Bernhard Froehlich wrote:
Jorey Bump wrote:
Is this as simple as commenting out default_crl_days? I've noticed
that a certificate with a longer default_days will be treated as
expired when default_crl_days is reached. Yet, I don't see the CRL
period in the signed certificate when I view it with the -text option.
I'm afraid I don't understand the underlying CRL checking mechanism.
Does the server (web, mail, etc.) check the CRL, or the client?
No, you have to comment out "crlDistributionPoints" (and maybe some
similar entries like "nsCaRevocationUrl").
If a crlDistributionPoint is coded into the certificate a verifying
entity should download a new CRL every default_crl_days days, and if it
is not possible to download the CRL (maybe because you forgot to publish
the current version) the verification should fail! Otherwise an evil guy
would swamp the CRL distribution point with DoS-attacks and could use a
revoked cert till its expiry date.
Thanks a lot for the clarification. I've learned a lot over the last few
days - enough to realize that I misinterpreted some of the failures.
OK, if someone acquired your CA's key you're deep in the dirt,
regardless wether you use CRLs or not, since the evil one can build
his/her own CRLs with the signature of your CA. ;)
But only with the passphrase of the CA private key, correct?
I don't know very much about OCSP since I haven't used it till now. As I
understand it it's a webserver-plugin (cgi or perl or something like
that) that looks up a certificate's serial number in its local CRL and
returns (essentially) TRUE or FALSE.
It'll never catch on -- too effecient. :)
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
