Jorey Bump wrote:
Bernhard Froehlich wrote:The idea behind a CRL is to have the possibility to publicly revoke a certificate before it expires (so setting default_crl_days equal to default days is not very sensible, you should just work without a CRL in such a case).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.
It's been mentioned elsewhere that the CRLs of major CAs can grow to be several MB, but I can't say that I've ever noticed such activity on either my servers or clients (not that I was looking for it, but I do actively monitor connections).
As I see it CRLs are not often used, maybe just because of that reason. But from your description I'd guess that the size of the CRL should not be a problem in your environment.
The disadvantage of a CRL is that it has to be accessible and kept up-to-date or the verification will fail. So using a CRL will require a stable net, stable webserver and someone (possibly a cron job or something like that) generating new CRLs in regular intervals.I can probably do that, although at the moment it would seem more manageable to push the CRL out to the small number of clients when necessary. On the other hand, it seems that simply replacing a certificate on the server is as effective as revoking it and publishing a CRL (assuming, of course, that noone has acquired the key/cert and is using it to masquerade as my server). In this case, a CRL would be most valuable in protecting the integrity of my root CA certificate (which could also be replaced and redistributed, I guess).
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. ;)
Wether you can do without a CRL is hard to say without knowing your detailed security requirements. If there are only few servers to distribute new certificates to, setting a shorter expiry date may do a similar job. On the other hand, if you are using the certificates for client access to important data you might like to be able to revoke a lost certificate within few days or even hours, in which case even a CRL might not be "fast" enough and you'd have to set up an OCSP server...Yes, I've glanced at OCSP, and it seems to be the most sensible approach. But is it widely supported? Is the OCSP server included with OpenSSL robust? Is it recommended to set up OCSP servers on port 80 to accommodate corporate firewalls? I have no current plans for issuing client certificates, but the need may arise in the future.
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.
[...]
Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26
smime.p7s
Description: S/MIME Cryptographic Signature
