Sorry to prolong this thread, but does the function X509_CRL_verify()
actually check to see if the CRL has expired? If not what function
performs this verification? I'm confused as to the actually mechanics of
using the default_crl_days in code.
-David Brock-
Bernhard Froehlich wrote:
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
;)
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
