RE: Can't recognize intermediate CA
Yeah, I realized that. I changed things to include an AKID if the issuer has a SKID, and the issuer's issuer's subject DN and issuer's serial number if not. Got it all working finally, once I had the proxy chain it's intermediate CA. (When it wasn't doing this, I thought to try to add it to the trusted store of the browser, realizing that defeated the purpose of an intermediate CA, but wanted to test. That didn't work, but likely because I forgot the tell the browser what the trust chain rooted at the root CA was FOR.) -Original Message- From: owner-openssl-us...@openssl.org on behalf of Dr. Stephen Henson Sent: Fri 3/13/2009 5:14 AM To: openssl-users@openssl.org Subject: Re: Can't recognize intermediate CA On Thu, Mar 12, 2009, Rene Hollan wrote: > True, but (a) it doesn't hurt to have both, and (b) if the issuer > doesn't have a SKID, AKID issuer/serial takes the place of an AKID > keyid. > The disadvantage is that if you want to support more than one intermediate CA (cross certification for example) and you have issuer+serial in AKID then you'll get a mismatch with any new CA. This has caused issues when some people had an intermediate CA expire before the EE cert. Technically AKID/SKID should just be a hint as to the correct issuer certificate which can be ignored but some software (including OpenSSL currently) requires a match. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org <>
Re: TLS, BIOs, SSL_read/write
Hello, as I can see from code you first set readBIO and writeBIO to socket(scktUpstream ) and that makes TLS negotiation to succeed. Later you set SSL readBIO to mem_bio, and writeBIO to NULL and then try to use writeBIO ( calling SSL_write) - sure it will fail. During negotiation do you receive server responses on scktUpstream? I think so, otherwise I don't see how it would work. Have you tried to not reset SSL BIO with memBIO but have blocking SSL_read - it will return once you socket finish reading.and then just use SSL_write as you do, just again without reseting SSL BIO. hope this will help. Galina On Fri, Mar 13, 2009 at 7:52 PM, Nate Leon wrote: > Greetings, > I am in the process of converting an SMTP/TLS server to use Async IO. > (using IO Completion Ports on Windows) > As such, the previously working style of using SSL_accept, select, and > SSL_read / SSL_write is no longer sufficient. > > Now that I am using WSARecv to do the read, my app is notified when a > buffer is filled with (encrypted) data. > Somebody suggested I stuff that data into a BIO buffer and read it out of > that. > I attempted to use BIO_read but without success. > I seem to have that half working now, looking roughly like this: > (over-simplified for readability) > > // SMTP client requests STARTTLS, server takes these actions: > BIO* m_bioSckt = BIO_new_socket((int)scktUpstream, BIO_NOCLOSE); > SSL* m_ssl = SSL_new(ctx); > SSL_set_accept_state(m_ssl); > SSL_set_bio(m_ssl, m_bioSckt, m_bioSckt); > > // Server sends "220 go ahead" to client, and waits for Client/Server > to negotiate handshake > int nRetCode = SSL_accept(m_ssl); > > // This succeeds - client reports: "New, TLSv1/SSLv3, Cipher is > AES256-SHA, etc..." > // Now client sends command (e.g. "EHLO example.org") which needs to > be decrypted > BIO* m_bioMem = BIO_new_mem_buf(encryptedData, nEncDataSize); > SSL_set_bio(m_ssl, m_bioMem, NULL); > char decryptedData[4096]; > int numBytesRead = SSL_read(m_ssl, decryptedData, sizeof(decryptedData)); > > // SMTP server processes decryptedData and takes appropriate action - > e.g. sends a "250 OK" response > // That response needs to be encrypted before it is sent (WSASend) > BIO* bioMem = BIO_new(BIO_f_buffer()); > SSL_set_bio(m_ssl, NULL, bioMem); > int numBytesWritten = SSL_write(m_ssl, responseData, nRespDataSize); // > fails > BIO_flush(bioMem); > > I am testing using the openssl client: > openssl s_client -starttls smtp -connect localhost:25 -crlf -msg -debug > > The SSL_write seems to fail completely. :( > Am I on the right track here? > Is it the optimal way to go about it? > Also surprising, (at least to me) is that BIO_new_socket and > BIO_new_mem_buf return the identical address in memory, > which makes me think I am really not understanding how this is supposed to > work. > > Any pointers are much appreciated. > > TIA, > n8 > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
TLS, BIOs, SSL_read/write
Greetings, I am in the process of converting an SMTP/TLS server to use Async IO. (using IO Completion Ports on Windows) As such, the previously working style of using SSL_accept, select, and SSL_read / SSL_write is no longer sufficient. Now that I am using WSARecv to do the read, my app is notified when a buffer is filled with (encrypted) data. Somebody suggested I stuff that data into a BIO buffer and read it out of that. I attempted to use BIO_read but without success. I seem to have that half working now, looking roughly like this: (over-simplified for readability) // SMTP client requests STARTTLS, server takes these actions: BIO* m_bioSckt = BIO_new_socket((int)scktUpstream, BIO_NOCLOSE); SSL* m_ssl = SSL_new(ctx); SSL_set_accept_state(m_ssl); SSL_set_bio(m_ssl, m_bioSckt, m_bioSckt); // Server sends "220 go ahead" to client, and waits for Client/Server to negotiate handshake int nRetCode = SSL_accept(m_ssl); // This succeeds - client reports: "New, TLSv1/SSLv3, Cipher is AES256-SHA, etc..." // Now client sends command (e.g. "EHLO example.org") which needs to be decrypted BIO* m_bioMem = BIO_new_mem_buf(encryptedData, nEncDataSize); SSL_set_bio(m_ssl, m_bioMem, NULL); char decryptedData[4096]; int numBytesRead = SSL_read(m_ssl, decryptedData, sizeof(decryptedData)); // SMTP server processes decryptedData and takes appropriate action - e.g. sends a "250 OK" response // That response needs to be encrypted before it is sent (WSASend) BIO* bioMem = BIO_new(BIO_f_buffer()); SSL_set_bio(m_ssl, NULL, bioMem); int numBytesWritten = SSL_write(m_ssl, responseData, nRespDataSize); // fails BIO_flush(bioMem); I am testing using the openssl client: openssl s_client -starttls smtp -connect localhost:25 -crlf -msg -debug The SSL_write seems to fail completely. :( Am I on the right track here? Is it the optimal way to go about it? Also surprising, (at least to me) is that BIO_new_socket and BIO_new_mem_buf return the identical address in memory, which makes me think I am really not understanding how this is supposed to work. Any pointers are much appreciated. TIA, n8 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL 0.9.8e on AIX 64-bit: make test fails
I'm building OpenSSL 0.9.8e on AIX 64-bit. Following 2 commands work fine. ./Configure -lpthreads aix64-gcc -maix64 --prefix=/usr/local/ssl/ --openssldir=/usr/local/ssl/ make make test fails with following end remarks: __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL 0.9.8e on AIX 64-bit: make test fails
I did not find a place to start a new thread. Sorry for writing a problem in reply I'm building OpenSSL 0.9.8e on AIX 64-bit. Following 2 commands work fine. ./Configure -lpthreads aix64-gcc -maix64 --prefix=/usr/local/ssl/ --openssldir=/usr/local/ssl/ make make test fails with following end remarks: __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
AW: openssl-users: cannot sign csr from win2008/e2k7
Dear Romek, thank you for your answer. I don't have any experience with IIS and certificates yet. All I know that the CSR generated on 2003 works, on 2008 it does not. Additionally, the all work with the Windows Server CA (phew, who would have thought that *eg*). Kind Regards, Jens -Ursprüngliche Nachricht- Von: Romek [mailto:rom...@gmail.com] Gesendet: Freitag, 13. März 2009 13:33 An: Jens Schwepe Betreff: Re: openssl-users: cannot sign csr from win2008/e2k7 Hi, I have been having the same issues with Windows 2003/2008 and IIS 6. The error in your request is that you have not got the 129 zeros needed in the enrolmentCSP that are needed (I believe caused by no CSP being assigned for the request) in the certificate wizard. For me, I have found that the only way to get these requests to work is by recreating them again and again until they do as you have no options to change this by default. It may be sensible that you try also with only 1 subjectAltName as you have 4 encoded in your request which may also cause problems. Also, I have found IIS 6 to give out badly encoded Public Keys giving negative values. You seem to have been lucky here! With IIS 6, I am unable to view the certificate requests with most ASN.1 viewers apart from Gutmann's dumpasn1, but I do not find the same with your request. I was testing with commercial CAs and not OpenSSL. Kind regards, Romek Szczesniak rom...@gmail.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Can't recognize intermediate CA
On Thu, Mar 12, 2009, Rene Hollan wrote: > True, but (a) it doesn't hurt to have both, and (b) if the issuer > doesn't have a SKID, AKID issuer/serial takes the place of an AKID > keyid. > The disadvantage is that if you want to support more than one intermediate CA (cross certification for example) and you have issuer+serial in AKID then you'll get a mismatch with any new CA. This has caused issues when some people had an intermediate CA expire before the EE cert. Technically AKID/SKID should just be a hint as to the correct issuer certificate which can be ignored but some software (including OpenSSL currently) requires a match. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Can't recognize intermediate CA
On Thu, Mar 12, 2009, Rene Hollan wrote: > Yup. That fixed it.. At least as far as openssl verify -CAfile > cacert.pem -untrusted intcert2.pem yahoo-x.pem goes. > > Oddly, firefox still rejects the end cert, even though both cacert.pem > and intcert2.pem are in it's trust store. Is it possible that browsers > actually ignore intermediate CA certs in their trust store and expect > servers to provide them? That's the next thing for me to try (if only I > can remember how to do that with openssl... :-)). > Well if you had to add intermediate CAs to browser trust stores they would be of limimted use. The whole idea is that you only need to add the root CA and the browser will automatically trust intermediate CAs it hasn't seen before. The SSL/TLS standards also require sending of the certificate chain (but the root can be excluded). Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
cannot sign csr from win2008/e2k7
Hi, i'm using the fine how-to from http://www.eclectica.ca/howto/ssl-cert-howto.php now for years without problems. It's on Debian Etch, openssl version is OpenSSL 0.9.8c 05 Sep 2006: saruman:~# dpkg -l |grep openssl ii openssl 0.9.8c-4etch4Secure Socket Layer (SSL) binary and related Now we have a Server 2008+E2k7, which shall replace the working 2003 one. However, I cannot sign the CSR generated from 2008 server, it says: saruman:~/ssl/CA# openssl ca -out mittelerde.intern.jk-works.de/cert.pem -config ./openssl.cnf -infiles mittelerde.intern.jk-works.de/certrequest.txt Using configuration from ./openssl.cnf Enter pass phrase for ./private/cakey.pem: Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows commonName :ASN.1 12:'mellon.jk-works.de' organizationalUnitName:ASN.1 12:'Mail Services' organizationName :ASN.1 12:'JK works GbR.' stateOrProvinceName :ASN.1 12:'Bremen' countryName :PRINTABLE:'DE' The stateOrProvinceName field needed to be the same in the CA certificate (Bremen) and the request (Bremen) - This is the CSR generated from New-ExchangeCertificate cmdlet: -BEGIN NEW CERTIFICATE REQUEST- MIIETTCCAzUCAQAwazEbMBkGA1UEAwwSbWVsbG9uLmprLXdvcmtzLmRlMRYwFAYD VQQLDA1NYWlsIFNlcnZpY2VzMRYwFAYDVQQKDA1KSyB3b3JrcyBHYlIuMQ8wDQYD VQQIDAZCcmVtZW4xCzAJBgNVBAYTAkRFMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAxD77mS4q3g5j+hLzm69Tvz6x52IN8eT+Vfmz9oKmSGYTlnO8Smz0 J/gJ68xXOMg7AiXXFV+0jhjRPOoKsxbnk2ryvmxHTKUQ3QfnidxYlWDrCUCCdL+G HqPQfBwCGms2pk05+mOTOd/RV7HHallVqs6VFpAcrlPih7aLTG8ScFVam/8X2pEy tBsXXTBaWM9mlrb91UgaPho/P0RIv1TARCH1klY5KrdHD7PYXswDLCQiwvYrIpN6 WtaaNH41rX6Igy+TyVQbZ2kJY4TbDSBBaDVF8Y5lB37PZpDzPqA83lnrzIKKmF4F 6a+ZX3JfogCNDCMq+hN9yOkZY5c2m+CZIQIDAQABoIIBmzAaBgorBgEEAYI3DQID MQwWCjYuMC42MDAxLjIwVAYJKwYBBAGCNxUUMUcwRQIBBQwdTWl0dGVsZXJkZS5p bnRlcm4uamstd29ya3MuZGUMEUpLV09SS1NcZXhjaGFkbWluDA5wb3dlcnNoZWxs LmV4ZTByBgorBgEEAYI3DQICMWQwYgIBAR5aAE0AaQBjAHIAbwBzAG8AZgB0ACAA UgBTAEEAIABTAEMAaABhAG4AbgBlAGwAIABDAHIAeQBwAHQAbwBnAHIAYQBwAGgA aQBjACAAUAByAG8AdgBpAGQAZQByAwEAMIGyBgkqhkiG9w0BCQ4xgaQwgaEwDgYD VR0PAQH/BAQDAgWgMGIGA1UdEQRbMFmCHW1pdHRlbGVyZGUuaW50ZXJuLmprLXdv cmtzLmRlghJtZWxsb24uamstd29ya3MuZGWCGGF1dG9kaXNjb3Zlci5qay13b3Jr cy5kZYIKbWl0dGVsZXJkZTAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBQ53Tt9Vieq XN6UPMDMes2E9RF+FjANBgkqhkiG9w0BAQUFAAOCAQEAdNrzTzzM4O77iUEo5vjj ZFA6psVzoYP2ICDzwPwTiIv4+IlQglC/9YactpK/q+I6jUTIY5imspKcXJFXIeWB RYkniewe0FKgLPr2FtK1jz1mkZ4Fhs8SJevwzxVI8hLUrjlbsVayoR9fD5NzTLZr U8NpoNMTQdVafWwPGrWuaZGDrKyULdX31wQ30Eub78QNd/zxNO2Gua/IJMyrjoaA YKNWG1oxSzovCAISUsy1nuzBytVOHpNdCrh/f61kTS+961j7KJPUsPox5CP3waLK +Z9ZTVl2g2T0eh9fd7inBgcXrMbOeENytpBawznngpRsAVLAuL500yEmymPi12XJ tQ== -END NEW CERTIFICATE REQUEST- A CSR generated on Server 2003+E2k7 can be signed without problems. Can you give me a hint on what I have to do to sign the new CSR? Thanks in advance, Jens Schwepe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: PBE Key creation
Yeah, I appreciate that. What I can't see in the docs is how the key and IV is defined from the password and if I can do that without calling the openssl enc call. If the key and IV were from an md5 then I could do "echo '1234' | openssl md5". But it isn't md5 and I can't figure out what it is... Dave Thompson-4 wrote: > >> From: owner-openssl-us...@openssl.org On Behalf Of brechmos >> Sent: Thursday, 12 March, 2009 08:25 > >> I am relatively new at openssl and am just figuring out its >> power. One thing > > General suggestion: for any of the openssl commandline > functions, you can get a brief usage display by adding -? . > On a Unix-type installation (I believe including cygwin) > there are also man pages (you may need to adjust your > MANPATH depending on where OpenSSL is installed). > Note that the command for symmetric crypto is actually 'enc'; > 'des3' is really 'enc -des3', 'rc2-ofb' is 'enc -rc2-ofb', etc.; > so the man page is for 'enc' not for a specific ciphername. > >> I do not understand is the key creation. For example, >> >> $ openssl des3 -nosalt -P -in bob.txt >> >> and I type in the password 1234 (not my normal password :-) and >> it comes up > with: >> >> Verifying - enter des-ede3-cbc encryption password: >> key=81DC9BDB52D04DC20036DBD8313ED055CC5776D16A1FB6E4 >> iv =AFA34B18395DA656 >> >> Is there a way to create the key shown above using an ssl command line? >> > From openssl enc -? : > -k passphrase is the next argument > -pass pass phrase source > (and elsewhere several options for arg are given including pass:value) > Hence: > openssl enc -des3 -k 1234 -nosalt > openssl enc -des3 -pass pass:1234 -nosalt > > > Subject to the usual caveat: on some OSes and/or in some situations, > commandline parameters can be seen by other programs, and possibly > other users on a multiuser system; this may be insecure for you. > > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > > -- View this message in context: http://www.nabble.com/PBE-Key-creation-tp22476230p22486863.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Can't recognize intermediate CA
Actually, in addition to the last link I gave, http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/31fe9768dcb00b2c/7fab610c48b40a9c?#7fab610c48b40a9c has a link to the entire thread (which includes a couple more questions and answers). http://is.gd/n9o4 is a short redirect to that URL. -Kyle H On Thu, Mar 12, 2009 at 7:31 PM, Rene Hollan wrote: > Great, just great. > > My changes worked for IE, but not for Firefox. > > Apparently, Firefox does more stringent checking that IE, and indeed, > than OpenSSL s_client ... (which gives a nice cert chain). > > > -Original Message- > From: Rene Hollan > Sent: Thursday, March 12, 2009 6:34 PM > To: 'openssl-users@openssl.org' > Subject: RE: Can't recognize intermediate CA > > Sigh. > > Well, I added the intermediate CA to the cert chain sent by my proxy > (and verified this with wireshark). > > OpenSSL s_client -CAfile cacert.pem -host login.yahoo.com -port 443 > works and shows the trust chain. > > But, Firefox, with cacert.pem loaded into it's trust store still > complains. :-( > > > > -Original Message- > From: Rene Hollan > Sent: Thursday, March 12, 2009 5:39 PM > To: 'openssl-users@openssl.org' > Subject: RE: Can't recognize intermediate CA > > Yup. That fixed it.. At least as far as openssl verify -CAfile > cacert.pem -untrusted intcert2.pem yahoo-x.pem goes. > > Oddly, firefox still rejects the end cert, even though both cacert.pem > and intcert2.pem are in it's trust store. Is it possible that browsers > actually ignore intermediate CA certs in their trust store and expect > servers to provide them? That's the next thing for me to try (if only I > can remember how to do that with openssl... :-)). > > > -Original Message- > From: owner-openssl-us...@openssl.org > [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson > Sent: Thursday, March 12, 2009 4:23 PM > To: openssl-users@openssl.org > Subject: Re: Can't recognize intermediate CA > > > If it's any consolation you aren't alone with that, it gets commented on > quite often so much so in fact that it has an FAQ entry: > > http://www.openssl.org/support/faq.html#USER15 > > You can just leave out the issuer+serial number combination from AKID > too. > > Steve. > -- > Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL > project core developer and freelance consultant. > Homepage: http://www.drh-consultancy.demon.co.uk > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-us...@openssl.org > Automated List Manager majord...@openssl.org > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-us...@openssl.org > Automated List Manager majord...@openssl.org > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org