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 openssl-users@openssl.org
Automated List Manager majord...@openssl.org
