Re: Local Issuer Certificate??????
Dan O'Reilly wrote: Trying to test certs before moving on to LDAP tests. The certs were obtained from a CA running on a MS box. Here's what happens: openssl s_client -connect adtest:636 -cert foo.pem -CAfile homeca_ce rt_chain.p7b Enter pass phrase for foo.pem: CONNECTED(0003) depth=0 /CN=adtest.altdomain2000.psccos.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /CN=adtest.altdomain2000.psccos.com verify error:num=27:certificate not trusted verify return:1 depth=0 /CN=adtest.altdomain2000.psccos.com verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=adtest.altdomain2000.psccos.com i:/C=US/ST=CO/L=Colorado Springs/O=Process Software/CN=homeca --- Server certificate -BEGIN CERTIFICATE- snip -END CERTIFICATE- subject=/CN=adtest.altdomain2000.psccos.com issuer=/C=US/ST=CO/L=Colorado Springs/O=Process Software/CN=homeca [...] What is this telling me? I downloaded the CA certificate from the MS system and have a server certificate. I'm *VERY* lost in all this! HELP Hmm, the error message of s_client is saying that it cannot find the certificate of the issuer of the server's cert. Since there are no intermediate CAs involved the issuer must be contained in the CAfile. Are you sure the certificate of /C=US/ST=CO/L=Colorado Springs/O=Process Software/CN=homeca is contained in your CAfile (homeca_ce)? Is it possible for you to post the homeca_ce and the server's cert (snipped out in your log)? Have you tried connecting without a client certificate as a first step to make sure the server's cert is verified correctly? Have you tried connecting another secure server (for example https://www.cacert.org, the corresponding CA certificate can be downloaded at http://www.cacert.org/certs/root.crt)? Just some directions that may (or may not) help you to find the way out... Hope it helps. Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 smime.p7s Description: S/MIME Cryptographic Signature
Re: OpenSSL and CA
Vincenzo Sciarra wrote: Hi, I'm developing an application using X509 cert stardard. I'm trying to use a remote Certification Authority in client-server authentication exchange. In other words : Client send public key to server - Server verify client's public key with CA - Authentication exchange follow up My problems are : 1) How Server can trust a CA on demand using OpenSSL? (I thing that CA should be pre-trusted) 2) Using OpenSSL API how can server get public key verification from CA? I'm not sure what your problem is. Are you trying to verify certificates with a CA's revocation list or OCSP? Or are you trying to verify the CA's certificate itself (you can't do that automatically. A CA's certificate has to be trusted as far as OpenSSL is concerned)? Or do you want to verify that a client certificate is issued by an acceptable CA? Or are you just trying to load a CAfile into a context? Please be a bit more specific. Hope it helps, Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 smime.p7s Description: S/MIME Cryptographic Signature
Need help: Understanding SSL object in multi-threaded environment
Hi all, I have some doubts about openssl and multithreaded environment. I will appreciate if you could help me understand this better. It is said that openssl is thread-safe with a limitation that "an SSL connection may not concurrently be used by multiple threads" I am not clear on this point. What is meant by "using SSL connection concurrently by multiple threads" ? I read somewhere that anSSL object modifies and maintains its state during reads and writes. So if the same object is used in multiple threads concurrently, chances are that due to state mismatch, the read/write may fail. Could someone explain this in more details. I believe that multiple threads would share the sameSSL object. So in fact, they will be using 'the sameSSL object'. Is this understanding correct? If yes, what is the issue with using the same object in multiple threads? I am struggling to understand this. Could someone make the picture more clear? Thank you, ~ Urjit DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails.
Re: OpenSSL and CA
I want to verify that a client certificate is issued by an acceptable CA. Thanks 2006/10/5, Bernhard Froehlich [EMAIL PROTECTED]: Vincenzo Sciarra wrote: Hi, I'm developing an application using X509 cert stardard. I'm trying to use a remote Certification Authority in client-server authentication exchange. In other words : Client send public key to server - Server verify client's public key with CA - Authentication exchange follow up My problems are : 1) How Server can trust a CA on demand using OpenSSL? (I thing that CA should be pre-trusted) 2) Using OpenSSL API how can server get public key verification from CA? I'm not sure what your problem is. Are you trying to verify certificateswith a CA's revocation list or OCSP? Or are you trying to verify theCA's certificate itself (you can't do that automatically. A CA'scertificate has to be trusted as far as OpenSSL is concerned)? Or do you want to verify that a client certificate is issued by an acceptable CA?Or are you just trying to load a CAfile into a context?Please be a bit more specific.Hope it helps,Ted;)--PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.ascKey fingerprint = 31B0 E029 BCF9 6605 DAC1B2E1 0CC8 70F4 7AFB 8D26
RE: Need help: Understanding SSL object in multi-threaded environment
Hi, you may usethe sameH_SSL_CTX (handle to an SSL context) in concurrent threads. This structure serves as a factory of ssl connections. You use SSL_new to create SSL connection handles (H_SSL). These you can use only within one thread. So, you may share H_SSL_CTX, you may not share H_SSL. HTH André From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Urjit GokhaleSent: Donnerstag, 5. Oktober 2006 09:33To: openssl-users@openssl.orgSubject: Need help: Understanding SSL object in multi-threaded environment Hi all, I have some doubts about openssl and multithreaded environment. I will appreciate if you could help me understand this better. It is said that openssl is thread-safe with a limitation that "an SSL connection may not concurrently be used by multiple threads" I am not clear on this point. What is meant by "using SSL connection concurrently by multiple threads" ? I read somewhere that anSSL object modifies and maintains its state during reads and writes. So if the same object is used in multiple threads concurrently, chances are that due to state mismatch, the read/write may fail. Could someone explain this in more details. I believe that multiple threads would share the sameSSL object. So in fact, they will be using 'the sameSSL object'. Is this understanding correct? If yes, what is the issue with using the same object in multiple threads? I am struggling to understand this. Could someone make the picture more clear? Thank you, ~ Urjit DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. smime.p7s Description: S/MIME Cryptographic Signature
Question on Diffie Hellman Parameters
Hi there, I still can't get a grip on the security implications of those DH parameters. I understand that they have to be chosen carefully but otherwise they may be public. This would imply that once a good set of parameters has been found everybody could use them forever (that is, until lager key sizes are needed), all over the world. If this is so why aren't good DH parameters just hardcoded into OpenSSL's DH implementation? Does it improve security to periodically generate new DH params? I'd appreciate if someone could shed some light on the topic. Or point me to a more appropriate forum to post this question. Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 smime.p7s Description: S/MIME Cryptographic Signature
Re: OpenSSL and CA
Vincenzo Sciarra wrote: I want to verify that a client certificate is issued by an acceptable CA. Thanks You'd do it the same way as verifying that the server's CA is acceptable. Would be something like * Setting a CA-file or a CA directory containing the acceptable CAs into the context with SSL_CTX_load_verify_locations * Setting mode ***SSL_VERIFY_PEER* with SSL_CTX_set_verify * Possibly also set a callback with SSL_CTX_set_verify or use SSL_get_peer_certificate to check for extensions (for example to do OCSP or CRL checking) Hope it helps. Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 smime.p7s Description: S/MIME Cryptographic Signature
RE: Need help: Understanding SSL object in multi-threaded environment
you may use the same H_SSL_CTX (handle to an SSL context) in concurrent threads. This structure serves as a factory of ssl connections. You use SSL_new to create SSL connection handles (H_SSL). These you can use only within one thread. So, you may share H_SSL_CTX, you may not share H_SSL. I can't find anything in the documentation to suggest that you cannot share a SSL object between threads. The important thing is to implement the locking callbacks [CRYPTO_set_locking_callback() etc.]. I have written applications that read on one thread and write on another using the same SSL object and they work fine. Please tell me if I am incorrect in my assumptions. Regards, Mark __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Need help: Understanding SSL object in multi-threaded environment
- Original Message - From: Mark [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Thursday, October 05, 2006 2:49 PM Subject: RE: Need help: Understanding SSL object in multi-threaded environment you may use the same H_SSL_CTX (handle to an SSL context) in concurrent threads. This structure serves as a factory of ssl connections. You use SSL_new to create SSL connection handles (H_SSL). These you can use only within one thread. So, you may share H_SSL_CTX, you may not share H_SSL. I can't find anything in the documentation to suggest that you cannot share a SSL object between threads. The important thing is to implement the locking callbacks [CRYPTO_set_locking_callback() etc.]. [Urjit]: Correct. One should implement the locking callbacks. What I am confused about is the statement in openssl faq (http://www.openssl.org/support/faq.html#PROG1) that reads: --- 1. Is OpenSSL thread-safe? Yes (with limitations: an SSL connection may not concurrently be used by multiple threads) --- ~ Urjit DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Need help: Understanding SSL object in multi-threaded environment
1. Is OpenSSL thread-safe? Yes (with limitations: an SSL connection may not concurrently be used by multiple threads) This means exactly what it says. A single SSL connection may not be used concurrently by multiple threads. This means it is illegal for one thread to do a 'write' on the connection at the same time another thread might be doing, say, a 'read'. You can share an SSL connection object among threads, but you must protect it yourself with a mutex or similar lock. This is a semantic difference between SSL connections and normal TCP connections. For example, with TCP, you call 'shutdown' in one thread, 'read' in another, and 'write' in a third all at the same time and you will get sensible results. This is, however, the usual rule for user-space objects. For example, even if you have a plain old integer, you cannot write to it in one thread and read from it another and get guaranteed results. (At least, not without some special knowledge about your platform.) DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Need help: Understanding SSL object in multi-threaded environment
David, 1. Is OpenSSL thread-safe? Yes (with limitations: an SSL connection may not concurrently be used by multiple threads) This means exactly what it says. A single SSL connection may not be used concurrently by multiple threads. This means it is illegal for one thread to do a 'write' on the connection at the same time another thread might be doing, say, a 'read'. You can share an SSL connection object among threads, but you must protect it yourself with a mutex or similar lock. I assume this a reason why OpenSSL has the locking callback functions. As long as you use these it is safe to share the object AFAIK. Regards, Mark __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Local Issuer Certificate??????
On Thu, Oct 05, 2006, Dan O'Reilly wrote: At 12:48 AM 10/5/2006, Bernhard Froehlich wrote: Dan O'Reilly wrote: Trying to test certs before moving on to LDAP tests. The certs were obtained from a CA running on a MS box. Here's what happens: openssl s_client -connect adtest:636 -cert foo.pem -CAfile homeca_ce rt_chain.p7b The above command is the problem. You can't use a PKCS#7 (.p7b) file directly in the -CAfile command. openssl pkcs7 -inform der -in homeca_cert_chain.p7b -noout -print_certs -text Use the above command to say the certificate to a PEM file. For exampl home_ca.pem and use that file for the -CAfile. 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]
Re: Local Issuer Certificate??????
At 05:34 AM 10/5/2006, Dr. Stephen Henson wrote: On Thu, Oct 05, 2006, Dan O'Reilly wrote: At 12:48 AM 10/5/2006, Bernhard Froehlich wrote: Dan O'Reilly wrote: Trying to test certs before moving on to LDAP tests. The certs were obtained from a CA running on a MS box. Here's what happens: openssl s_client -connect adtest:636 -cert foo.pem -CAfile homeca_ce rt_chain.p7b The above command is the problem. You can't use a PKCS#7 (.p7b) file directly in the -CAfile command. openssl pkcs7 -inform der -in homeca_cert_chain.p7b -noout -print_certs -text Use the above command to say the certificate to a PEM file. For exampl home_ca.pem and use that file for the -CAfile. It doesn't change anything. Same error. openssl s_client -connect adtest:636 -CAfile homeca_cert_chain.pem CONNECTED(0003) depth=0 /CN=adtest.altdomain2000.psccos.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /CN=adtest.altdomain2000.psccos.com verify error:num=27:certificate not trusted verify return:1 depth=0 /CN=adtest.altdomain2000.psccos.com verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=adtest.altdomain2000.psccos.com i:/C=US/ST=CO/L=Colorado Springs/O=Process Software/CN=homeca snip 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] -- +---++ | Dan O'Reilly | There are 10 types of people in this | | Principal Engineer| world: those who understand binary | | Process Software | and those who don't.| | http://www.process.com|| +---++ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Local Issuer Certificate??????
Hello, Trying to test certs before moving on to LDAP tests. The certs were obtained from a CA running on a MS box. Here's what happens: openssl s_client -connect adtest:636 -cert foo.pem -CAfile homeca_ce rt_chain.p7b The above command is the problem. You can't use a PKCS#7 (.p7b) file directly in the -CAfile command. openssl pkcs7 -inform der -in homeca_cert_chain.p7b -noout -print_certs -text Use the above command to say the certificate to a PEM file. For exampl home_ca.pem and use that file for the -CAfile. It doesn't change anything. Same error. openssl s_client -connect adtest:636 -CAfile homeca_cert_chain.pem CONNECTED(0003) depth=0 /CN=adtest.altdomain2000.psccos.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /CN=adtest.altdomain2000.psccos.com verify error:num=27:certificate not trusted verify return:1 depth=0 /CN=adtest.altdomain2000.psccos.com verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=adtest.altdomain2000.psccos.com i:/C=US/ST=CO/L=Colorado Springs/O=Process Software/CN=homeca To check if you have proper CA cert in homeca_cert_chain.pem execute: $ openssl x509 -in homeca_cert_chain.pem -noout -subject -issuer output should be something like: subject= /C=US/ST=CO/L=Colorado Springs/O=Process Software/CN=homeca issuer= /C=US/ST=CO/L=Colorado Springs/O=Process Software/CN=homeca (provided that you have one certificate in homeca_cert_chain.pem) If you do not have such certificate then you must download proper CA cert. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Local Issuer Certificate??????
At 06:54 AM 10/5/2006, Marek Marcola wrote: Hello, Trying to test certs before moving on to LDAP tests. The certs were obtained from a CA running on a MS box. Here's what happens: openssl s_client -connect adtest:636 -cert foo.pem -CAfile homeca_ce rt_chain.p7b The above command is the problem. You can't use a PKCS#7 (.p7b) file directly in the -CAfile command. openssl pkcs7 -inform der -in homeca_cert_chain.p7b -noout -print_certs -text Use the above command to say the certificate to a PEM file. For exampl home_ca.pem and use that file for the -CAfile. It doesn't change anything. Same error. openssl s_client -connect adtest:636 -CAfile homeca_cert_chain.pem CONNECTED(0003) depth=0 /CN=adtest.altdomain2000.psccos.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /CN=adtest.altdomain2000.psccos.com verify error:num=27:certificate not trusted verify return:1 depth=0 /CN=adtest.altdomain2000.psccos.com verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=adtest.altdomain2000.psccos.com i:/C=US/ST=CO/L=Colorado Springs/O=Process Software/CN=homeca To check if you have proper CA cert in homeca_cert_chain.pem execute: $ openssl x509 -in homeca_cert_chain.pem -noout -subject -issuer output should be something like: subject= /C=US/ST=CO/L=Colorado Springs/O=Process Software/CN=homeca issuer= /C=US/ST=CO/L=Colorado Springs/O=Process Software/CN=homeca (provided that you have one certificate in homeca_cert_chain.pem) If you do not have such certificate then you must download proper CA cert. OK, I got a new copy of the cert and converted it to PEM format from DER format. Now I get: $ openssl s_client -connect adtest:636 -CAfile homeca_cert.pem CONNECTED(0003) depth=1 /C=US/ST=CO/L=Colorado Springs/O=Process Software/CN=homeca verify return:1 depth=0 /CN=adtest.altdomain2000.psccos.com verify return:1 --- Certificate chain 0 s:/CN=adtest.altdomain2000.psccos.com i:/C=US/ST=CO/L=Colorado Springs/O=Process Software/CN=homeca --- Server certificate -BEGIN CERTIFICATE- MIIFijCCBTSgAwIBAgIKYQMaYgAAAjANBgkqhkiG9w0BAQUFADBhMQswCQYD VQQGEwJVUzELMAkGA1UECBMCQ08xGTAXBgNVBAcTEENvbG9yYWRvIFNwcmluZ3Mx GTAXBgNVBAoTEFByb2Nlc3MgU29mdHdhcmUxDzANBgNVBAMTBmhvbWVjYTAeFw0w NjA5MTQxNjU3NDdaFw0wODA5MTQxNzA3NDdaMCoxKDAmBgNVBAMTH2FkdGVzdC5h bHRkb21haW4yMDAwLnBzY2Nvcy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBAL7nVRO9pvigvqim4cqetHJu56PQlPw2MSJe2/SYcxrnA2SsdSvbBAwVTEPZ KUqGOyGfXDV02S07MX9GR5X66YS1qkGfBzeSbX7Yx1ti9+J/PODkyZh2vwlRtTHj PQzZ0X6p+Z5eevDxkE4lJ0jWitvhwlZF3H3X3AsBsjltqnQpAgMBAAGjggO/MIID uzALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMC8G CSsGAQQBgjcUAgQiHiAARABvAG0AYQBpAG4AQwBvAG4AdAByAG8AbABsAGUAcjAd BgNVHQ4EFgQUIdHmJF8ClHMKh5ciCj+UrQtuwZkwgZoGA1UdIwSBkjCBj4AUovZy djchr9mywKUw9EvkaSvBoDuhZaRjMGExCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJD TzEZMBcGA1UEBxMQQ29sb3JhZG8gU3ByaW5nczEZMBcGA1UEChMQUHJvY2VzcyBT b2Z0d2FyZTEPMA0GA1UEAxMGaG9tZWNhghBRMq+GTAdMg0PtqnzeHGUHMIIBGQYD VR0fBIIBEDCCAQwwgcWggcKggb+GgbxsZGFwOi8vL0NOPWhvbWVjYSxDTj1hZHRl c3QsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9YWx0ZG9tYWluMjAwMCxEQz1wc2Njb3MsREM9 Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RjbGFzcz1j UkxEaXN0cmlidXRpb25Qb2ludDBCoECgPoY8aHR0cDovL2FkdGVzdC5hbHRkb21h aW4yMDAwLnBzY2Nvcy5jb20vQ2VydEVucm9sbC9ob21lY2EuY3JsMIIBNAYIKwYB BQUHAQEEggEmMIIBIjCBtQYIKwYBBQUHMAKGgahsZGFwOi8vL0NOPWhvbWVjYSxD Tj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hbHRkb21haW4yMDAwLERDPXBzY2NvcyxEQz1jb20/ Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwaAYIKwYBBQUHMAKGXGh0dHA6Ly9hZHRlc3QuYWx0ZG9tYWluMjAwMC5w c2Njb3MuY29tL0NlcnRFbnJvbGwvYWR0ZXN0LmFsdGRvbWFpbjIwMDAucHNjY29z LmNvbV9ob21lY2EuY3J0MEsGA1UdEQREMEKgHwYJKwYBBAGCNxkBoBIEENuNPV9r O/hNswSDqOAydGmCH2FkdGVzdC5hbHRkb21haW4yMDAwLnBzY2Nvcy5jb20wDQYJ KoZIhvcNAQEFBQADQQBBwxlOIAYrY7CjsR09PEgdDhGDdcky2VYUQ6sYf8Bict28 jezE705z/+I9heVmrNQESfHPvSEk/bJ/Ge3vG+S4 -END CERTIFICATE- subject=/CN=adtest.altdomain2000.psccos.com issuer=/C=US/ST=CO/L=Colorado Springs/O=Process Software/CN=homeca --- Acceptable client certificate CA names /C=US/O=VeriSign, Inc./OU=Class 1 Public Primary Certification Authority - G2/OU =(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network /C=US/O=VeriSign, Inc./OU=Class 4 Public Primary Certification Authority - G2/OU =(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification Services Division/CN=Thawte Personal Freemail CA/[EMAIL PROTECTED] m /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification Services Division/CN=Thawte Personal Premium CA/[EMAIL PROTECTED] /C=US/O=First Data Digital Certificates Inc./CN=First Data Digital Certificates Inc. Certification
Re: Local Issuer Certificate??????
Hello, $ openssl s_client -connect adtest:636 -CAfile homeca_cert.pem CONNECTED(0003) depth=1 /C=US/ST=CO/L=Colorado Springs/O=Process Software/CN=homeca verify return:1 depth=0 /CN=adtest.altdomain2000.psccos.com verify return:1 --- Certificate chain 0 s:/CN=adtest.altdomain2000.psccos.com i:/C=US/ST=CO/L=Colorado Springs/O=Process Software/CN=homeca --- .. .. Can I assume this is working OK now? This is connecting to an LDAP port on a system. Now looks good. 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-0.9.7l compile on s390x
Trying to compile openssl-0.9.7l on s390x. Able to compile w/o errors using ./config --prefix=/web/software/openssl-0.9.7l --openssldir=/web/software/openssl-0.9.7l. It compiles for s390x, the problem is when I create a self-signed certificate. I am able to create a key but receive Segmentation Fault when self-signing. -Receiving segmentation fault when creating self signed certificate on openssl-0.9.7l. ./openssl genrsa -des3 -out server.key 1024 /web/software/openssl-0.9.7l/bin # more server.key -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,2B84DEC1F098E9CA NZbvungVBVgi9BAsMb0yxYxdVgKxjlib73KA+gTwJv4wJOyRE3jp5hHxPueQkhwz HNcqMR+QXLv9lb/3psHXH5qt9Oflf5zmAiZqKL/xgpSbBTEG+hvE/F5S7QoaE+TN 2242aBPqizb+gbgO/KIayyyRk3HE4+GUq7ghbz7/TVzM7j1Y2QFmeqtCq8dzWuXB oWydcjypFNGbpm1awdLR7eOmmrd+VB+o8w9ZpoHTE+MyrMApRTDpNh5NoupCFheu s0/qv5xlYai1s6I38gRrzRSZD6BJYMV/rcsGG10u1hEv0x6+T8jrEqHLEz8s0nT5 4aYViVezKU6HtE3PX0RkFqZmciy8D/j1Ng+onfrCeOXQtwD3ikPgM2VZDi+xsaOp D2CaHJYGXkjF0YPMc0T5E7iIL4VHSkozHrIUf3Mkd/tjvGrgChegHg3xwINUCSZV g+xxaLVZP7B302+LKljEbeMfmnulq+HaMcnaltcyrWx18qx/ubsgu5DhYUOUdXej +J15pWa7gnnrdL3dKYtG+2cNVxsC6NfSgxUH4Rllu7kc7 -END RSA PRIVATE KEY- ./openssl req -new -key server.key -out server.csr ./openssl rsa -in server.key -out server.key The error appears when running the next command. ./openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt Segmentation fault Any ideas? Thanks in advance. mike == This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and/or attachments. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use of this message. == __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL: connect failed..Please help..
On 05/10/2006, at 4:49 AM, Marek Marcola wrote: Hello, Dear all, ... tls_tcpconn_init: Setting in ACCEPT mode (server) 11(5927) tcpconn_add: hashes: 835, 11 11(5927) handle_new_connect: new connection: 0x422d88f0 24 flags: 0002 11(5927) send2child: to tcp child 0 7(5919), 0x422d88f0 7(5919) received n=4 con=0x422d88f0, fd=20 7(5919) DBG: io_watch_add(0x80ed320, 20, 2, 0x422d88f0), fd_no=1 7(5919) tls_update_fd: New fd is 20 7(5919) tls_accept: Error in SSL: 7(5919) tls_error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number 7(5919) DBG: io_watch_del (0x80ed320, 20, 1, 0x10) fd_no=2 called 7(5919) releasing con 0x422d88f0, state -2, fd=20, id=11 7(5919) extra_data 0x422e8a08 11(5927) handle_tcp_child: reader response= 422d88f0, -2 from 0 11(5927) tcpconn_destroy: destroying connection 0x422d88f0, flags 0002 11(5927) tls_close: Closing SSL connection 11(5927) tls_update_fd: New fd is 24 11(5927) tls_shutdown: Shutdown successful 11(5927) tls_tcpconn_clean: Entered What`s wrong? How to solve the error SSL3_GET_RECORD:wrong version number and SSL: connect failed? From server side, you may get this error when: - server is setup to SSL/TLS and client is connecting in plain mode, for example: $ telnet some_server 443 Escape character is '^]'. lkasdkfgjlasdkfgjsdlkfjgsdfkgjsldkfgjhsdfkgsfgk bytes 2 and 3 must be proper SSL3/TLS1 version specification: 0x0300 - SSL3 0x0301 - TLS1 or for SSL2 (in handshake negotiation) byte 4 and 5 has version information: 0x0200 - SSL2 0x0300 - SSL3 0x0301 - TLS1 and of course using SSL2 client_hello TLS1 may be setup (if supported by client and server) - server is setup to SSL3/TLS1 (not SSL2) and client sends SSL2 client_hello, for example OpenSSL SSL_CTX created with SSLv23_client_method() method sends SSL2 client_hello with version information set to TLS1. But when server is set to understand SSL3/TLS1 only then SSL2 proposition is not recognized correctly (version information is at bytes 4 and 5, not 2 and 3) and we get wrong version number. To correct this, on client side disable SSL2 compatibility handshake if SSL_CTX is created with SSLv23_client_method() with SSL_OP_NO_SSLv2, or on server side create SSL_CTX with SSLv23_server_method() instead of SSLv3_server_method() or TLSv1_server_method(). In other words, both sides should have enabled the same protocols. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ Marek, I'm also getting the same error: LOG7[29231:25188864]: SSL alert (write): fatal: handshake failure LOG3[29231:25188864]: SSL_connect: 1408F10B: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number LOG5[29231:25188864]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket Are you saying that this error is caused by the client sending using a different version of SSL to that which the server is using? From the error message above, the server is using version 3 of SSL, correct? (I'm using the latest version of stunnel and OpenSSL 0.9.7i). If so, the Apple's Mail app must be using an older SSL version? Does anyone know which version it uses? Or can something else be causing this error? Thanks, James. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
CVE-2006-2937, CVE-2006-2940
Hi Dr. Stephen, is there a way to verify/test these vulnerabilities? I have compiled a new version of customized openssl/openssh but how do I know that my openssl/openssh is not vulnerable to these attacks? Thanks, Fei __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Need help: Understanding SSL object in multi-threaded environment
I assume this a reason why OpenSSL has the locking callback functions. No. OpenSSL has the locking callback functions so it can protect internal structures. For example, if two SSL objects internally reference the objects. As long as you use these it is safe to share the object AFAIK. Then when wouldn't it be safe to share the object? The locking callback functions are required for all multithreaded applications or else OpenSSL can't protect its internal state. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Need help: Understanding SSL object in multi-threaded environment
Is it the case that both SSL_read and SSL_write modify the same part of the SSL object ? Yes, but that's not the issue. Could you give some more details about this? Could you throw some more light on the ssl state maintained by the SSL object during SSL_read and SSL_write? I'm not sure why more internal details of how OpenSSL works would be helpful. I've already explained the external interface. Is it safe if I programmatically make sure (say using mutex) that only one thread is accessing the SSL object at any time? Yes. In that case, would it be okay to call SSL_read on one thread and SSL_write on other thread? So long as you didn't call them both on the same SSL object at the same time. Where exactly would the locking callback functions come into picture? The locking callback functions are required to be properly implemented if you are going to use OpenSSL on a multithreaded platform. OpenSSL uses them internally to prevent conflicts. Every sophisticated library that supports multiple threads strikes a balance between thread-safety in the caller and thread-safety in the library itself. This is OpenSSL's balance. It's pretty much the same balance the vast majority of libraries takes. Concurrent calls on the same upper-level object are prohibited. But calls that internally happen to access the same lower-level objects are handled by the library. The only reason it's important to mention that you can't access the same SSL object in multiple threads is that TCP allows this. Otherwise, it would be what you would assume. For example, a typical C++ string library is thread-safe, even if it accesses global structures such as a private memory pool, but you can't manipulate the same string at the same time in two threads. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Need help: Understanding SSL object in multi-threaded environment
I'm sure David will have more to say about how the locking callbacks are used in OpenSSL. But my understanding is that just because you implement these, you still cannot freely call SSL_read/SSL_write from different threads without the proper locking. The reason is because you have direct access to the SSL* obj passed to these 2 functions. The locking callbacks probably provide the library with the locks necessary for it to protect objects it uses internally that need syncrhonization. But the SSL object is used in your code and it is totally up to you to provide the necessary locking yourself. At least that I my understanding, which so far seems to work in my multi-threaded application. Ed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Sent: Thursday, October 05, 2006 3:24 AM To: openssl-users@openssl.org Subject: RE: Need help: Understanding SSL object in multi-threaded environment David, 1. Is OpenSSL thread-safe? Yes (with limitations: an SSL connection may not concurrently be used by multiple threads) This means exactly what it says. A single SSL connection may not be used concurrently by multiple threads. This means it is illegal for one thread to do a 'write' on the connection at the same time another thread might be doing, say, a 'read'. You can share an SSL connection object among threads, but you must protect it yourself with a mutex or similar lock. I assume this a reason why OpenSSL has the locking callback functions. As long as you use these it is safe to share the object AFAIK. Regards, Mark __ 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]
