Re: [openssl-users] Something causing "Error 12"/Expired CRL during CRL processing
On Wed, Mar 09, 2016, o haya wrote: > > Question: What exactly is determines the ORDER in which the CRLs would be > selected? > > In other words, say there were two CRL files (the previous one and the > current one) but one hash (only .r0) pointing to the current CRL file. The > reason for my question is that we're (or I) am still trying to understand why > we'd get the Error 12/Expired CRL? > > In this case, there'd be only one hash/soft link, pointing to one of the CRL > files, and no softlink pointing to the other CRL file. > > So how does OpenSSL (or Apache?) decide which of the CRLs to work with? > If you only have one CRL in the the form .r0 then that will get loaded. What may have happened in your case was that there were two CRLs with the same issuer name and the hash file only pointed to the one which was not up to date. So OpenSSL would only load that one case and you'd get that error. If you had CRLs of the form .r0, .r1 etc then it should've loaded both and used the more recent one. When you have CRLs bundled in a file they all get loaded so it will see both and use the appropriate case. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Something causing "Error 12"/Expired CRL during CRL processing
Dr. Henson, It turns out that the app apparently makes copies of the old CRL files before downloading new ones, i.e., so there were multiple copies of CRL files for the same CA. They cleaned out the directory and left only one CA CRL and the ROOT CA CRL and then it worked. Question: What exactly is determines the ORDER in which the CRLs would be selected? In other words, say there were two CRL files (the previous one and the current one) but one hash (only .r0) pointing to the current CRL file. The reason for my question is that we're (or I) am still trying to understand why we'd get the Error 12/Expired CRL? In this case, there'd be only one hash/soft link, pointing to one of the CRL files, and no softlink pointing to the other CRL file. So how does OpenSSL (or Apache?) decide which of the CRLs to work with? Thanks, Jim On Tue, 3/8/16, o haya wrote: Subject: Re: [openssl-users] Something causing "Error 12"/Expired CRL during CRL processing To: "o haya" , "Dr. Stephen Henson" Cc: openssl-users@openssl.org Date: Tuesday, March 8, 2016, 7:09 PM I'm not sure about the answer to your last question, but I will check tomorrow. I do know that the set of CAs is configured by us, and then they have either an app or script that gets run to re-download each of the CRLs intermittently. What I don't know is whether they restart/reload the Apache, but I'm guessing that that they do do that. I'll confirm tomorrow. Based on what you said, and assuming we use individual files per CRL and with the hashes, and assuming that we just happen to have more than one CRL file that resulted in the same hash string, would that account for an Error 12/Expired CRL error? I guess the thing that still bothers me is that they've been using this scheme/approach for awhile with the earlier Apache and with openssl 0.9.8 until this upgrade attempt recently, and it's hard to believe that they'd all of sudden be encountering hash collisions and just at the time of upgrading the Apache 2.4.16 and openssl 1.0.1e? Talk about bad luck :)!! I will post back tomorrow. Thanks, Jim On Tue, 3/8/16, Dr. Stephen Henson wrote: Subject: Re: [openssl-users] Something causing "Error 12"/Expired CRL during CRL processing To: "o haya" Cc: openssl-users@openssl.org Date: Tuesday, March 8, 2016, 6:35 PM On Tue, Mar 08, 2016, o haya wrote: > > Can you clarify what you mean by "multiple CRLs with the same hash"? Do you > mean a situation where we have several of the CRL files (for different CAs) > where the result of the "openssl hash" gives an identical number/string? > The hash depends on the CRL issuer name only. It is first converted to a canonical form and then a hash taken of the encoding. That guarantees that identical issuer names will produce the same hash. Equivalent (i.e. equal but not having the same encoding) issuer names *should* produce the same hash. The hash is only 8 hex digits so there are only 2^32 possible hashes which gives a 1 in 2^16 chance of a collision: but you'd get a different error in that case. > > Re. the "time": I'm pretty sure the system time is correct, but will have > them check, BUT if the time was wrong, how would it be able to work when we > put the CRLs into a big PEM file instead of as individual files with the > hashes? In other words, if the system time was wrong, wouldn't that also > cause the CRL verify to fail when the CRLs were all in one big PEM file? > If the CRLs are in a big file then the duplicate hash issue wont affect this. What this might be is if you have two CRLs with identical issuer name one of which has a nextUpdate after the current time (which is what causes the error) and one before. In the case of the hashes in a directory calling everytyhing .r0 only one CRL would be downloaded. In a big file the valid CRL would be selected of the two. A question back: is the CRL set fixed when you start the server or are you trying to update them in real time? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Something causing "Error 12"/Expired CRL during CRL processing
I'm not sure about the answer to your last question, but I will check tomorrow. I do know that the set of CAs is configured by us, and then they have either an app or script that gets run to re-download each of the CRLs intermittently. What I don't know is whether they restart/reload the Apache, but I'm guessing that that they do do that. I'll confirm tomorrow. Based on what you said, and assuming we use individual files per CRL and with the hashes, and assuming that we just happen to have more than one CRL file that resulted in the same hash string, would that account for an Error 12/Expired CRL error? I guess the thing that still bothers me is that they've been using this scheme/approach for awhile with the earlier Apache and with openssl 0.9.8 until this upgrade attempt recently, and it's hard to believe that they'd all of sudden be encountering hash collisions and just at the time of upgrading the Apache 2.4.16 and openssl 1.0.1e? Talk about bad luck :)!! I will post back tomorrow. Thanks, Jim On Tue, 3/8/16, Dr. Stephen Henson wrote: Subject: Re: [openssl-users] Something causing "Error 12"/Expired CRL during CRL processing To: "o haya" Cc: openssl-users@openssl.org Date: Tuesday, March 8, 2016, 6:35 PM On Tue, Mar 08, 2016, o haya wrote: > > Can you clarify what you mean by "multiple CRLs with the same hash"? Do you > mean a situation where we have several of the CRL files (for different CAs) > where the result of the "openssl hash" gives an identical number/string? > The hash depends on the CRL issuer name only. It is first converted to a canonical form and then a hash taken of the encoding. That guarantees that identical issuer names will produce the same hash. Equivalent (i.e. equal but not having the same encoding) issuer names *should* produce the same hash. The hash is only 8 hex digits so there are only 2^32 possible hashes which gives a 1 in 2^16 chance of a collision: but you'd get a different error in that case. > > Re. the "time": I'm pretty sure the system time is correct, but will have > them check, BUT if the time was wrong, how would it be able to work when we > put the CRLs into a big PEM file instead of as individual files with the > hashes? In other words, if the system time was wrong, wouldn't that also > cause the CRL verify to fail when the CRLs were all in one big PEM file? > If the CRLs are in a big file then the duplicate hash issue wont affect this. What this might be is if you have two CRLs with identical issuer name one of which has a nextUpdate after the current time (which is what causes the error) and one before. In the case of the hashes in a directory calling everytyhing .r0 only one CRL would be downloaded. In a big file the valid CRL would be selected of the two. A question back: is the CRL set fixed when you start the server or are you trying to update them in real time? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Something causing "Error 12"/Expired CRL during CRL processing
On Tue, Mar 08, 2016, o haya wrote: > > Can you clarify what you mean by "multiple CRLs with the same hash"? Do you > mean a situation where we have several of the CRL files (for different CAs) > where the result of the "openssl hash" gives an identical number/string? > The hash depends on the CRL issuer name only. It is first converted to a canonical form and then a hash taken of the encoding. That guarantees that identical issuer names will produce the same hash. Equivalent (i.e. equal but not having the same encoding) issuer names *should* produce the same hash. The hash is only 8 hex digits so there are only 2^32 possible hashes which gives a 1 in 2^16 chance of a collision: but you'd get a different error in that case. > > Re. the "time": I'm pretty sure the system time is correct, but will have > them check, BUT if the time was wrong, how would it be able to work when we > put the CRLs into a big PEM file instead of as individual files with the > hashes? In other words, if the system time was wrong, wouldn't that also > cause the CRL verify to fail when the CRLs were all in one big PEM file? > If the CRLs are in a big file then the duplicate hash issue wont affect this. What this might be is if you have two CRLs with identical issuer name one of which has a nextUpdate after the current time (which is what causes the error) and one before. In the case of the hashes in a directory calling everytyhing .r0 only one CRL would be downloaded. In a big file the valid CRL would be selected of the two. A question back: is the CRL set fixed when you start the server or are you trying to update them in real time? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Something causing "Error 12"/Expired CRL during CRL processing
Hello Dr. Henson, It's been a very long time since I've been on this list... it's great that you're still here :)!!! We were kind of wondering about the hashes (we couldn't find how they were calculated, etc.). Can you clarify what you mean by "multiple CRLs with the same hash"? Do you mean a situation where we have several of the CRL files (for different CAs) where the result of the "openssl hash" gives an identical number/string? I'm not on our production site yet, so I'll ask someone who is. I'm pretty sure that they didn't check for that as they have an automated task or something that they run under a cron job to re-calculate the hashes when they are downloaded. Re. the "time": I'm pretty sure the system time is correct, but will have them check, BUT if the time was wrong, how would it be able to work when we put the CRLs into a big PEM file instead of as individual files with the hashes? In other words, if the system time was wrong, wouldn't that also cause the CRL verify to fail when the CRLs were all in one big PEM file? A couple of more questions: 1) Re. what I said about about HOW the hashes are calculated: The docs say "based on the Issuer name". Is that mean literally, i.e., the hash is only a hash of the Issuer name inside the CRL and the other contents of the CRL, like signatures, etc. don't affect the value of the hash that openssl calculates?? In other words, assuming that the Issuer names in the CRLs don't change, can we just download update CRL files and NOT re-calculate the hashes in the CRL directory? 2) When you said "A couple of possibilities": Would the duplicate hashes cause an "Error 12"/Expired CRL error? That seems like an incorrect error? Thanks, Jim ------------ On Tue, 3/8/16, Dr. Stephen Henson wrote: Subject: Re: [openssl-users] Something causing "Error 12"/Expired CRL during CRL processing To: "o haya" , openssl-users@openssl.org Date: Tuesday, March 8, 2016, 2:46 PM On Tue, Mar 08, 2016, o haya wrote: > > Our websites are configured for SSL client authentication with CRLs in a directory pointed to by SSLCACertificateRevocationPath and SSLCARevocationCheck set to "chain". We then place our CRLs in the directory and create the hashes for them using an app or script that we wrote. I think that this essentially does something like: > > ln -s ca.crl `openssl crl -hash -noout -in ca.crl`.r0 > > However, when we did a test upgrade one of our production instances the requests are failing and, in the error logs, we are seeing the following messages: > > A couple of possibilities. One is that the time isn't properly set on the machine which has this problem. Another is that there may be multiple CRLs with the same hash: have you checked for that? If there are you need to use the form .r1, .r2 etc. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Something causing "Error 12"/Expired CRL during CRL processing
On Tue, Mar 08, 2016, o haya wrote: > > Our websites are configured for SSL client authentication with CRLs in a > directory pointed to by SSLCACertificateRevocationPath and > SSLCARevocationCheck set to "chain". We then place our CRLs in the directory > and create the hashes for them using an app or script that we wrote. I think > that this essentially does something like: > > ln -s ca.crl `openssl crl -hash -noout -in ca.crl`.r0 > > However, when we did a test upgrade one of our production instances the > requests are failing and, in the error logs, we are seeing the following > messages: > > A couple of possibilities. One is that the time isn't properly set on the machine which has this problem. Another is that there may be multiple CRLs with the same hash: have you checked for that? If there are you need to use the form .r1, .r2 etc. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Something causing "Error 12"/Expired CRL during CRL processing
Hi, I wasn't sure which mailing list would be most appropriate, so I had posted about this originally on the Apache mailing list earlier. I haven't gotten any feedback on that, so I'm posting here in the hopes that someone might have some idea about what might be causing the problems we're seeing. Anyway, we are upgrading some of our Apache instances to 2.4.16 (on Redhat) and OpenSSL from 0.9.8x to 1.0.1e, at the same time, mostly because we want to enable TLS, and we are encountering a strange problem with SSL and CRLs. Our websites are configured for SSL client authentication with CRLs in a directory pointed to by SSLCACertificateRevocationPath and SSLCARevocationCheck set to "chain". We then place our CRLs in the directory and create the hashes for them using an app or script that we wrote. I think that this essentially does something like: ln -s ca.crl `openssl crl -hash -noout -in ca.crl`.r0 However, when we did a test upgrade one of our production instances the requests are failing and, in the error logs, we are seeing the following messages: [ssl.debug] [pid 4866] ssl_engine_kernel.c: [client 10.10.10.10-] Certificate Verification, depth 1, CRL checking mode: chain [subject: CN=CA4,OU=branch, / issuer: CN=Root 3,OU=branch,... / serial: 86 / notbefore: Aug 1 00:00:00 2013 GMT / notafter: Aug 1 00:00:00 2021 GMT] [ssl.info] [pid 4866] [client 10.10.10.10-] Certificate Verification: Error (12): CRL has expired [subject: CN=CA4,OU=branch,... / issuer: CN=Root 3,... / serial: 86 / notbefore: Aug 1 00:00:00 2013 GMT / notafter: Aug 1 00:00:00 2021 GMT] We checked all of the CRL files and they all appear to be within their validity periods, so we are really puzzled as to what is causing this problem. Also, I should mention a couple of additional pieces of info: - After the Apache upgrade, we explicitly re-generated the CRL hashes using openssl 1.0.1x. - We did another set of tests, where instead of using the Apache SSLCARevocationPath directive and the CRLs and hashes in the directoryl, we glommed all of the CRLs together into a big PEM file and used SSLCARevocationFile directory, and when we did that that, we did not get the "Error 12"/Expired errors. The thing is that we have not been able to replicate this problem in our test environment, when we try to re-create a similar PKI heirarchy, so we (or I) suspect that there may be something going on with either the CRLs or cert files themselves that we are getting from the CAs (but recall that these same CRLs worked with older Apache. So I was wondering: If there is any known situations (e.g., some combination of constraints, etc., maybe some difference in versions or something in the CRL formats) that Apache/openssl to think that the CRL was expired and cause "Error 12" to be logged, but where the problem was being cause by something other than the CRL files actually being expired? As I said, I wasn't quite sure where to post this, but I'm hoping that someone here might have some clue about what is causing this problem. Thanks in advance, Jim -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: "expired" CRL
> Well, make that hard choice: do you want to have your software fail > when an up-to-date CRL is not available, or do you want to make your > software susceptible to a denial-of-service attack on the CRL distro > process? Exactly. Security is all about risk management. Which is more likely to happen -- a revocation of a compromised (or mis-issued) high-value key, or nothing's happened (or other rationale) so the CA didn't get around to issuing another CRL. Those aren't static decision, either, and probably vary depending on time of day, academic calendar, etc. > These are the kind of hard questions (of the form "how much are you > REALLY willing to pay for security?") that the horrible old men who > task us cannot be bothered to consider. :) > > Gotcha. So it would be safe to assume that almost nobody uses CRLs since > > none of the software I use that does SSL seems to worry about the > > presence (or lack) of a CRL. Wonderful. That really inspires confidence. In the general Internet, it's probably not so bad. SSL is really only used for data privacy, and US Law limits your exposure for CCard purchases to $50. So it's just not worth it for anyone to insist on or implement stronger controls. BTW, when VRSN erroneously issued MSFT certificate to non-MSFT employees, part of the patch from MSFT was to hard-wire a CRL into IE. "If a CRL falls in the forest, does it make a sound?" > > I'll just bump the nextUpdate field out and make sure that the CA is > > keeping the CRL up-to-date. The more valuable the certs, the more important timely it is to have timely revocation. The more valuable the certs, the harder it should be to crank up the CA and sign certs. Paradoxically, the more valuable the certs, the easier it should be to crank up the CA and sign CRL's. If you really care, have your CA issue a CRL-issuing-certs to someone else. /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: "expired" CRL
Well, make that hard choice: do you want to have your software fail when an up-to-date CRL is not available, or do you want to make your software susceptible to a denial-of-service attack on the CRL distro process? Same question if your OCSP request fails without prejudice. If you go ahead and trust the certificate anyway, all the adverary has to do is jam your OCSP request. If you don't trust the certificate, then minor and temporary failures in the OCSP process become very visible. These are the kind of hard questions (of the form "how much are you REALLY willing to pay for security?") that the horrible old men who task us cannot be bothered to consider. In this case, the cost is not of money but instead is of inconvenience due to non-robustness with respect to minor network failings. As usual: the level of security required should be commeasurate with the value of the asset to be protected. Joseph Bruni wrote: Gotcha. So it would be safe to assume that almost nobody uses CRLs since none of the software I use that does SSL seems to worry about the presence (or lack) of a CRL. Wonderful. That really inspires confidence. I'll just bump the nextUpdate field out and make sure that the CA is keeping the CRL up-to-date. On Dec 29, 2003, at 7:19 PM, Dr. Stephen Henson wrote: The reason this is often done is that if you allow an expired CRL to be used then someone could use a revoked certificate that hadn't been revoked in the expired CRL but has been revoked in the current one. Steve. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- +-+-+-+-+-+-+-+ Charles B. (Ben) Cranston mailto:[EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: "expired" CRL
Gotcha. So it would be safe to assume that almost nobody uses CRLs since none of the software I use that does SSL seems to worry about the presence (or lack) of a CRL. Wonderful. That really inspires confidence. I'll just bump the nextUpdate field out and make sure that the CA is keeping the CRL up-to-date. On Dec 29, 2003, at 7:19 PM, Dr. Stephen Henson wrote: The reason this is often done is that if you allow an expired CRL to be used then someone could use a revoked certificate that hadn't been revoked in the expired CRL but has been revoked in the current one. Steve. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: "expired" CRL
On Mon, Dec 29, 2003, Joseph Bruni wrote: > I've run into an interesting situation and need some advice. I'm building a > server that will be validating clients via certs. So, I've coded this to > handle CRLs, but I've encountered that if a CRL has "expired" no > certificates related to that CA are considered valid. I'm not sure this a > good way to go because I don't want to shut down communications just because > of a CRL that hasn't been updated. The certificates that had been revoked > are still revoked! > The reason this is often done is that if you allow an expired CRL to be used then someone could use a revoked certificate that hadn't been revoked in the expired CRL but has been revoked in the current one. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
"expired" CRL
I've run into an interesting situation and need some advice. I'm building a server that will be validating clients via certs. So, I've coded this to handle CRLs, but I've encountered that if a CRL has "expired" no certificates related to that CA are considered valid. I'm not sure this a good way to go because I don't want to shut down communications just because of a CRL that hasn't been updated. The certificates that had been revoked are still revoked! I thought about testing the CRL before loading it, but then that means anyone can connect with a cert. that has been revoked. The other approach would be to set the "nextUpdate" field of the CRL farther into the future. Any suggestions on this? __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
