RE: SSL Library Error
The system is 11.11. I'm *pretty* sure everything has been compiled with gcc. I'm compiling apache with gcc, but OpenLDAP and Openssl might have been compiled with something different. The apache install that works was definitely also compiled with gcc and uses the same install of OpenSSL and OpenLDAP. There is no lsof on this system, but I might be able to track down a copy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marek Marcola Sent: Wednesday, September 12, 2007 11:43 AM To: openssl-users@openssl.org Subject: RE: SSL Library Error Hello, I've missed that this is on hpux11. Very important is what version you have: hpux1100, hpux, hpux1123ia, hpux1123pa, hpux1131ia or hpux1131pa ? > I added --with-ssl=/usr/local to the the configure options and > recompiled. Although mod_ldap is still unhappy, that corrects the > unresolved symbol error if I launch apache without mod_ldap. However, > the result is the same problem I've been wrestling with. Piling up > child processes in a "waiting..." state. This installation has no > mention in the ldd output of links to the 0.9.8 so it should be, as far > as I can tell, using ONLY the 0.9.7 system, OS installed Openssl > libraries. Check that all software is compiled with gcc or with HP compiler. If some part (like Apache) is compiled with HP compiler and other (like OpenSSL) with gcc then OpenSSL requires libgcc but Apache has no link to this library because libgcc is not used by HP compiler. On hpux1100 there is no standard OpenSSL library (and not OpenSSL headers). If you have your Apapche running you may check with lsof what shared libraries are used by apache and from what directories. I think you should be able to perform clean rebuild of Apache and current OpenSSL. Depending on hpux you have, to be sure, you may temporary rename link /usr/include/openssl (which sometime points to /opt/openssl/include/openssl and sometimes is directory) when you compile your applications to be sure that header files are from your specified locations If Aapache is running try to connect with 'openssl s_client' with specified protocols (-ssl2, -ssl3 -tls1). Best regards, -- Marek Marcola <[EMAIL PROTECTED]> __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: SSL Library Error
I added --with-ssl=/usr/local to the the configure options and recompiled. Although mod_ldap is still unhappy, that corrects the unresolved symbol error if I launch apache without mod_ldap. However, the result is the same problem I've been wrestling with. Piling up child processes in a "waiting..." state. This installation has no mention in the ldd output of links to the 0.9.8 so it should be, as far as I can tell, using ONLY the 0.9.7 system, OS installed Openssl libraries. Aaron -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marek Marcola Sent: Wednesday, September 12, 2007 9:41 AM To: openssl-users@openssl.org Subject: RE: SSL Library Error Hello, > Well, I recompiled AGAIN with no mention of the 0.9.8 library in any of > my environment variables. The resulting httpd binary showed no links to > the 0.9.8 libraries, just 0.9.7 (the system OS libraries). THIS one > won't even start. I get an error of: > > /usr/lib/dld.sl: Unresolved symbol: __umoddi3 (code) from > /usr/local/lib/libcrypto.sl This symbol is in libgcc. Depending on gcc compilation, libgcc may be static or dynamic (or both). In this case it looks like main program is linked static (or not) with libgcc and when loading libcrypto.sl there is no link to this library. You may need to add this dynamic library to httpd recompilation (or rename temporary static version of libgcc). Best regards, -- Marek Marcola <[EMAIL PROTECTED]> __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: SSL Library Error
Well, I recompiled AGAIN with no mention of the 0.9.8 library in any of my environment variables. The resulting httpd binary showed no links to the 0.9.8 libraries, just 0.9.7 (the system OS libraries). THIS one won't even start. I get an error of: /usr/lib/dld.sl: Unresolved symbol: __umoddi3 (code) from /usr/local/lib/libcrypto.sl Not to mention that in order to get THAT far, I have to comment out the loading of the mod_ldap because it throws a much more vague "Unresolved External" error when it tries to load. This system is cursedCURSED I SAY! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Victor Duchovni Sent: Tuesday, September 11, 2007 4:12 PM To: openssl-users@openssl.org Subject: Re: SSL Library Error On Tue, Sep 11, 2007 at 03:34:13PM -0400, Aaron Smith wrote: > Looking at the output of LDD closer, it looks like the httpd binary is > linked to both libraries. BUT, I don't think this is the cause of the > problem as the httpd binary that DOES work is ALSO linked this way Being linked to both libraries is a problem, but even more so if the first library that is loaded does not match the compile-time headers. First escape DLL-hell, then debug other issues. If your LDAP library depends on OpenSSL 0.9.7, you need to link Apache also with 0.9.7. Mixing 0.9.7 and 0.9.8 in the same binary leads to unspecified behaviour. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: SSL Library Error
I'll see if I can figure out what's causing apache to link to 0.9.7. As far as I know, I've got all my environment variables set to look at the 0.9.8 libraries. It seems odd that the original compile would work though. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Victor Duchovni Sent: Tuesday, September 11, 2007 4:12 PM To: openssl-users@openssl.org Subject: Re: SSL Library Error On Tue, Sep 11, 2007 at 03:34:13PM -0400, Aaron Smith wrote: > Looking at the output of LDD closer, it looks like the httpd binary is > linked to both libraries. BUT, I don't think this is the cause of the > problem as the httpd binary that DOES work is ALSO linked this way Being linked to both libraries is a problem, but even more so if the first library that is loaded does not match the compile-time headers. First escape DLL-hell, then debug other issues. If your LDAP library depends on OpenSSL 0.9.7, you need to link Apache also with 0.9.7. Mixing 0.9.7 and 0.9.8 in the same binary leads to unspecified behaviour. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: SSL Library Error
Looking at the output of LDD closer, it looks like the httpd binary is linked to both libraries. BUT, I don't think this is the cause of the problem as the httpd binary that DOES work is ALSO linked this way -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Victor Duchovni Sent: Tuesday, September 11, 2007 1:57 PM To: openssl-users@openssl.org Subject: Re: SSL Library Error On Tue, Sep 11, 2007 at 01:43:50PM -0400, Aaron Smith wrote: > I apologize in advance if this is not the correct forum for this > question. I haven't had much luck in the apache forums. I have an > apache 2.0.55 installation that I'm attempting to recompile on an HP-UX > 11 system. It has mod_ssl 2.0.66 and I have OpenSSL 0.9.8d installed in > /opt/openssl098d. The system itself apparently has an older version of > OpenSSL (0.9.7e) installed in /usr/local. We have apache running on > this system just fine, but I have to recompile in order to add LDAP > support. If I take a fresh tarball of apache-2.0.55 and do a configure, > make, make install, everything completes without error. Doing an LDD of > the httpd binary shows it linked to the OpenSSL 0.9.8d libraries in > /opt/openssl098d/lib. The server starts up without issue, but when I > connect (with apache in debug mode), I get this: Perhaps you are using headers from one version of OpenSSL and linking with libraries from another. Make sure compile-time and run-time versions match. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
SSL Library Error
I apologize in advance if this is not the correct forum for this question. I haven't had much luck in the apache forums. I have an apache 2.0.55 installation that I'm attempting to recompile on an HP-UX 11 system. It has mod_ssl 2.0.66 and I have OpenSSL 0.9.8d installed in /opt/openssl098d. The system itself apparently has an older version of OpenSSL (0.9.7e) installed in /usr/local. We have apache running on this system just fine, but I have to recompile in order to add LDAP support. If I take a fresh tarball of apache-2.0.55 and do a configure, make, make install, everything completes without error. Doing an LDD of the httpd binary shows it linked to the OpenSSL 0.9.8d libraries in /opt/openssl098d/lib. The server starts up without issue, but when I connect (with apache in debug mode), I get this: [Tue Sep 11 10:10:43 2007] [info] Connection to child 2 established (server ourserver.name.scrubbed:8040, client ) [Tue Sep 11 10:10:43 2007] [info] Seeding PRNG with 136 bytes of entropy [Tue Sep 11 10:10:43 2007] [debug] ssl_engine_io.c(1512): OpenSSL: read 11/11 bytes from BIO#401a3500 [mem: 401aabb0] (BIO dump fo llows) [Tue Sep 11 10:10:43 2007] [debug] ssl_engine_io.c(1459): +--- --+ [Tue Sep 11 10:10:43 2007] [debug] ssl_engine_io.c(1484): | : 80 67 01 03 01 00 4e 00-00 00 10 .gN | [Tue Sep 11 10:10:43 2007] [debug] ssl_engine_io.c(1490): +--- --+ [Tue Sep 11 10:10:43 2007] [info] SSL library error 1 in handshake (server ourserver.name.scrubbed:8040, client ) [Tue Sep 11 10:10:43 2007] [info] SSL Library Error: 336027900 error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol speaking not SSL to HTTPS port!? [Tue Sep 11 10:10:43 2007] [info] Connection to child 2 closed with abortive shutdown(server ourserver.name.scrubbed:8040, ) That's if mod_ssl is compiled as a shared module. If I compile it into the httpd binary statically, then each request results in a child process spawning and sitting in the "Waiting" mode. The pile up and pile up until they eventually drive the server load up to really high levels. One oddity I notice is that even though I set every environment variable I know of (SHLIB_PATH, LD_LIBRARY_PATH, CPPFLAGS, LDFLAGS) to point to /opt/openssl098d/lib, the apache server-status lists OpenSSL 0.9.7e (the local system install). The other thing is that a few months ago, I was working on the same issue and manage to compile a version of apache in a parallel directory using the same configure commands (I believe) as now, and that install works perfectly!! I'm thinking it's something strange with my current build environment but am uncertain where else to look. Where could apache be picking up that other SSL library?
RE: Wierd Linking issue with 0.9.8d
Ah! Excellent! That did indeed correct that annoying error. Thank you. Aaron Smith[EMAIL PROTECTED] System Administrator (269) 337-7496 Kalamazoo College -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marek Marcola Sent: Thursday, December 21, 2006 10:36 AM To: openssl-users@openssl.org Subject: Re: Wierd Linking issue with 0.9.8d Hello, > So I downloaded a copy of OpenSSL 0.9.8d to my HP-UX > system, did a ./config -prefix=/opt/openssl098d shared, make, make > test, make install and all worked well. However, I've run into a > problem while compiling other pieces of software that use OpenSSL > (such as Apache's mod_auth_ldap module) where it's trying to find > "./libcrypto.sl.0.9.8". Yes, there's a "../" on there. If I run ldd > on libssl.sl.0.9.8, it shows: > > > > # /usr/ccs/bin/ldd libssl.sl.0.9.89 > > /usr/lib/libdld.2 =>/usr/lib/libdld.2 > > /usr/lib/libc.2 => /usr/lib/libc.2 > > /usr/lib/libdld.2 =>/usr/lib/libdld.2 > > ../libcrypto.sl.0.9.8 => ../libcrypto.sl.0.9.8 > > /usr/lib/libdld.2 =>/usr/lib/libdld.2 > > > > I can get things to compile by copying that libcrypto library into > whatever local directory it happens to be trying to compile in, but > that's a dirty hack and I suspect that this is the cause of me not > being able to run those resultant binaries (they throw errors about > unresolved symbols like ap_set_flag_slot and apr_pool_cleanup_null). > What did I do wrong with the install here to cause this to happen? Nothing, sometimes on hpux this works this way. To change this you may after "make install" change definition of SHLIBDEPS variable in main Makefile in line: $(MAKE) SHLIBDIRS=ssl SHLIBDEPS='-lcrypto' build-shared; \ to: SHLIBDEPS='/opt/openssl098d/lib/libcrypto.sl.0.9.8' and next: # ldd libssl.sl.0.9.8 # rm libssl.sl.0.9.8 # make libssl.sl.0.9.8 # ldd libssl.sl.0.9.8 # cp libssl.sl.0.9.8 /opt/openssl098d/lib this will change "./" to "/opt/openssl098d/lib". Next dirty hack. Best regards, -- Marek Marcola <[EMAIL PROTECTED]> __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Wierd Linking issue with 0.9.8d
So I downloaded a copy of OpenSSL 0.9.8d to my HP-UX system, did a ./config -prefix=/opt/openssl098d shared, make, make test, make install and all worked well. However, I've run into a problem while compiling other pieces of software that use OpenSSL (such as Apache's mod_auth_ldap module) where it's trying to find "./libcrypto.sl.0.9.8". Yes, there's a "./" on there. If I run ldd on libssl.sl.0.9.8, it shows: # /usr/ccs/bin/ldd libssl.sl.0.9.89 /usr/lib/libdld.2 =>/usr/lib/libdld.2 /usr/lib/libc.2 => /usr/lib/libc.2 /usr/lib/libdld.2 =>/usr/lib/libdld.2 ./libcrypto.sl.0.9.8 => ./libcrypto.sl.0.9.8 /usr/lib/libdld.2 =>/usr/lib/libdld.2 I can get things to compile by copying that libcrypto library into whatever local directory it happens to be trying to compile in, but that's a dirty hack and I suspect that this is the cause of me not being able to run those resultant binaries (they throw errors about unresolved symbols like ap_set_flag_slot and apr_pool_cleanup_null). What did I do wrong with the install here to cause this to happen? -------- Aaron Smith[EMAIL PROTECTED] System Administrator (269) 337-7496 Kalamazoo College
RE: Certificate Verification
Well, I figured out PART of my problem. Somehow I got the wrong CA certificate. Once I got the right one, I can do a successful s_client connect as long as I provide the –Cafile argument to point openssl to the correct CA file. However, if I try to do it without the –Cafile argument, I get the same “unable to get local issuer” problem. I don’t have a cacert.pem file on the system at all (this is a stock Solaris 10 install). Everything openssl related appears to be in /etc/sfw/openssl, including the openssl.cnf file. This file has the following default options in the [CA_default] section: dir = /etc/sfw/openssl certs = $dir/certs certificate = $dir/cacert.pem So, I take this to mean that openssl will look for CA certificates in /etc/sfw/openssl/cacert.pem? I took the CA certificate (that works) and put it in /etc/sfw/openssl with the name of cacert.pem but it still couldn’t find it. From: owner-openssl-users@openssl.org [mailto:owner-openssl-users@openssl.org] On Behalf Of Vincenzo Sciarra Sent: Thursday, October 12, 2006 4:29 AM To: openssl-users@openssl.org Subject: Re: Certificate Verification Try to add the CA certificate to cacert.pem default openssl CA certificate Simply: cat MScaCERT.pem >> cacert.pem 2006/10/12, Dr. Stephen Henson <[EMAIL PROTECTED]>: On Wed, Oct 11, 2006, Aaron Smith wrote: > Ok. This is hopefully a simple question, and one that I see > quite a bit in the archives. However, everything I've tried and gleaned > from searching the archives have come up nothing. I have server > certificate from a Microsoft Domain Controller that was created via MS's > certificate authority. I'm trying to get Openssl to connect to it, but > I get the now familiar "unable to get local issuer certificate" error > when using s_client. I have the CA certificate, and there is, to my > knowledge, no intermediate certificates. I have tried putting the CA > certificate into the certs directory defined in openssl.cnf with a > symbolic link of the cert's hash value pointing to it. I have tried > doing openssl verify -Cafile ./sandbox-ca.pem server-cert.pem and still > get the same error. Now, my assumption is that if I try to do a verify > on a server certificate and provide (via the -Cafile option) that SHOULD > be all it needs to verify the certificate correct? Is there something > wrong with my certs? I've provided both in the email so that maybe > someone can point out what the problem is: > The problem is that the subject key identifier (SKID) of the issuer certifcate does not match the authority key identifier (AKID) of the server certificate. You can see this for yourself by doing: openssl x509 -in cert.pem -text -noout So whatever generated the certificates needs to be configured so it correctly uses the same value for AKID in the server as SKID in the CA. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- Vincenzo Sciarra
Certificate Verification
Ok. This is hopefully a simple question, and one that I see quite a bit in the archives. However, everything I’ve tried and gleaned from searching the archives have come up nothing. I have server certificate from a Microsoft Domain Controller that was created via MS’s certificate authority. I’m trying to get Openssl to connect to it, but I get the now familiar “unable to get local issuer certificate” error when using s_client. I have the CA certificate, and there is, to my knowledge, no intermediate certificates. I have tried putting the CA certificate into the certs directory defined in openssl.cnf with a symbolic link of the cert’s hash value pointing to it. I have tried doing openssl verify –Cafile ./sandbox-ca.pem server-cert.pem and still get the same error. Now, my assumption is that if I try to do a verify on a server certificate and provide (via the –Cafile option) that SHOULD be all it needs to verify the certificate correct? Is there something wrong with my certs? I’ve provided both in the email so that maybe someone can point out what the problem is: N1-wrath.sandbox.com (sandbox.com is a virtual domain used for testing): -BEGIN CERTIFICATE- MIIFszCCBJugAwIBAgIKGlNrzjANBgkqhkiG9w0BAQUFADBDMRMwEQYK CZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPyLGQBGRYHc2FuZGJveDETMBEGA1UE AxMKU2FuZGJveCBDQTAeFw0wNjA4MjMxNTM5NDNaFw0wNzA4MjMxNTM5NDNaMB8x HTAbBgNVBAMTFG4xLXdyYXRoLnNhbmRib3guY29tMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDfYb6tJxC8E4GMIIXwuV2VuUTKMavBRjem04DRZzYDpLky4mOo cBd8s8DwlmRKqtW68LxIhRxHZc6K3y8ytXeFD9VMKTX9hPl3Tk+vvQ/Q2Xjv1CwG wTRqaeAbnZK+15Q6WkM61yAu0XA3U1f6RaBA5PZFyFbTOkSN0TAJiHw2tQIDAQAB o4IDTzCCA0swCwYDVR0PBAQDAgWgMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcN AwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNV HQ4EFgQUAduzIdaqGDT41RLrYhQJdAR+YPswLwYJKwYBBAGCNxQCBCIeIABEAG8A bQBhAGkAbgBDAG8AbgB0AHIAbwBsAGwAZQByMB8GA1UdIwQYMBaAFEcKpdwNYJ/A b+MFCQo8wgaO7VtCMIIBBAYDVR0fBIH8MIH5MIH2oIHzoIHwhoG0bGRhcDovLy9D Tj1TYW5kYm94JTIwQ0EsQ049bjEtd3JhdGgsQ049Q0RQLENOPVB1YmxpYyUyMEtl eSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9c2Fu ZGJveCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVj dENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hjdodHRwOi8vbjEtd3JhdGguc2Fu ZGJveC5jb20vQ2VydEVucm9sbC9TYW5kYm94JTIwQ0EuY3JsMIIBGgYIKwYBBQUH AQEEggEMMIIBCDCBqwYIKwYBBQUHMAKGgZ5sZGFwOi8vL0NOPVNhbmRib3glMjBD QSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMs Q049Q29uZmlndXJhdGlvbixEQz1zYW5kYm94LERDPWNvbT9jQUNlcnRpZmljYXRl P2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBYBggrBgEF BQcwAoZMaHR0cDovL24xLXdyYXRoLnNhbmRib3guY29tL0NlcnRFbnJvbGwvbjEt d3JhdGguc2FuZGJveC5jb21fU2FuZGJveCUyMENBLmNydDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwEwQAYDVR0RBDkwN6AfBgkrBgEEAYI3GQGgEgQQgto8 vGzkE0+9zIRFWXgxVYIUbjEtd3JhdGguc2FuZGJveC5jb20wDQYJKoZIhvcNAQEF BQADggEBAJjCdQkVc+QOSMp81/Og7/2X8nJDEP6qJqPnJjVLAfWnMJjYzbj3bZs0 XompdxVxNb7CchT3TEJoUMnGGzTSu7J0di+Qgwt7lMfOR6BFOYal03fscuLQmALZ U4/4K//QJV9MWungDMkj0XBGg86HJzwtUpZeu7bUdgmcRCYfZhTdY42fD13a9bGD IGcz6LAAYBMWwfIDQ0UL6CuFIkS6j7WTxxLWzB+i8cxrEMhLvpUT54fJQnYfNkhS 4Wg12/MUGn9ykK1IFk3ym+FgB20K5vjAykx3DVqdxKG1pa+NhDHdpgcv+cI7wyUA bBtxiZa2V2vB2x+BV0f0LYVB+3KgrOU= -END CERTIFICATE- The CA certificate from the sandbox.com domain controller (which happens to be n1-wrath): -BEGIN CERTIFICATE- MIIEgjCCA2qgAwIBAgIQHZSufQev7bBPeD3puDiTZDANBgkqhkiG9w0BAQUFADBD MRMwEQYKCZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPyLGQBGRYHc2FuZGJveDET MBEGA1UEAxMKU2FuZGJveCBDQTAeFw0wNjA4MjMxODEwNDJaFw0xMTA4MjMxODE5 MTFaMEMxEzARBgoJkiaJk/IsZAEZFgNjb20xFzAVBgoJkiaJk/IsZAEZFgdzYW5k Ym94MRMwEQYDVQQDEwpTYW5kYm94IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAzi1RBABv+NIwN6V5Cb36Xvh4aBR0meZu6Dt7C03E2NGLRuqByGEZ roxHFmxfw3iLEXCG4wuX8vgmofL25Zxs4SFh0AGTXRLtyCgWkcaRtaRLv/2uOdxu cfzr0lQujvuaBwORG2b/oxMvaHNs7Fn1W+dDl8mtaq1GIoW4Cy37xWvEK/cLfxzK Ar2ieI9edSMTDn23ckksKhFVhz4vQN2eDGR6hS7a22ocxFf+X5bbCZih8gtsZq7P tNByxtAtqxPvFK+KvBphFi8W7W4xRwY9jbgigjluzM4HxtqmNHUWmhFtOjdwnfDd RJPxgLVvkrlNz8xQi4s4j2f/naIZUDZMIQIDAQABo4IBcDCCAWwwEwYJKwYBBAGC NxQCBAYeBABDAEEwCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0O BBYEFFF6eyh++VR2O41NFn610FcKO2RIMIIBBAYDVR0fBIH8MIH5MIH2oIHzoIHw hoG0bGRhcDovLy9DTj1TYW5kYm94JTIwQ0EsQ049bjEtd3JhdGgsQ049Q0RQLENO PVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3Vy YXRpb24sREM9c2FuZGJveCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hjdodHRwOi8v bjEtd3JhdGguc2FuZGJveC5jb20vQ2VydEVucm9sbC9TYW5kYm94JTIwQ0EuY3Js MBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBBQUAA4IBAQCpf6vt20PD17bi /GJFzIbR+fnjbmYtM6dCcjJoxquxMhBG6YDh29kNIoztDXShEOVPxhFYeaDvONEk v39WBYpyCqwQogQkNAQGOP0j+hzVJqxJtwZW0GE2QW+5pmdYJkzcD7R7ckZvHU9t ngYBqbCZQTVPFCxit0nHiwNLe0P+aFb4cc7xq+l4Sd/9GyDAnQLsJ8NL8seqWbVZ NPA70dgYj1qJR08yuJlB48yXkOyOG0GJQvsZpmwMV5r7feKjQCQnRV7fYHSTpsh6 RYx+zA1okfkaqBQ75RAoidiGyYkeBKwp+I+SzHf7011dUajRMik2ZD7u7APa6sZB zVlJ7wPM -END CERTIFICAT
Re: Question about generating keys, certificate requests
Well, with the various SSL certificates I create with our in-house CA, I create them all on one machine and then copy the certificates over to the machines that will actually use them. No problem at all. So I'd guess that nothing about the machine you're creating the request on is put into the certificate... On Tue, 2005-01-04 at 16:22, Stewart Dean wrote: > When you do this using either the req or gen rsa command, does the > generated output have *anything* in it that acts as a fingerprint of the > machine where the command was invoked? > That is, as part of running these commands, does the output end up withe > some section that ties it to that very machine and no other? > > I am bringing up secure IMAP using openssl on our imap mail server. I > currently have it working just fine using a self-signed certificate. > Now I want to get a Class 1 Digital Certificate from Verisign and so > have to submit a certificate request > I'm pretty clear on what I have to do, but I have a problem. > > The mail server in question has a hostname (mercury.bard.edu). It also > has 3 NICs that answer to 6 numeric addresses...three of them primary > addresses and the other three secondary 'network aliases' (as defined, I > think, by Sun, IBM and Red Hat, a network alias is a numeric address > that is recognized and responded to BY THE NIC HARDWARE...as such, it is > externally indistinguishable from the primary address...the machine > responds the same to either, and it's only internally that you can find > out which is which). ALL six of the corresponding symbolic host names > have A records (NOT CNAME) in DNS and resolve forward and back uniquely. > > Now if this were a machine with one hostname and one numeric address, I > would have no question about how to generate keys and certificate > requests...I would just do it. > > But. > > This machine has 6 numeric IP addresses it answers, one internal > hostname (mercury) and 5 more hostnames in DNS: mercury2, mercmailport, > smtp, imap & mail > > When I run the openssl req/genrsa command, am I going to get some > fingerprint of the machine embedded that won't match the DNS symbolic > name I want to use (imap.bard.edu) and put in the CN? Which I would > think would make the certificate usage fail because the host name it got > for that fingerprint might be mercury or anyone of the other 4? > > Or does the generation process take no fingerprint and could be run on > any machine that answers to the numeric IP address corresponding to the > CN specified and entered when the command was run? > > My head hurts. > > I wouldn't make such a big deal out of this, except that the certificate > isn't cheap, and Verisign gives you 3 days of support to get things up, > then you're on your own. And my attempt to ask this question of the > pre-purchase email tech support returned a 'dartboard' answerit had > absolutely nothing to do with my question..must have been picked out > by throwing a dart at a list of canned answers > > Thanks in advance for your help -- - Aaron Smith vox: 269.226.9550 ext.26 http://www.nexcerpt.com fax: 269.349.9076 ...Nexcerpt... Extend Your Expertise signature.asc Description: This is a digitally signed message part
Re: Certificate Revocation
That did the trick. Thanks a lot! On Fri, 2004-05-14 at 12:52, Olaf Gellert wrote: > Aaron Smith wrote: > > We have been using OpenSSL to generate certificates for various > > applications here with a home grown CA (created using openssl ca). We > > recently started upgrading our servers from Redhat 7.3 to RHEL 3.0. The > > machine that used to house the CA directories used openssl version > > 0.9.6b (RedHat RPM) and the new machine uses openssl version 0.9.7b > > (again, RedHat RPM). I tar'ed up the CA directories from the old > > machine and plopped them onto the new machine. When I attempted to > > revoke a certificate (by "openssl ca -revoke certfile.pem"), I received > > the following error: > > > > ERROR:name does not match > > Maybe it's something to do with Email-Addresses in > the DN? From 0.9.6 to 0.9.7 the entry output of > openssl changed from "Email" to "emailAddress" > so it could be that you have to change this in > the "index.txt" file of OpenSSL. > > Just a guess... > Cheers, Olaf -- - Aaron Smith vox: 269.226.9550 ext.26 Network Directorfax: 269.349.9076 Nexcerpt, Inc. http://www.nexcerpt.com ...Nexcerpt... Extend Your Expertise signature.asc Description: This is a digitally signed message part
Certificate Revocation
We have been using OpenSSL to generate certificates for various applications here with a home grown CA (created using openssl ca). We recently started upgrading our servers from Redhat 7.3 to RHEL 3.0. The machine that used to house the CA directories used openssl version 0.9.6b (RedHat RPM) and the new machine uses openssl version 0.9.7b (again, RedHat RPM). I tar'ed up the CA directories from the old machine and plopped them onto the new machine. When I attempted to revoke a certificate (by "openssl ca -revoke certfile.pem"), I received the following error: ERROR:name does not match The same command worked fine on the old server. The only different in execution that I see is that, when run on the new server, I get a line that says "Using configuration from /usr/share/ssl/openssl.cnf" which I don't get on the old server. I have an openssl.cnf file in the CA directory that was just copied from /usr/share/ssl when the CA was originally created (along with CA.pl). Is this a compatibility problem between the openssl versions? If so, is there a way around it or do I need to recreate all of my CA's and regenerate all of my certificates? -- --------- Aaron Smith vox: 269.226.9550 ext.26 Network Directorfax: 269.349.9076 Nexcerpt, Inc. http://www.nexcerpt.com ...Nexcerpt... Extend Your Expertise signature.asc Description: This is a digitally signed message part
Re: OpenSSL: Support, Mailing Lists
I just installed mod_ssl on my Mac OS X server and when I try to access it for testing I get the following error message: SSL_connect:error in SSLv2/v3 read server hello A 404:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:460: Any suggestions? Thanks, Aaron Smith __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
