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?
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).
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).
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.
Just consider what might happen if a certificate is compromised and used by someone evil till it expires, this will help you to decide.
Evil people suck. :) I understand the significance of asking users to import my root CA certificate (as opposed to simply accepting the server certificate for each session) and I want to protect them from my own oversight, as well. My next step will be to learn how to narrow the purpose of a certificate when I sign it.
Hope it helps,
Yes, it does. A few days ago I thought SSL/TLS was hopelessly complex, but now I'm sure of it. :) In any case, I've made some great gains and I'm at the point of trying to determine what standard practice is. Inspecting other root CA certificates is of little help because they vary so wildly according to their purpose. There are a lot of features I'll probably never use, but I wonder if some of them are ignored by everyone, due to lack of server/client support.
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
