Re: [openssl-users] Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Le 25/09/2012 18:45, Jakob Bohm a écrit :
On 9/25/2012 6:12 PM, Erwann Abalea wrote:
Le 25/09/2012 14:16, Jakob Bohm a écrit :
On 9/25/2012 11:11 AM, Erwann Abalea wrote:
[...]
Any signature algorithm works by dividing the universe of N bit strings
into those that are validsignatures for the object and those that are
not. For most algorithms the valid subset is exactly one of the 2**N
bit strings, for some ECC variants it is two of them, for DSA it is
2**(N/2) of them. [...]
I'll have to re-read this in a quiet environment, with my HAC kept
close. Thanks.
[...]
So there's one more possibility: the CA changes its key, keeps its name
(so it's the same CA), and issues 2 certificates. First one is a
self-signed one with its brand new key. Second one is a self-issued one,
signed by the previous key.
Both this case and the previous one are used by several countries for
CSCA certificates (for passports).
So you say they have an intermediary certificate where
Issuer DN==Subject DN,
but the Issuer keyis not the key in the cert itself. Very weird, unless
there are appropriate key identifiers in thecertificates.
That's right. And that's precisely a self-issued certificate, considered
differently on the validation algorithm. For example, such a certificate
doesn't count for the pathLen constraints.
{subject,authority}KeyIdentifier extensions are not mandatory.
Consider a root CA with a self-signed certificate, with only
digitalSignature set in its keyUsage extension. This CA can then
self-issue another certificate with the cRLSign bit set. That's
different from a CA with 2 self-signed certificates, each one for one
usage. The former is valid for RFC5280 while the latter isn't, both are
valid for X.509.
[hours later]
Another scenario has been used in real world: have the root certificate
contain the hash of the public key of the next root (etc), the subject
name doesn't change. That was used for SET (shortly, I admit), as all CA
certificates were renewed every year. Some kind of forward chaining.
Some of the discussions on this thread seems to indicate that when
both the
A and B certificate are available, OpenSSL sometimes may fail to stop
when
it hits the new (A) CA in the trust store because it does not
distinguish between
its trust store and its collection of cached/preloaded intermediary
certificates
(unlike Windows, which has seperate stores for those two categories).
What I understand from the OP seems to be different from this paragraph.
I grabed the old 1996-2004 VeriSign C3 root certificate, and its renewed
version 1996-2028 (same key, same name). That's your scenario 1.
The Thawte CA certificate doesn't have any authorityKeyIdentifier
extension, and OpenSSL correctly tests each possible certificate,
filtered by their subject name, until the validation is OK.
I assume the Thawte certificate you mention is not the same as the
VeriSign certificate (they havebeen the same company for a long time
now).
The OP talked about www.google.com, I connected and got a 1024bits
intermediate Thawte certificate from 2004, signed by VeriSign C3.
--
Erwann ABALEA
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Bonjour, Le 24/09/2012 21:03, Jakob Bohm a écrit : Does that work with any other serious X.509 validation toolkit? It should. When trying to build a valid certification path, all possibilities have to be tested until one of them succeeds. If a CA gives a good signature, but fails for whatever reason (a non respected constraint, a revoked state, or an expired certificate), then the considered certificate chain is invalid, and the next has to be tested. To make this work (assuming the old root CA cert has not yet expired), the validation code will need to actually verify the End Entity certificate against both public keys, which effectively reduces the algorithm security by allowing twice as many bit strings to be accepted as valid. An EE can be valid under different certificate chains, without reducing the security of anything. Think about cross-certifications. As for trust anchor update scenarios, I know of 3 different scenarios that should be accepted by any good X.509 validation algorithm: 1. Changing expiry or other attributes while keeping the key. Here the CA issues a new self-signed certificate with updated attributes but unchanged key. This needs a manual update of the trust store, as you're introducing a new certificate object not linked to anything. Following X509 rules, you can also change the key. Following RFC5280 ones, you can't (in fact, you can, but it won't be the root of the same PKI). 2. Changing the CA key when the old key has *not* been compromised. Here the CA generates a new key and issues two certificates for it: A. A self-signed new root with a serial number or other variation in one of the subject name components. This is a change in the name of the CA, whence it's a completely different CA. B. A certificate for the new key and the same subject and (optional) SubjectKeyIdentifier as A, but issued by the old root certificate identity and key. That's a self-issued certificate, it's OK until the old CA certificate is not expired. Well described in X.509. Manual update of the trust anchor is still necessary if you want the validation to pass the expiration date of the old CA cert. 3. Setting up the CA to have keys for more than one algorithm (such as RSA 1024 with SHA1 and RSA 4096 with SHA256). In this case, the certificate validation could SHOULD (but might not) match issued end entity certificates to the trust anchor by also comparing signatureAlgorithm in the issued certificate against subjectPublicKeyInfo.algorithm in the candidate issuer cert from the store. The issued certificate will have sha1withRSA or sha256withRSA in its signatureAlgorithm, not sha1withRSA1024 or sha256withRSA4096. A SHA256 certificate (or however you call it) can still produce sha1withRSA signatures. The other way is also possible, of course. -- Erwann ABALEA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Just for the records: my workaround was to check the expiration date while dumping the certificates into the file, and skipping the expired ones. Further, I dump the certificates once a day to avoid issues with certificates expired after doing the dump. regards Klaus On 13.09.2012 17:09, Erik Tkal wrote: I suppose that’s a workaround, but doesn’t address the root cause. Windows can quite happily handle expired certificates still hanging out in trusted stores; I see this all the time as root updates occur and renewed certificates are installed. It seems that a change in OpenSSL broke the previous behaviour that allowed this as well, though we can’t tell if it’s the s_client app or the OpenSSL cert store functionality that changed this. *Erik Tkal** *Juniper OAC/UAC/Pulse Development *From:*owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] *On Behalf Of *Charles Mills *Sent:* Thursday, September 13, 2012 9:42 AM *To:* openssl-users@openssl.org *Subject:* RE: certificate validation issues with openssl 1.0.0 and expired certificates in cafile Would it make sense to delete the expired certificate from the Windows store? Duplicate expired/non expired CA certificates sounds to me like a problem waiting to happen. /Charles/ *From:*owner-openssl-us...@openssl.org mailto:owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] *On Behalf Of *Ashok C *Sent:* Thursday, September 13, 2012 12:49 AM *To:* openssl-users@openssl.org mailto:openssl-users@openssl.org *Subject:* Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile Sending again as the previous email did not appear in list. Is there some problem with the mailing list? -- Ashok On Wed, Sep 12, 2012 at 2:59 PM, Ashok C ash@gmail.com mailto:ash@gmail.com wrote: Hi, I don't think this question was answered. Could you please reply? -- Ashok On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion klaus.mailingli...@pernau.at mailto:klaus.mailingli...@pernau.at wrote: Hi! I wrote a small program which dumps all root certificates from Windows certificate store into a file. Then I use openssl to connect to Google and validate its certificate: openssl s_client -connect www.google.com:443 http://www.google.com:443 -CAfile dump.crt When using openssl0.9.8k or openssl0.9.8x everything works as expected. When using openssl1.0.0g or openssl 1.0.1c the certificate validation fails with: Verify return code: 10 (certificate has expired) CONNECTED(016C) depth=2 C = US, O = VeriSign, Inc., OU = Class 3 Public Primary Certification Authority verify error:num=10:certificate has expired notAfter=Jan 7 23:59:59 2004 GMT verify return:0 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com http://www.google.com i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority When analyzing the cafile with the dumped certificates from Windows certificate store, I found out that there are two certificates for Verisign with identical subject, whereas one is expired, the other not. X.509 Certificate Information: Version: 1 Serial Number (hex): 00e49efdf33ae80ecfa5113e19a4240232 Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Validity: Not Before: Mon Jan 29 00:00:00 UTC 1996 Not After: Wed Jan 07 23:59:59 UTC 2004 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Subject Public Key Algorithm: RSA X.509 Certificate Information: Version: 1 Serial Number (hex): 70bae41d10d92934b638ca7b03ccbabf Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Validity: Not Before: Mon Jan 29 00:00:00 UTC 1996 Not After: Tue Aug 01 23:59:59 UTC 2028 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Subject Public Key Algorithm: RSA Thus, it seems that openssl 0.9.8 just ignores the expired certificate and searches if there is another valid one whereas openssl 1.0.0 stop with the first expired certificate. Is the new behavior the intended behavior? Is it possible to have the old behavior also in new openssl versions? Thanks Klaus __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org mailto:openssl-users@openssl.org Automated List Manager majord...@openssl.org mailto:majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing List
Re: [openssl-users] Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
On 9/25/2012 11:11 AM, Erwann Abalea wrote: Bonjour, Le 24/09/2012 21:03, Jakob Bohm a écrit : Does that work with any other serious X.509 validation toolkit? It should. When trying to build a valid certification path, all possibilities have to be tested until one of them succeeds. If a CA gives a good signature, but fails for whatever reason (a non respected constraint, a revoked state, or an expired certificate), then the considered certificate chain is invalid, and the next has to be tested. Read carefully, I said that if the only way to pick the right candidate is to validate the signature against 2 same-algorithm public keys, then the security of the signature validation is reduced by up to log2(keycount) bits. Anything that can be filtered out without signature checking (such as different algorithms, different key identifies, different key lengths etc.) does not cause that problem. And is OK security wise, but may not be implemented by all (otherwise compliant) X.509 implementations. To make this work (assuming the old root CA cert has not yet expired), the validation code will need to actually verify the End Entity certificate against both public keys, which effectively reduces the algorithm security by allowing twice as many bit strings to be accepted as valid. An EE can be valid under different certificate chains, without reducing the security of anything. Think about cross-certifications. Cross-certifications involve different distinguished names for signature chain building, these can all be verified by building the trusted chain before validating the signatures. As for trust anchor update scenarios, I know of 3 different scenarios that should be accepted by any good X.509 validation algorithm: 1. Changing expiry or other attributes while keeping the key. Here the CA issues a new self-signed certificate with updated attributes but unchanged key. This needs a manual update of the trust store, as you're introducing a new certificate object not linked to anything. Following X509 rules, you can also change the key. Following RFC5280 ones, you can't (in fact, you can, but it won't be the root of the same PKI). Yes, but the trick is that it provides a transitional period (between issuing the new self-signed CA cert and expiry or other limits of the old cert attributes kicking in) during which the issued certificates are fully valid against either cert, thus allowing time to update multiple trust stores across a network (small or world-wide). 2. Changing the CA key when the old key has *not* been compromised. Here the CA generates a new key and issues two certificates for it: A. A self-signed new root with a serial number or other variation in one of the subject name components. This is a change in the name of the CA, whence it's a completely different CA. Yes, but it will still have a sufficiently close name to retain any reputation based human trust. B. A certificate for the new key and the same subject and (optional) SubjectKeyIdentifier as A, but issued by the old root certificate identity and key. That's a self-issued certificate, it's OK until the old CA certificate is not expired. Well described in X.509. Manual update of the trust anchor is still necessary if you want the validation to pass the expiration date of the old CA cert. Actually, this is a cross-certificate from the old CA to the new CA. as you said, well described in the literature. Some of the discussions on this thread seems to indicate that when both the A and B certificate are available, OpenSSL sometimes may fail to stop when it hits the new (A) CA in the trust store because it does not distinguish between its trust store and its collection of cached/preloaded intermediary certificates (unlike Windows, which has seperate stores for those two categories). 3. Setting up the CA to have keys for more than one algorithm (such as RSA 1024 with SHA1 and RSA 4096 with SHA256). In this case, the certificate validation could SHOULD (but might not) match issued end entity certificates to the trust anchor by also comparing signatureAlgorithm in the issued certificate against subjectPublicKeyInfo.algorithm in the candidate issuer cert from the store. The issued certificate will have sha1withRSA or sha256withRSA in its signatureAlgorithm, not sha1withRSA1024 or sha256withRSA4096. I deliberately did not give the OID names for the combinations, just descriptions, that is why I wrote it as multiple space separated words. A SHA256 certificate (or however you call it) can still produce sha1withRSA signatures. The other way is also possible, of course. Yes, but it cannot be validated by an X.509 implementation which does not support SHA256 because of a silly policy to never add new algorithms in updates to older versions, even if thousands of library clients cannot be easily updated to a new library version (this bad policy is in both the OpenSSL project and
Re: [openssl-users] Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Bonjour, Le 25/09/2012 14:16, Jakob Bohm a écrit : On 9/25/2012 11:11 AM, Erwann Abalea wrote: Le 24/09/2012 21:03, Jakob Bohm a écrit : Does that work with any other serious X.509 validation toolkit? It should. And in fact, OpenSSL works correctly, at least versions 1.0.1 (Ubuntu), and 1.1.0 (from sources). The 1.0.1 version displays a warning if it finds the expired certificate first, but the verification goes on with the next certificates, and it finally gives an OK result. That can be checked either by removing the nonexpired certificate from the CAfile or by changing to the CApath mode and using strace to see OpenSSL opens the second CA certificate (named 415660c1.1). When trying to build a valid certification path, all possibilities have to be tested until one of them succeeds. If a CA gives a good signature, but fails for whatever reason (a non respected constraint, a revoked state, or an expired certificate), then the considered certificate chain is invalid, and the next has to be tested. Read carefully, I said that if the only way to pick the right candidate is to validate the signature against 2 same-algorithm public keys, then the security of the signature validation is reduced by up to log2(keycount) bits. ?? Could you elaborate on this? Anything that can be filtered out without signature checking (such as different algorithms, different key identifies, different key lengths etc.) does not cause that problem. And is OK security wise, but may not be implemented by all (otherwise compliant) X.509 implementations. To make this work (assuming the old root CA cert has not yet expired), the validation code will need to actually verify the End Entity certificate against both public keys, which effectively reduces the algorithm security by allowing twice as many bit strings to be accepted as valid. An EE can be valid under different certificate chains, without reducing the security of anything. Think about cross-certifications. Cross-certifications involve different distinguished names for signature chain building, these can all be verified by building the trusted chain before validating the signatures. You're right. The cross-certified entity will have different certificates, each one with a distinct issuer name. As for trust anchor update scenarios, I know of 3 different scenarios that should be accepted by any good X.509 validation algorithm: 1. Changing expiry or other attributes while keeping the key. Here the CA issues a new self-signed certificate with updated attributes but unchanged key. 2. Changing the CA key when the old key has *not* been compromised. Here the CA generates a new key and issues two certificates for it: A. A self-signed new root with a serial number or other variation in one of the subject name components. This is a change in the name of the CA, whence it's a completely different CA. Yes, but it will still have a sufficiently close name to retain any reputation based human trust. What about the DigiCert (Malaysia) against DigiCert, Inc (US) not so old problem? B. A certificate for the new key and the same subject and (optional) SubjectKeyIdentifier as A, but issued by the old root certificate identity and key. That's a self-issued certificate, it's OK until the old CA certificate is not expired. Well described in X.509. Manual update of the trust anchor is still necessary if you want the validation to pass the expiration date of the old CA cert. Actually, this is a cross-certificate from the old CA to the new CA. as you said, well described in the literature. Again, I misread. The case you're describing is really a cross-certificate. So there's one more possibility: the CA changes its key, keeps its name (so it's the same CA), and issues 2 certificates. First one is a self-signed one with its brand new key. Second one is a self-issued one, signed by the previous key. Both this case and the previous one are used by several countries for CSCA certificates (for passports). Some of the discussions on this thread seems to indicate that when both the A and B certificate are available, OpenSSL sometimes may fail to stop when it hits the new (A) CA in the trust store because it does not distinguish between its trust store and its collection of cached/preloaded intermediary certificates (unlike Windows, which has seperate stores for those two categories). What I understand from the OP seems to be different from this paragraph. I grabed the old 1996-2004 VeriSign C3 root certificate, and its renewed version 1996-2028 (same key, same name). That's your scenario 1. The Thawte CA certificate doesn't have any authorityKeyIdentifier extension, and OpenSSL correctly tests each possible certificate, filtered by their subject name, until the validation is OK. 3. Setting up the CA to have keys for more than one algorithm (such as RSA 1024 with SHA1 and RSA 4096 with SHA256). In
Re: [openssl-users] Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
On 9/25/2012 6:12 PM, Erwann Abalea wrote: Bonjour, Le 25/09/2012 14:16, Jakob Bohm a écrit : On 9/25/2012 11:11 AM, Erwann Abalea wrote: Le 24/09/2012 21:03, Jakob Bohm a écrit : Does that work with any other serious X.509 validation toolkit? It should. And in fact, OpenSSL works correctly, at least versions 1.0.1 (Ubuntu), and 1.1.0 (from sources). The 1.0.1 version displays a warning if it finds the expired certificate first, but the verification goes on with the next certificates, and it finally gives an OK result. That can be checked either by removing the nonexpired certificate from the CAfile or by changing to the CApath mode and using strace to see OpenSSL opens the second CA certificate (named 415660c1.1). When trying to build a valid certification path, all possibilities have to be tested until one of them succeeds. If a CA gives a good signature, but fails for whatever reason (a non respected constraint, a revoked state, or an expired certificate), then the considered certificate chain is invalid, and the next has to be tested. Read carefully, I said that if the only way to pick the right candidate is to validate the signature against 2 same-algorithm public keys, then the security of the signature validation is reduced by up to log2(keycount) bits. ?? Could you elaborate on this? Any signature algorithm works by dividing the universe of N bit strings into those that are validsignatures for the object and those that are not. For most algorithms the valid subset is exactly one of the 2**N bit strings, for some ECC variants it is two of them, for DSA it is 2**(N/2) of them. By simple logic, log2 of the fraction of invalid to valid bit strings is a hard upper bound on the security of the signature algorithm (because of the trivial try-many-sigs-until-one-is-valid brute force attack). Now adding code outside the algorithm which accepts two or more different keys obviously increases the number bit strings that are valid, thus reducing that upper bound by log2(number of accepted keys). For RSA this does not matter much as the security of an N bit RSA key is a lot less than N bits. But for DSA, ECC algorithms and other algorithms whose expected security is at or close to the upper bound, this is a security reduction. Anything that can be filtered out without signature checking (such as different algorithms, different key identifies, different key lengths etc.) does not cause that problem. And is OK security wise, but may not be implemented by all (otherwise compliant) X.509 implementations. To make this work (assuming the old root CA cert has not yet expired), the validation code will need to actually verify the End Entity certificate against both public keys, which effectively reduces the algorithm security by allowing twice as many bit strings to be accepted as valid. An EE can be valid under different certificate chains, without reducing the security of anything. Think about cross-certifications. Cross-certifications involve different distinguished names for signature chain building, these can all be verified by building the trusted chain before validating the signatures. You're right. The cross-certified entity will have different certificates, each one with a distinct issuer name. As for trust anchor update scenarios, I know of 3 different scenarios that should be accepted by any good X.509 validation algorithm: 1. Changing expiry or other attributes while keeping the key. Here the CA issues a new self-signed certificate with updated attributes but unchanged key. 2. Changing the CA key when the old key has *not* been compromised. Here the CA generates a new key and issues two certificates for it: A. A self-signed new root with a serial number or other variation in one of the subject name components. This is a change in the name of the CA, whence it's a completely different CA. Yes, but it will still have a sufficiently close name to retain any reputation based human trust. What about the DigiCert (Malaysia) against DigiCert, Inc (US) not so old problem? Yep, and probably did a lot of real world damage to the innocent DigiCert. B. A certificate for the new key and the same subject and (optional) SubjectKeyIdentifier as A, but issued by the old root certificate identity and key. That's a self-issued certificate, it's OK until the old CA certificate is not expired. Well described in X.509. Manual update of the trust anchor is still necessary if you want the validation to pass the expiration date of the old CA cert. Actually, this is a cross-certificate from the old CA to the new CA. as you said, well described in the literature. Again, I misread. The case you're describing is really a cross-certificate. So there's one more possibility: the CA changes its key, keeps its name (so it's the same CA), and issues 2 certificates. First one is a self-signed one with its
Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
On 9/13/2012 3:41 PM, Charles Mills wrote:
Would it make sense to delete the expired certificate from the Windows
store? Duplicate expired/non expired CA certificates sounds to me like a
problem waiting to happen.
/Charles/
Windows has built in support for using and checking time stamping
countersignatures in PKCS7 signatures. If the countersignature is
signed with a currently valid certificate with the time stamping
extended usage enabled, then the outer PKCS7 signature and its
certificate is checked as if the current time was the one certified
by the time stamp (but still using up to date revocation
information, paying attention to revocation reasons and dates).
Thus the Windows certificate store has good reason to keep around
expired CA certificates going back to ca. 1996 (when Microsoft
released the first version supporting time stamped signatures).
P.S.
I see no technical reason why such time stamp countersignature
support could not be added to the OpenSSL core code.
The validation side implementation involves a few standard OIDs
(1.3.6.1.5.5.7.3.8 = timeStamping extended key usage,
1.2.840.113549.1.9.6 = counterSignature
unauthenticated attribute and 1.2.840.113549.1.9.5 signingTime
authenticated attribute). The countersignature specifies the
signed data type to be 1.2.840.113549.1.7.1=data, but the
signed data is really the encryptedDigest/signatureValue from
the enclosing SignerInfo being countersigned (as per
PKCS#9/RFC2985 section 5.3.6). The timeStamp indicated by
a counterSignature made by an entity with the timeStamping
extended key usage is simply the standard signingTime
authenticated attribute in the counterSignature itself.
On the signing side, the signer simply submits his
encryptedDigest/signatureValue to a time stamping service he has
a contract with, using a simplified historic protocol as follows:
POST url with Accept: application/octet-string Content-Type:
application/octet-string The post data is Base64 of DER of
SEQUENCE { -- Attribute
type OID -- must be 1.3.6.1.4.1.311.3.2.1 =timeStampRequest
SEQUENCE { -- This is a PKCS#7 ContentInfo, see RFC2315
content Type OID -- must be 1.2.840.113549.1.7.1 =data
content [0] EXPLICIT OCTET STRING
-- must be the outer encryptedDigest
}
}
}
Response if successful is a 200 HTTP status with Content-Type:
application/octet-string and a value which is Base64 of DER of
a PKCS#7/CMS SignedData where encapContentInfo is the ContentInfo
from the request. The time is indicated by the standard
signingTime authenticated attribute in the only SignerInfo in
signerInfos)
This historic time stamping protocol is necessary because the
RFC3161 protocol returns a signature which is not a valid RFC2985
counterSignature.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Hi,
One more observation was made here in another test case.
*Configuration:*
One old root CA certificate oldca.pem with subject name say, C=IN
One new root CA certificate newca.pem with same subject name.
One EE certificate, ee.pem issued by new root CA.
*Test case 1:*
Using CAFile option in openssl verify of the ee.pem,
If oldca.pem is placed on top and newca.pem below, verification fails.
i.e., cat oldca.pem combined.pem;cat newca.pem combined.pem
*Test case 2:*
If newca.pem is placed on top and oldca.pem below that, verification
succeeds.
i.e., cat newca.pem combined.pem; cat oldca.pemcombined.pem
Test case 1 does not seem to correct behaviour as the trust store contains
newca.pem. Ideally the lookup needs to verify ee.pem with the newca.pem.
P.S. The CA and EE certificates are v3 but do not contain AKI or SKI fields.
--
Ashok
On Mon, Sep 24, 2012 at 6:50 PM, Jakob Bohm jb-open...@wisemo.com wrote:
On 9/13/2012 3:41 PM, Charles Mills wrote:
Would it make sense to delete the expired certificate from the Windows
store? Duplicate expired/non expired CA certificates sounds to me like a
problem waiting to happen.
/Charles/
Windows has built in support for using and checking time stamping
countersignatures in PKCS7 signatures. If the countersignature is signed
with a currently valid certificate with the time stamping
extended usage enabled, then the outer PKCS7 signature and its certificate
is checked as if the current time was the one certified
by the time stamp (but still using up to date revocation
information, paying attention to revocation reasons and dates).
Thus the Windows certificate store has good reason to keep around
expired CA certificates going back to ca. 1996 (when Microsoft
released the first version supporting time stamped signatures).
P.S.
I see no technical reason why such time stamp countersignature
support could not be added to the OpenSSL core code.
The validation side implementation involves a few standard OIDs
(1.3.6.1.5.5.7.3.8 = timeStamping extended key usage, 1.2.840.113549.1.9.6
= counterSignature
unauthenticated attribute and 1.2.840.113549.1.9.5 signingTime
authenticated attribute). The countersignature specifies the
signed data type to be 1.2.840.113549.1.7.1=data, but the
signed data is really the encryptedDigest/signatureValue from
the enclosing SignerInfo being countersigned (as per
PKCS#9/RFC2985 section 5.3.6). The timeStamp indicated by
a counterSignature made by an entity with the timeStamping
extended key usage is simply the standard signingTime
authenticated attribute in the counterSignature itself.
On the signing side, the signer simply submits his
encryptedDigest/signatureValue to a time stamping service he has
a contract with, using a simplified historic protocol as follows:
POST url with Accept: application/octet-string Content-Type:
application/octet-string The post data is Base64 of DER of
SEQUENCE { -- Attribute
type OID -- must be 1.3.6.1.4.1.311.3.2.1 =timeStampRequest
SEQUENCE { -- This is a PKCS#7 ContentInfo, see RFC2315
content Type OID -- must be 1.2.840.113549.1.7.1 =data
content [0] EXPLICIT OCTET STRING
-- must be the outer encryptedDigest
}
}
}
Response if successful is a 200 HTTP status with Content-Type:
application/octet-string and a value which is Base64 of DER of
a PKCS#7/CMS SignedData where encapContentInfo is the ContentInfo
from the request. The time is indicated by the standard
signingTime authenticated attribute in the only SignerInfo in
signerInfos)
This historic time stamping protocol is necessary because the
RFC3161 protocol returns a signature which is not a valid RFC2985
counterSignature.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
__**__**__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Hi,
In your test case which fields actually differ between the
old root CA certificate and the new root CA certificate?
P.S.
Please do not use those 3 letter abbreviations of certificate
field names, very few people know those abbreviations.
For the benefit of other readers:
I think Ashok was referring to AuthorityKeyIdentifier and
SubjectKeyIdentifier fieldsbeing absent from the root
CA certificates in his scenario.
On 9/24/2012 6:26 PM, Ashok C wrote:
Hi,
One more observation was made here in another test case.
_*Configuration:*_
One old root CA certificate oldca.pem with subject name say, C=IN
One new root CA certificate newca.pem with same subject name.
One EE certificate, ee.pem issued by new root CA.
_*Test case 1:*_
Using CAFile option in openssl verify of the ee.pem,
If oldca.pem is placed on top and newca.pem below, verification fails.
i.e., cat oldca.pem combined.pem;cat newca.pem combined.pem
_*Test case 2:*_
If newca.pem is placed on top and oldca.pem below that, verification
succeeds.
i.e., cat newca.pem combined.pem; cat oldca.pemcombined.pem
Test case 1 does not seem to correct behaviour as the trust store
contains newca.pem. Ideally the lookup needs to verify ee.pem with the
newca.pem.
P.S. The CA and EE certificates are v3 but do not contain AKI or SKI
fields.
--
Ashok
On Mon, Sep 24, 2012 at 6:50 PM, Jakob Bohm jb-open...@wisemo.com
mailto:jb-open...@wisemo.com wrote:
On 9/13/2012 3:41 PM, Charles Mills wrote:
Would it make sense to delete the expired certificate from the
Windows
store? Duplicate expired/non expired CA certificates sounds to
me like a
problem waiting to happen.
/Charles/
Windows has built in support for using and checking time stamping
countersignatures in PKCS7 signatures. If the countersignature is
signed with a currently valid certificate with the time stamping
extended usage enabled, then the outer PKCS7 signature and its
certificate is checked as if the current time was the one certified
by the time stamp (but still using up to date revocation
information, paying attention to revocation reasons and dates).
Thus the Windows certificate store has good reason to keep around
expired CA certificates going back to ca. 1996 (when Microsoft
released the first version supporting time stamped signatures).
P.S.
I see no technical reason why such time stamp countersignature
support could not be added to the OpenSSL core code.
The validation side implementation involves a few standard OIDs
(1.3.6.1.5.5.7.3.8 = timeStamping extended key usage,
1.2.840.113549.1.9.6 = counterSignature
unauthenticated attribute and 1.2.840.113549.1.9.5 signingTime
authenticated attribute). The countersignature specifies the
signed data type to be 1.2.840.113549.1.7.1=data, but the
signed data is really the encryptedDigest/signatureValue from
the enclosing SignerInfo being countersigned (as per
PKCS#9/RFC2985 section 5.3.6). The timeStamp indicated by
a counterSignature made by an entity with the timeStamping
extended key usage is simply the standard signingTime
authenticated attribute in the counterSignature itself.
On the signing side, the signer simply submits his
encryptedDigest/signatureValue to a time stamping service he has
a contract with, using a simplified historic protocol as follows:
POST url with Accept: application/octet-string Content-Type:
application/octet-string The post data is Base64 of DER of
SEQUENCE { -- Attribute
type OID -- must be 1.3.6.1.4.1.311.3.2.1 =timeStampRequest
SEQUENCE { -- This is a PKCS#7 ContentInfo, see RFC2315
content Type OID -- must be 1.2.840.113549.1.7.1 =data
content [0] EXPLICIT OCTET STRING
-- must be the outer encryptedDigest
}
}
}
Response if successful is a 200 HTTP status with Content-Type:
application/octet-string and a value which is Base64 of DER of
a PKCS#7/CMS SignedData where encapContentInfo is the ContentInfo
from the request. The time is indicated by the standard
signingTime authenticated attribute in the only SignerInfo in
signerInfos)
This historic time stamping protocol is necessary because the
RFC3161 protocol returns a signature which is not a valid RFC2985
counterSignature.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
tel:%2B45%2031%2013%2016%2010
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
__
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Only the private and public keys are different.. Rest of the fields are
same.. Basically I am simulating the trust anchor update related scenarios..
And yes Jacob, thanks for indicating, I'll make sure I don't use such
abbreviations from here on..
Ashok
On Sep 24, 2012 11:25 PM, Jakob Bohm jb-open...@wisemo.com wrote:
Hi,
In your test case which fields actually differ between the
old root CA certificate and the new root CA certificate?
P.S.
Please do not use those 3 letter abbreviations of certificate
field names, very few people know those abbreviations.
For the benefit of other readers:
I think Ashok was referring to AuthorityKeyIdentifier and
SubjectKeyIdentifier fieldsbeing absent from the root
CA certificates in his scenario.
On 9/24/2012 6:26 PM, Ashok C wrote:
Hi,
One more observation was made here in another test case.
_*Configuration:*_
One old root CA certificate oldca.pem with subject name say, C=IN
One new root CA certificate newca.pem with same subject name.
One EE certificate, ee.pem issued by new root CA.
_*Test case 1:*_
Using CAFile option in openssl verify of the ee.pem,
If oldca.pem is placed on top and newca.pem below, verification fails.
i.e., cat oldca.pem combined.pem;cat newca.pem combined.pem
_*Test case 2:*_
If newca.pem is placed on top and oldca.pem below that, verification
succeeds.
i.e., cat newca.pem combined.pem; cat oldca.pemcombined.pem
Test case 1 does not seem to correct behaviour as the trust store
contains newca.pem. Ideally the lookup needs to verify ee.pem with the
newca.pem.
P.S. The CA and EE certificates are v3 but do not contain AKI or SKI
fields.
--
Ashok
On Mon, Sep 24, 2012 at 6:50 PM, Jakob Bohm jb-open...@wisemo.com
mailto:jb-open...@wisemo.com** wrote:
On 9/13/2012 3:41 PM, Charles Mills wrote:
Would it make sense to delete the expired certificate from the
Windows
store? Duplicate expired/non expired CA certificates sounds to
me like a
problem waiting to happen.
/Charles/
Windows has built in support for using and checking time stamping
countersignatures in PKCS7 signatures. If the countersignature is
signed with a currently valid certificate with the time stamping
extended usage enabled, then the outer PKCS7 signature and its
certificate is checked as if the current time was the one certified
by the time stamp (but still using up to date revocation
information, paying attention to revocation reasons and dates).
Thus the Windows certificate store has good reason to keep around
expired CA certificates going back to ca. 1996 (when Microsoft
released the first version supporting time stamped signatures).
P.S.
I see no technical reason why such time stamp countersignature
support could not be added to the OpenSSL core code.
The validation side implementation involves a few standard OIDs
(1.3.6.1.5.5.7.3.8 = timeStamping extended key usage,
1.2.840.113549.1.9.6 = counterSignature
unauthenticated attribute and 1.2.840.113549.1.9.5 signingTime
authenticated attribute). The countersignature specifies the
signed data type to be 1.2.840.113549.1.7.1=data, but the
signed data is really the encryptedDigest/signatureValue from
the enclosing SignerInfo being countersigned (as per
PKCS#9/RFC2985 section 5.3.6). The timeStamp indicated by
a counterSignature made by an entity with the timeStamping
extended key usage is simply the standard signingTime
authenticated attribute in the counterSignature itself.
On the signing side, the signer simply submits his
encryptedDigest/signatureValue to a time stamping service he has
a contract with, using a simplified historic protocol as follows:
POST url with Accept: application/octet-string Content-Type:
application/octet-string The post data is Base64 of DER of
SEQUENCE { -- Attribute
type OID -- must be 1.3.6.1.4.1.311.3.2.1 =timeStampRequest
SEQUENCE { -- This is a PKCS#7 ContentInfo, see RFC2315
content Type OID -- must be 1.2.840.113549.1.7.1 =data
content [0] EXPLICIT OCTET STRING
-- must be the outer encryptedDigest
}
}
}
Response if successful is a 200 HTTP status with Content-Type:
application/octet-string and a value which is Base64 of DER of
a PKCS#7/CMS SignedData where encapContentInfo is the ContentInfo
from the request. The time is indicated by the standard
signingTime authenticated attribute in the only SignerInfo in
signerInfos)
This historic time stamping protocol is necessary because the
RFC3161 protocol returns a signature which is not a valid RFC2985
counterSignature.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Does that work with any other serious X.509 validation toolkit? To make this work (assuming the old root CA cert has not yet expired), the validation code will need to actually verify the End Entity certificate against both public keys, which effectively reduces the algorithm security by allowing twice as many bit strings to be accepted as valid. Filtering based on criteria that do not involve actual signature validation would be cryptographically safe, but when falling back to validating against multiple signatures, extra care is needed for the above reason. As for trust anchor update scenarios, I know of 3 different scenarios that should be accepted by any good X.509 validation algorithm: 1. Changing expiry or other attributes while keeping the key. Here the CA issues a new self-signed certificate with updated attributes but unchanged key. 2. Changing the CA key when the old key has *not* been compromised. Here the CA generates a new key and issues two certificates for it: A. A self-signed new root with a serial number or other variation in one of the subject name components. B. A certificate for the new key and the same subject and (optional) SubjectKeyIdentifier as A, but issued by the old root certificate identity and key. End Entities with certificates issued with the new key reference the modified subject as authority and should be configured to supply the transitional B certificate in chains sent to other end entities. Such end entities should then succeed validating against either the old root CA (via the B certificate supplied) or the new root CA (via finding it as a locally configured trust anchor). This is the scenario used by at least one major CA for its upgrade to larger keys, and SSL servers that forget the B certificate in the supplied chain get rejected by at least one common platform version (Android 2.3) because it only includes the old trust root in its store and uses an underdocumented BouncyCastly store format thus preventing the efficient deployment of the new A cert. 3. Setting up the CA to have keys for more than one algorithm (such as RSA 1024 with SHA1 and RSA 4096 with SHA256). In this case, the certificate validation could SHOULD (but might not) match issued end entity certificates to the trust anchor by also comparing signatureAlgorithm in the issued certificate against subjectPublicKeyInfo.algorithm in the candidate issuer cert from the store. However because not all clients are going to do that, it is still recommended that the CA follows the scenario 2 procedures, except when it is a test CA for verifying handling of this scenario in X.509 implementations. On 9/24/2012 8:01 PM, Ashok C wrote: Only the private and public keys are different.. Rest of the fields are same.. Basically I am simulating the trust anchor update related scenarios.. And yes Jacob, thanks for indicating, I'll make sure I don't use such abbreviations from here on.. Ashok On Sep 24, 2012 11:25 PM, Jakob Bohm jb-open...@wisemo.com mailto:jb-open...@wisemo.com wrote: Hi, In your test case which fields actually differ between the old root CA certificate and the new root CA certificate? P.S. Please do not use those 3 letter abbreviations of certificate field names, very few people know those abbreviations. For the benefit of other readers: I think Ashok was referring to AuthorityKeyIdentifier and SubjectKeyIdentifier fieldsbeing absent from the root CA certificates in his scenario. On 9/24/2012 6:26 PM, Ashok C wrote: Hi, One more observation was made here in another test case. _*Configuration:*_ One old root CA certificate oldca.pem with subject name say, C=IN One new root CA certificate newca.pem with same subject name. One EE certificate, ee.pem issued by new root CA. _*Test case 1:*_ Using CAFile option in openssl verify of the ee.pem, If oldca.pem is placed on top and newca.pem below, verification fails. i.e., cat oldca.pem combined.pem;cat newca.pem combined.pem _*Test case 2:*_ If newca.pem is placed on top and oldca.pem below that, verification succeeds. i.e., cat newca.pem combined.pem; cat oldca.pemcombined.pem Test case 1 does not seem to correct behaviour as the trust store contains newca.pem. Ideally the lookup needs to verify ee.pem with the newca.pem. P.S. The CA and EE certificates are v3 but do not contain AKI or SKI fields. -- Ashok On Mon, Sep 24, 2012 at 6:50 PM, Jakob Bohm jb-open...@wisemo.com mailto:jb-open...@wisemo.com mailto:jb-open...@wisemo.com mailto:jb-open...@wisemo.com__ wrote: On 9/13/2012 3:41 PM, Charles Mills wrote: Would it make sense to delete the expired certificate from the Windows
Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Thanks Jacob, but in the three scenarios you mentioned, the first one *does not* seem to be supported by openssl 1.0.0*. I think that was the subject of this email thread in the beginning. 1. Changing expiry or other attributes while keeping the key. Here the CA issues a new self-signed certificate with updated attributes but unchanged key. Here, if the expired one is encountered first, openSSL does not lookup the non-expired CA certificate. This is then a bug right? -- Ashok On Tue, Sep 25, 2012 at 12:33 AM, Jakob Bohm jb-open...@wisemo.com wrote: Does that work with any other serious X.509 validation toolkit? To make this work (assuming the old root CA cert has not yet expired), the validation code will need to actually verify the End Entity certificate against both public keys, which effectively reduces the algorithm security by allowing twice as many bit strings to be accepted as valid. Filtering based on criteria that do not involve actual signature validation would be cryptographically safe, but when falling back to validating against multiple signatures, extra care is needed for the above reason. As for trust anchor update scenarios, I know of 3 different scenarios that should be accepted by any good X.509 validation algorithm: 1. Changing expiry or other attributes while keeping the key. Here the CA issues a new self-signed certificate with updated attributes but unchanged key. 2. Changing the CA key when the old key has *not* been compromised. Here the CA generates a new key and issues two certificates for it: A. A self-signed new root with a serial number or other variation in one of the subject name components. B. A certificate for the new key and the same subject and (optional) SubjectKeyIdentifier as A, but issued by the old root certificate identity and key. End Entities with certificates issued with the new key reference the modified subject as authority and should be configured to supply the transitional B certificate in chains sent to other end entities. Such end entities should then succeed validating against either the old root CA (via the B certificate supplied) or the new root CA (via finding it as a locally configured trust anchor). This is the scenario used by at least one major CA for its upgrade to larger keys, and SSL servers that forget the B certificate in the supplied chain get rejected by at least one common platform version (Android 2.3) because it only includes the old trust root in its store and uses an underdocumented BouncyCastly store format thus preventing the efficient deployment of the new A cert. 3. Setting up the CA to have keys for more than one algorithm (such as RSA 1024 with SHA1 and RSA 4096 with SHA256). In this case, the certificate validation could SHOULD (but might not) match issued end entity certificates to the trust anchor by also comparing signatureAlgorithm in the issued certificate against subjectPublicKeyInfo.algorithm in the candidate issuer cert from the store. However because not all clients are going to do that, it is still recommended that the CA follows the scenario 2 procedures, except when it is a test CA for verifying handling of this scenario in X.509 implementations. On 9/24/2012 8:01 PM, Ashok C wrote: Only the private and public keys are different.. Rest of the fields are same.. Basically I am simulating the trust anchor update related scenarios.. And yes Jacob, thanks for indicating, I'll make sure I don't use such abbreviations from here on.. Ashok On Sep 24, 2012 11:25 PM, Jakob Bohm jb-open...@wisemo.com mailto:jb-open...@wisemo.com** wrote: Hi, In your test case which fields actually differ between the old root CA certificate and the new root CA certificate? P.S. Please do not use those 3 letter abbreviations of certificate field names, very few people know those abbreviations. For the benefit of other readers: I think Ashok was referring to AuthorityKeyIdentifier and SubjectKeyIdentifier fieldsbeing absent from the root CA certificates in his scenario. On 9/24/2012 6:26 PM, Ashok C wrote: Hi, One more observation was made here in another test case. _*Configuration:*_ One old root CA certificate oldca.pem with subject name say, C=IN One new root CA certificate newca.pem with same subject name. One EE certificate, ee.pem issued by new root CA. _*Test case 1:*_ Using CAFile option in openssl verify of the ee.pem, If oldca.pem is placed on top and newca.pem below, verification fails. i.e., cat oldca.pem combined.pem;cat newca.pem combined.pem _*Test case 2:*_ If newca.pem is placed on top and oldca.pem below that, verification succeeds. i.e., cat newca.pem combined.pem; cat oldca.pemcombined.pem Test case 1 does not seem to
Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Gentle reminder .. Just want to know if this is a bug or intended behaviour. -- Ashok On Fri, Sep 14, 2012 at 3:12 PM, Ashok C ash@gmail.com wrote: Hi Etkal, s_client app or the OpenSSL cert store functionality that changed this. The problem is with the openSSL store itself, as I had tested this with my own SSL client and observed the same behaviour. -- Ashok On Thu, Sep 13, 2012 at 8:39 PM, Erik Tkal et...@juniper.net wrote: I suppose that’s a workaround, but doesn’t address the root cause. Windows can quite happily handle expired certificates still hanging out in trusted stores; I see this all the time as root updates occur and renewed certificates are installed. It seems that a change in OpenSSL broke the previous behaviour that allowed this as well, though we can’t tell if it’s the s_client app or the OpenSSL cert store functionality that changed this. *Erik Tkal** *Juniper OAC/UAC/Pulse Development ** ** *From:* owner-openssl-us...@openssl.org [mailto: owner-openssl-us...@openssl.org] *On Behalf Of *Charles Mills *Sent:* Thursday, September 13, 2012 9:42 AM *To:* openssl-users@openssl.org *Subject:* RE: certificate validation issues with openssl 1.0.0 and expired certificates in cafile ** ** Would it make sense to delete the expired certificate from the Windows store? Duplicate expired/non expired CA certificates sounds to me like a problem waiting to happen. ** ** *Charles* *From:* owner-openssl-us...@openssl.org [ mailto:owner-openssl-us...@openssl.org owner-openssl-us...@openssl.org] *On Behalf Of *Ashok C *Sent:* Thursday, September 13, 2012 12:49 AM *To:* openssl-users@openssl.org *Subject:* Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile ** ** Sending again as the previous email did not appear in list. Is there some problem with the mailing list? -- Ashok On Wed, Sep 12, 2012 at 2:59 PM, Ashok C ash@gmail.com wrote: Hi, I don't think this question was answered. Could you please reply? -- Ashok ** ** On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion klaus.mailingli...@pernau.at wrote: Hi! I wrote a small program which dumps all root certificates from Windows certificate store into a file. Then I use openssl to connect to Google and validate its certificate: openssl s_client -connect www.google.com:443 -CAfile dump.crt When using openssl0.9.8k or openssl0.9.8x everything works as expected. When using openssl1.0.0g or openssl 1.0.1c the certificate validation fails with: Verify return code: 10 (certificate has expired) CONNECTED(016C) depth=2 C = US, O = VeriSign, Inc., OU = Class 3 Public Primary Certification Authority verify error:num=10:certificate has expired notAfter=Jan 7 23:59:59 2004 GMT verify return:0 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority When analyzing the cafile with the dumped certificates from Windows certificate store, I found out that there are two certificates for Verisign with identical subject, whereas one is expired, the other not. X.509 Certificate Information: Version: 1 Serial Number (hex): 00e49efdf33ae80ecfa5113e19a4240232 Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Validity: Not Before: Mon Jan 29 00:00:00 UTC 1996 Not After: Wed Jan 07 23:59:59 UTC 2004 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Subject Public Key Algorithm: RSA X.509 Certificate Information: Version: 1 Serial Number (hex): 70bae41d10d92934b638ca7b03ccbabf Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Validity: Not Before: Mon Jan 29 00:00:00 UTC 1996 Not After: Tue Aug 01 23:59:59 UTC 2028 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Subject Public Key Algorithm: RSA Thus, it seems that openssl 0.9.8 just ignores the expired certificate and searches if there is another valid one whereas openssl 1.0.0 stop with the first expired certificate. Is the new behavior the intended behavior? Is it possible to have the old behavior also in new openssl versions? Thanks Klaus __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org*** * ** ** ** **
Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Hi Etkal, s_client app or the OpenSSL cert store functionality that changed this. The problem is with the openSSL store itself, as I had tested this with my own SSL client and observed the same behaviour. -- Ashok On Thu, Sep 13, 2012 at 8:39 PM, Erik Tkal et...@juniper.net wrote: I suppose that’s a workaround, but doesn’t address the root cause. Windows can quite happily handle expired certificates still hanging out in trusted stores; I see this all the time as root updates occur and renewed certificates are installed. It seems that a change in OpenSSL broke the previous behaviour that allowed this as well, though we can’t tell if it’s the s_client app or the OpenSSL cert store functionality that changed this. *Erik Tkal** *Juniper OAC/UAC/Pulse Development ** ** *From:* owner-openssl-us...@openssl.org [mailto: owner-openssl-us...@openssl.org] *On Behalf Of *Charles Mills *Sent:* Thursday, September 13, 2012 9:42 AM *To:* openssl-users@openssl.org *Subject:* RE: certificate validation issues with openssl 1.0.0 and expired certificates in cafile ** ** Would it make sense to delete the expired certificate from the Windows store? Duplicate expired/non expired CA certificates sounds to me like a problem waiting to happen. ** ** *Charles* *From:* owner-openssl-us...@openssl.org [ mailto:owner-openssl-us...@openssl.org owner-openssl-us...@openssl.org] *On Behalf Of *Ashok C *Sent:* Thursday, September 13, 2012 12:49 AM *To:* openssl-users@openssl.org *Subject:* Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile ** ** Sending again as the previous email did not appear in list. Is there some problem with the mailing list? -- Ashok On Wed, Sep 12, 2012 at 2:59 PM, Ashok C ash@gmail.com wrote: Hi, I don't think this question was answered. Could you please reply? -- Ashok ** ** On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion klaus.mailingli...@pernau.at wrote: Hi! I wrote a small program which dumps all root certificates from Windows certificate store into a file. Then I use openssl to connect to Google and validate its certificate: openssl s_client -connect www.google.com:443 -CAfile dump.crt When using openssl0.9.8k or openssl0.9.8x everything works as expected. When using openssl1.0.0g or openssl 1.0.1c the certificate validation fails with: Verify return code: 10 (certificate has expired) CONNECTED(016C) depth=2 C = US, O = VeriSign, Inc., OU = Class 3 Public Primary Certification Authority verify error:num=10:certificate has expired notAfter=Jan 7 23:59:59 2004 GMT verify return:0 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority When analyzing the cafile with the dumped certificates from Windows certificate store, I found out that there are two certificates for Verisign with identical subject, whereas one is expired, the other not. X.509 Certificate Information: Version: 1 Serial Number (hex): 00e49efdf33ae80ecfa5113e19a4240232 Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Validity: Not Before: Mon Jan 29 00:00:00 UTC 1996 Not After: Wed Jan 07 23:59:59 UTC 2004 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Subject Public Key Algorithm: RSA X.509 Certificate Information: Version: 1 Serial Number (hex): 70bae41d10d92934b638ca7b03ccbabf Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Validity: Not Before: Mon Jan 29 00:00:00 UTC 1996 Not After: Tue Aug 01 23:59:59 UTC 2028 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Subject Public Key Algorithm: RSA Thus, it seems that openssl 0.9.8 just ignores the expired certificate and searches if there is another valid one whereas openssl 1.0.0 stop with the first expired certificate. Is the new behavior the intended behavior? Is it possible to have the old behavior also in new openssl versions? Thanks Klaus __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org ** ** ** **
Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Sending again as the previous email did not appear in list. Is there some problem with the mailing list? -- Ashok On Wed, Sep 12, 2012 at 2:59 PM, Ashok C ash@gmail.com wrote: Hi, I don't think this question was answered. Could you please reply? -- Ashok On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion klaus.mailingli...@pernau.at wrote: Hi! I wrote a small program which dumps all root certificates from Windows certificate store into a file. Then I use openssl to connect to Google and validate its certificate: openssl s_client -connect www.google.com:443 -CAfile dump.crt When using openssl0.9.8k or openssl0.9.8x everything works as expected. When using openssl1.0.0g or openssl 1.0.1c the certificate validation fails with: Verify return code: 10 (certificate has expired) CONNECTED(016C) depth=2 C = US, O = VeriSign, Inc., OU = Class 3 Public Primary Certification Authority verify error:num=10:certificate has expired notAfter=Jan 7 23:59:59 2004 GMT verify return:0 --- Certificate chain 0 s:/C=US/ST=California/L=**Mountain View/O=Google Inc/CN=www.google.com i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority When analyzing the cafile with the dumped certificates from Windows certificate store, I found out that there are two certificates for Verisign with identical subject, whereas one is expired, the other not. X.509 Certificate Information: Version: 1 Serial Number (hex): 00e49efdf33ae80ecfa5113e19a424**0232 Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Validity: Not Before: Mon Jan 29 00:00:00 UTC 1996 Not After: Wed Jan 07 23:59:59 UTC 2004 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Subject Public Key Algorithm: RSA X.509 Certificate Information: Version: 1 Serial Number (hex): 70bae41d10d92934b638ca7b03ccba**bf Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Validity: Not Before: Mon Jan 29 00:00:00 UTC 1996 Not After: Tue Aug 01 23:59:59 UTC 2028 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Subject Public Key Algorithm: RSA Thus, it seems that openssl 0.9.8 just ignores the expired certificate and searches if there is another valid one whereas openssl 1.0.0 stop with the first expired certificate. Is the new behavior the intended behavior? Is it possible to have the old behavior also in new openssl versions? Thanks Klaus __**__** __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Would it make sense to delete the expired certificate from the Windows store? Duplicate expired/non expired CA certificates sounds to me like a problem waiting to happen. Charles From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Ashok C Sent: Thursday, September 13, 2012 12:49 AM To: openssl-users@openssl.org Subject: Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile Sending again as the previous email did not appear in list. Is there some problem with the mailing list? -- Ashok On Wed, Sep 12, 2012 at 2:59 PM, Ashok C ash@gmail.com wrote: Hi, I don't think this question was answered. Could you please reply? -- Ashok On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion klaus.mailingli...@pernau.at wrote: Hi! I wrote a small program which dumps all root certificates from Windows certificate store into a file. Then I use openssl to connect to Google and validate its certificate: openssl s_client -connect www.google.com:443 -CAfile dump.crt When using openssl0.9.8k or openssl0.9.8x everything works as expected. When using openssl1.0.0g or openssl 1.0.1c the certificate validation fails with: Verify return code: 10 (certificate has expired) CONNECTED(016C) depth=2 C = US, O = VeriSign, Inc., OU = Class 3 Public Primary Certification Authority verify error:num=10:certificate has expired notAfter=Jan 7 23:59:59 2004 GMT verify return:0 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority When analyzing the cafile with the dumped certificates from Windows certificate store, I found out that there are two certificates for Verisign with identical subject, whereas one is expired, the other not. X.509 Certificate Information: Version: 1 Serial Number (hex): 00e49efdf33ae80ecfa5113e19a4240232 Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Validity: Not Before: Mon Jan 29 00:00:00 UTC 1996 Not After: Wed Jan 07 23:59:59 UTC 2004 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Subject Public Key Algorithm: RSA X.509 Certificate Information: Version: 1 Serial Number (hex): 70bae41d10d92934b638ca7b03ccbabf Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Validity: Not Before: Mon Jan 29 00:00:00 UTC 1996 Not After: Tue Aug 01 23:59:59 UTC 2028 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Subject Public Key Algorithm: RSA Thus, it seems that openssl 0.9.8 just ignores the expired certificate and searches if there is another valid one whereas openssl 1.0.0 stop with the first expired certificate. Is the new behavior the intended behavior? Is it possible to have the old behavior also in new openssl versions? Thanks Klaus __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
I suppose that's a workaround, but doesn't address the root cause. Windows can quite happily handle expired certificates still hanging out in trusted stores; I see this all the time as root updates occur and renewed certificates are installed. It seems that a change in OpenSSL broke the previous behaviour that allowed this as well, though we can't tell if it's the s_client app or the OpenSSL cert store functionality that changed this. Erik Tkal Juniper OAC/UAC/Pulse Development From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Charles Mills Sent: Thursday, September 13, 2012 9:42 AM To: openssl-users@openssl.org Subject: RE: certificate validation issues with openssl 1.0.0 and expired certificates in cafile Would it make sense to delete the expired certificate from the Windows store? Duplicate expired/non expired CA certificates sounds to me like a problem waiting to happen. Charles From: owner-openssl-us...@openssl.orgmailto:owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Ashok C Sent: Thursday, September 13, 2012 12:49 AM To: openssl-users@openssl.orgmailto:openssl-users@openssl.org Subject: Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile Sending again as the previous email did not appear in list. Is there some problem with the mailing list? -- Ashok On Wed, Sep 12, 2012 at 2:59 PM, Ashok C ash@gmail.commailto:ash@gmail.com wrote: Hi, I don't think this question was answered. Could you please reply? -- Ashok On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion klaus.mailingli...@pernau.atmailto:klaus.mailingli...@pernau.at wrote: Hi! I wrote a small program which dumps all root certificates from Windows certificate store into a file. Then I use openssl to connect to Google and validate its certificate: openssl s_client -connect www.google.com:443http://www.google.com:443 -CAfile dump.crt When using openssl0.9.8k or openssl0.9.8x everything works as expected. When using openssl1.0.0g or openssl 1.0.1c the certificate validation fails with: Verify return code: 10 (certificate has expired) CONNECTED(016C) depth=2 C = US, O = VeriSign, Inc., OU = Class 3 Public Primary Certification Authority verify error:num=10:certificate has expired notAfter=Jan 7 23:59:59 2004 GMT verify return:0 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.comhttp://www.google.com i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority When analyzing the cafile with the dumped certificates from Windows certificate store, I found out that there are two certificates for Verisign with identical subject, whereas one is expired, the other not. X.509 Certificate Information: Version: 1 Serial Number (hex): 00e49efdf33ae80ecfa5113e19a4240232 Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Validity: Not Before: Mon Jan 29 00:00:00 UTC 1996 Not After: Wed Jan 07 23:59:59 UTC 2004 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Subject Public Key Algorithm: RSA X.509 Certificate Information: Version: 1 Serial Number (hex): 70bae41d10d92934b638ca7b03ccbabf Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Validity: Not Before: Mon Jan 29 00:00:00 UTC 1996 Not After: Tue Aug 01 23:59:59 UTC 2028 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Subject Public Key Algorithm: RSA Thus, it seems that openssl 0.9.8 just ignores the expired certificate and searches if there is another valid one whereas openssl 1.0.0 stop with the first expired certificate. Is the new behavior the intended behavior? Is it possible to have the old behavior also in new openssl versions? Thanks Klaus __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.orgmailto:openssl-users@openssl.org Automated List Manager majord...@openssl.orgmailto:majord...@openssl.org
Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Hi, I don't think this question was answered. Could you please reply? -- Ashok On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion klaus.mailingli...@pernau.at wrote: Hi! I wrote a small program which dumps all root certificates from Windows certificate store into a file. Then I use openssl to connect to Google and validate its certificate: openssl s_client -connect www.google.com:443 -CAfile dump.crt When using openssl0.9.8k or openssl0.9.8x everything works as expected. When using openssl1.0.0g or openssl 1.0.1c the certificate validation fails with: Verify return code: 10 (certificate has expired) CONNECTED(016C) depth=2 C = US, O = VeriSign, Inc., OU = Class 3 Public Primary Certification Authority verify error:num=10:certificate has expired notAfter=Jan 7 23:59:59 2004 GMT verify return:0 --- Certificate chain 0 s:/C=US/ST=California/L=**Mountain View/O=Google Inc/CN=www.google.com i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority When analyzing the cafile with the dumped certificates from Windows certificate store, I found out that there are two certificates for Verisign with identical subject, whereas one is expired, the other not. X.509 Certificate Information: Version: 1 Serial Number (hex): 00e49efdf33ae80ecfa5113e19a424**0232 Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Validity: Not Before: Mon Jan 29 00:00:00 UTC 1996 Not After: Wed Jan 07 23:59:59 UTC 2004 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Subject Public Key Algorithm: RSA X.509 Certificate Information: Version: 1 Serial Number (hex): 70bae41d10d92934b638ca7b03ccba**bf Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Validity: Not Before: Mon Jan 29 00:00:00 UTC 1996 Not After: Tue Aug 01 23:59:59 UTC 2028 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Subject Public Key Algorithm: RSA Thus, it seems that openssl 0.9.8 just ignores the expired certificate and searches if there is another valid one whereas openssl 1.0.0 stop with the first expired certificate. Is the new behavior the intended behavior? Is it possible to have the old behavior also in new openssl versions? Thanks Klaus __**__**__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Hi! I wrote a small program which dumps all root certificates from Windows certificate store into a file. Then I use openssl to connect to Google and validate its certificate: openssl s_client -connect www.google.com:443 -CAfile dump.crt When using openssl0.9.8k or openssl0.9.8x everything works as expected. When using openssl1.0.0g or openssl 1.0.1c the certificate validation fails with: Verify return code: 10 (certificate has expired) CONNECTED(016C) depth=2 C = US, O = VeriSign, Inc., OU = Class 3 Public Primary Certification Authority verify error:num=10:certificate has expired notAfter=Jan 7 23:59:59 2004 GMT verify return:0 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority When analyzing the cafile with the dumped certificates from Windows certificate store, I found out that there are two certificates for Verisign with identical subject, whereas one is expired, the other not. X.509 Certificate Information: Version: 1 Serial Number (hex): 00e49efdf33ae80ecfa5113e19a4240232 Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Validity: Not Before: Mon Jan 29 00:00:00 UTC 1996 Not After: Wed Jan 07 23:59:59 UTC 2004 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Subject Public Key Algorithm: RSA X.509 Certificate Information: Version: 1 Serial Number (hex): 70bae41d10d92934b638ca7b03ccbabf Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Validity: Not Before: Mon Jan 29 00:00:00 UTC 1996 Not After: Tue Aug 01 23:59:59 UTC 2028 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Subject Public Key Algorithm: RSA Thus, it seems that openssl 0.9.8 just ignores the expired certificate and searches if there is another valid one whereas openssl 1.0.0 stop with the first expired certificate. Is the new behavior the intended behavior? Is it possible to have the old behavior also in new openssl versions? Thanks Klaus __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
