Re: OT: SSL certificate chain problems
Victor Duchovni [EMAIL PROTECTED] writes: On Wed, Jan 31, 2007 at 01:57:04PM +1300, Peter Gutmann wrote: You use the key in the old root to validate the self-signature in the new root. Since they're the same key, you know that the new root supersedes the expired one. So this is a special trick to extend root CA lifetimes. How widely is this logic implemented, and is extending root CA key lifetime in this manner standard practice? Like a lot of PKI, it's total pot-luck (crapshoot in the US I guess) as to what a particular implementation does when it encounters this situation. It may work, it may not work, it may work under some circumstances, or it may do anything in between. (I've seen some implementations that require a system rebuild (meaning reinstall all your PKI software with the new roots) to roll over roots, all the way through to ones that handle the situation automatically. There really is no way to tell what a particular implemenation will do, apart from trying it out and seeing what happens). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OT: SSL certificate chain problems
On Wed, Jan 31, 2007 at 01:57:04PM +1300, Peter Gutmann wrote: Victor Duchovni [EMAIL PROTECTED] writes: What I don't understand is how the old (finally expired) root helps to validate the new unexpired root, when a verifier has the old root and the server presents the new root in its trust chain. You use the key in the old root to validate the self-signature in the new root. Since they're the same key, you know that the new root supersedes the expired one. Does this actually work with OpenSSL and v3 CA certs that have X509v3 Authority Key Identifier extensions? With these extensions present (default when OpenSSL constructs CA certs, ...), certs whose serial number does not match the serial field in the extension are not considered to be root CA certs (not self-signed), and CA certs sharing the same keys and DN, but carrying different serials, simply don't match. If I roll-back the serial numbers and issue a cert with all the details (including serial number, ...) the same, but just the start/end dates changed to start before the expiration of the verifier's expired CA, and end after today's date, the verifier ends up with a trust chain that starts with the expired cert and fails, regardless of whether the server sends the new root CA cert or not. CA0.pem: serial=C27B874157E381C0 issuer= fixed-ca-dn subject= fixed-ca-dn notBefore=Jan 1 00:00:00 2007 GMT notAfter=Jan 31 00:00:00 2007 GMT ... X509v3 Authority Key Identifier: keyid:CB:C0:45:68:F9:B0:DF:8B:A9:E9:EA:A0:F1:93:A1:C1:6B:7C:96:E4 DirName:fixed-ca-dn serial:C2:7B:87:41:57:E3:81:C0 CA1.pem: serial=C27B874157E381C0 issuer= fixed-ca-dn subject= fixed-ca-dn notBefore=Jan 15 00:00:00 2007 GMT notAfter=Feb 28 00:00:00 2007 GMT ... X509v3 Authority Key Identifier: keyid:CB:C0:45:68:F9:B0:DF:8B:A9:E9:EA:A0:F1:93:A1:C1:6B:7C:96:E4 DirName:fixed-ca-dn serial:C2:7B:87:41:57:E3:81:C0 SRV.pem: - serial=C27B874157E381C1 issuer= fixed-ca-dn subject= server-dn notBefore=Jan 15 00:00:00 2007 GMT notAfter=Feb 28 00:00:00 2007 GMT ... X509v3 Authority Key Identifier: keyid:CB:C0:45:68:F9:B0:DF:8B:A9:E9:EA:A0:F1:93:A1:C1:6B:7C:96:E4 DirName:fixed-ca-dn serial:C2:7B:87:41:57:E3:81:C0 A client with CAfile containing just CA0.pem fails to verify a server configured to send the SRV,CA1 trust chain. My verification callback is called three times and produces: Trace: certificate verification depth=1 verify=0 subject=fixed-ca-dn Error: CA certificate verification failed for peer certificate has expired Trace: certificate verification depth=1 verify=1 subject=fixed-ca-dn Trace: certificate verification depth=0 verify=1 subject=server-dn If the verifier trusts the CA1.pem cert, I see instead: Trace: certificate verification depth=1 verify=1 subject=fixed-ca-dn Trace: certificate verification depth=0 verify=1 subject=fixed-server-dn How does one construct a working (re-issued root CA) example with OpenSSL? Am I setting this up incorrectly, or does OpenSSL not in fact support establishing trust in re-issued root CA via now expired root CAs? I have not tried to do this without the issuer key identifier extension, but don't really expect to find anything different... -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OT: SSL certificate chain problems
Victor Duchovni [EMAIL PROTECTED] writes: What I don't understand is how the old (finally expired) root helps to validate the new unexpired root, when a verifier has the old root and the server presents the new root in its trust chain. You use the key in the old root to validate the self-signature in the new root. Since they're the same key, you know that the new root supersedes the expired one. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OT: SSL certificate chain problems
On Wed, Jan 31, 2007 at 01:57:04PM +1300, Peter Gutmann wrote: Victor Duchovni [EMAIL PROTECTED] writes: What I don't understand is how the old (finally expired) root helps to validate the new unexpired root, when a verifier has the old root and the server presents the new root in its trust chain. You use the key in the old root to validate the self-signature in the new root. Since they're the same key, you know that the new root supersedes the expired one. So this is a special trick to extend root CA lifetimes. How widely is this logic implemented, and is extending root CA key lifetime in this manner standard practice? I may have to revise the Postfix documentation to advise users to send the root cert. My most recent experience is ironically in the opposite direction: Peer finally upgrades from Windows Server 2000 to Windows Server 2003, and replaces unexpired Verisign CA certs (updated at some point in the past in the working Windows 2000) with now expired CA certs that were good way back, when the Windows 2003 CDs were burned :-) -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: OT: SSL certificate chain problems
Victor Duchovni wrote: On Sun, Jan 28, 2007 at 12:47:18PM -0500, Thor Lancelot Simon wrote: That doesn't make sense to me -- the end-of-chain (server or client) certificate won't be signed by _both_ the old and new root, I wouldn't think (does x.509 even make this possible)? Or do I misunderstand? The key extra information is that old and new roots share the same issuer and subject DNs and public key, only the start/expiration dates differ, so in the overlap when both are valid, they are interchangeable, both verify the same (singly-signed) certs. To expand on what Duchovni said, you might want to look into the concept of cross-certificates (which are heavily used with bridges). The surprising thing, at first, is that you can issue any certificate after it was originally issued. I can issue the leaf cert you got from Verisign last year. Tomorrow, I could create my own SS Root CA, and issue a cert for the Verisign Intermediate CA, by putting myself as the Issuer, the Verisign Intermediate CA as the Subject, and putting the Verisign ICA public key in it. Your leaf cert will now chain happily up to either the Verisign SS Root, or my new SS Root. So this is not just a thing that works for renewing self-signed roots. What I don't understand is how the old (finally expired) root helps to validate the new unexpired root, when a verifier has the old root and the server presents the new root in its trust chain. I shouldn't speak for Gutmann, but I assumed that he meant that the server should send the new root *before* the old root expires, so that the client can prepare in advance for the expiry. As an aside, there are some funny issues around having a signature done before the signer cert expired, but deciding *after* the cert has expired, whether to trust it. It was ok yesterday, but maybe it's not ok today -- what has changed...? Geoffrey - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OT: SSL certificate chain problems
Victor Duchovni [EMAIL PROTECTED] writes: Wouldn't the old root also (until it actually expires) verify any certificates signed by the new root? If so, why does a server need to send the new root? Because the client may not have the new root yet, and when they try and verify using the expired root the verification will fail. (There's a lot of potential further complications in there that I'm going to spare people the exposure to, but that's the basic idea). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OT: SSL certificate chain problems
On Sat, Jan 27, 2007 at 02:12:34PM +1300, Peter Gutmann wrote: Victor Duchovni [EMAIL PROTECTED] writes: Wouldn't the old root also (until it actually expires) verify any certificates signed by the new root? If so, why does a server need to send the new root? Because the client may not have the new root yet, and when they try and verify using the expired root the verification will fail. I am curious how the expired trusted old root helps to verify the as yet untrusted new root... Is there a special-case behaviour when the old and new root share the same DN and public key? Is such special-case behaviour standard for trust chain verification implementations (allowing the lifetime of root CAs to be indefinitely extended by issuing new certs with the same keys)? -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OT: SSL certificate chain problems
On Fri, Jan 26, 2007 at 11:42:58AM -0500, Victor Duchovni wrote: On Fri, Jan 26, 2007 at 07:06:00PM +1300, Peter Gutmann wrote: In some cases it may be useful to send the entire chain, one such being when a CA re-issues its root with a new expiry date, as Verisign did when its roots expired in December 1999. The old root can be used to verify the new root. Wouldn't the old root also (until it actually expires) verify any certificates signed by the new root? If so, why does a server need to send the new root? So long as the recipient has either the new or the old root, the chain will be valid. That doesn't make sense to me -- the end-of-chain (server or client) certificate won't be signed by _both_ the old and new root, I wouldn't think (does x.509 even make this possible)? That means that for a party trying to validate a certificate signed by the new root, but who has only the old root, the new root's certificate will be a necessary intermediate step in the chain to the old root, which that party trusts (assuming the new root is signed by the old root, that is). Or do I misunderstand? Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OT: SSL certificate chain problems
On Sun, Jan 28, 2007 at 12:47:18PM -0500, Thor Lancelot Simon wrote: Wouldn't the old root also (until it actually expires) verify any certificates signed by the new root? If so, why does a server need to send the new root? So long as the recipient has either the new or the old root, the chain will be valid. That doesn't make sense to me -- the end-of-chain (server or client) certificate won't be signed by _both_ the old and new root, I wouldn't think (does x.509 even make this possible)? Or do I misunderstand? The key extra information is that old and new roots share the same issuer and subject DNs and public key, only the start/expiration dates differ, so in the overlap when both are valid, they are interchangeable, both verify the same (singly-signed) certs. What I don't understand is how the old (finally expired) root helps to validate the new unexpired root, when a verifier has the old root and the server presents the new root in its trust chain. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OT: SSL certificate chain problems
Victor Duchovni [EMAIL PROTECTED] writes: Generally it is enough for a TLS server or client to present its own certificate and all *intermediate* CA certificates, sending the root CA cert is optional, because if the verifying system trusts the root CA in question, it has a local copy of that root CA cert. In some cases it may be useful to send the entire chain, one such being when a CA re-issues its root with a new expiry date, as Verisign did when its roots expired in December 1999. The old root can be used to verify the new root. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OT: SSL certificate chain problems
On Fri, Jan 26, 2007 at 07:06:00PM +1300, Peter Gutmann wrote: Victor Duchovni [EMAIL PROTECTED] writes: Generally it is enough for a TLS server or client to present its own certificate and all *intermediate* CA certificates, sending the root CA cert is optional, because if the verifying system trusts the root CA in question, it has a local copy of that root CA cert. In some cases it may be useful to send the entire chain, one such being when a CA re-issues its root with a new expiry date, as Verisign did when its roots expired in December 1999. The old root can be used to verify the new root. Wouldn't the old root also (until it actually expires) verify any certificates signed by the new root? If so, why does a server need to send the new root? So long as the recipient has either the new or the old root, the chain will be valid. Is the problem case when the verifier has both roots, and the older of the two has expired? -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OT: SSL certificate chain problems
Am Dienstag, den 23.01.2007, 20:47 -0600 schrieb Travis H.: Verify return code: 21 (unable to verify the first certificate) --- DONE I can't seem to get that certificate chain to have any contents other than what you see above, no matter what I do, and hence can't get rid of the Verify return code: 21... does anyone have any advice on what to do next? URLs or references to other mailing lists welcome. Did you try -CAfile, with this command you can give s_client a file with CAs you trust. If the Thawte Consulting certificate is in this file, you should have no problems with verifying. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: OT: SSL certificate chain problems
Hi, you should provide the whole chain starting from the CA that issued the server cert. Be careful, though, because you should *NOT* provide the root cert in the chain as well. Moreover you should use the: SSLCertificateChainFile not the SSLCACertificateFile (which is for client auth). Cheers, Max. Travis H. wrote: Hi, This is not really typical of the traffic on this list, hence the OT. I send it because I think this is one of the few places where I'll find some people with deep understanding of SSL certs. Recently I had an issue where Google checkout would not accept an SSL certificate because Apache didn't present the entire hierarchy, just the site certificate itself. The CA was Thawte. What Google said was that many browsers supply missing certs as needed, but apparently their software did not. The fix would seem to be easy; just put the right CA root cert in the SSLCACertFile directive. or point to the directory with SSLCACertPath. However, I've tried over and over with various root CA certs downloaded from Thawte, and with one intermediate CA cert, and various combinations thereof, but with no sucess. -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED] [EMAIL PROTECTED] Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063Work Phone: +1 (603) 646-9179 --o smime.p7s Description: S/MIME Cryptographic Signature
