Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Jakob Bohm <jb-openssl-Ov0D3Su7/I/QT0dZR+AlfA <at> public.gmane.org>
Subject: Re: openssl 1.0.0, multiple crls same issuer - revoked cert
Newsgroups: gmane.comp.encryption.openssl.user
Date: Monday 14th June 2010 18:23:19 UTC (over 7 years ago)
On 14-06-2010 18:47, matteo mattau wrote:
> Hi,
> I saw the thread "Multiple CRL with same issuer" on this mailing list, 
> and I have the
> same problem:
>
> for one CA issuer I have 100 CRLs, and if the revoked certificate is 
> not in the first CRL
> (in my case is the 11th CRL), openssl verify return ok.
>
> I have downloaded and installed openssl 1.0.0a,
> then
> 1) tried to create 1 file for each  CRL in pem format,  and created 
> symbolic link
> ln -s crlPEMn.crl `openssl crl -hash -noout -in crlPEMn.crl`.rn
> with n from 0 to 99
> executing
> openssl verify -verbose -CApath ./demoCA/certs -crl_check 
> ./RevokedCert.cer
> the result is ok, and it is very fast, it seems that it checks only 
> the first CRL (with .r0)
>
> 2) tried to create 1 file, with all the CRLs concatenated in pem 
> format, and created
> symbolic link
> ln -s crlPEM.crl `openssl crl -hash -noout -in crlPEM.crl`.r0
> executing
> openssl verify -verbose -CApath ./demoCA/certs -crl_check 
> ./RevokedCert.cer
> the result is ok, but it is slowly, such as check all the big CRL 
> file, but cannot
> find the revoked serial number.
>
> I've also tried to pass all the other verify args for CRL, but the 
> result does not change.
>
> Please, where I wrong? I downloaded openssl 1.0.0a because I've read 
> that from 0.9.9dev
> there is the support for multiple CRLs.
>
Note to list: I am aware of at least one public CA (TDC OCES) who (at 
least planned to) split
their CRL into smaller parts, each covering only revocations for a range 
of certificate serial
numbers.  The certificates themselves then contained/contain different 
CRL download URLs
depending on the serial number.

Example (numbers are made up)
   * Certificates with serial numbers     0..9999 point to 
https://ca.example.com/crls/crl0.crl
   * Certificates with serial numbers 10000..19999 point to 
https://ca.example.com/crls/crl1.crl
   * Certificates with serial numbers 20000..29999 point to 
https://ca.example.com/crls/crl2.crl
   * etc.
   * Each of crl0.crl, crl1.crl, crl2.crl etc. are issued 
simultaneously, but only cover revocations
    of certificates in their own range.  Their idea is that if a 
computer is validating less often than
    the CRL lifetime, then they would only need to download a smaller 
CRL, those who do
    lots of validations, would end up downloading all the CRLs, but 
would not need much more
    bandwidth than downloading a single big CRL.
   * If a computer with a fixed IP address downloads few CRLs, the https 
logs on the CRL
    download server would allow the CA to see approximately which 
certificates that computer
    is validating at a given time, causing almost the same privacy 
issues as OCSP.
   * I don't know if this CA practice is fully standards compliant, but 
it exists in the real world,
    for real 3rd party public CAs that are unlikely to listen to 
complaints.  So everybody else
    (than the CA) will just have to deal with this situation.
   * If an X.509 implementation caches CRLs based on the issuer 
distinguished name, rather
    than the CRL download URL, it may think that whatever CRL it already 
has (e.g. crl1.crl),
    also indicates if a certificate from another range (e.g. certificate 
23456) has been revoked
    or not, yielding to false trust in revoked certificates.

I don't know if this is the OP's situation, but if so, it would be a 
serious weakness in the
certificate validation code.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                   
[email protected]
Automated List Manager                          
[email protected]
 
CD: 2ms