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-
Ber
Jorey Bump wrote:
[...]
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?
Yes, correct, the bad
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
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 w
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 defau
Jorey Bump wrote:
I'm nearly complete in setting up my own CA, but I'm not sure how to
manage Certificate Revocation Lists (CRL). I noticed that related
settings such as *RevocationUrl are commented out in the default
openssl.cnf. Should I fill these in and post my CRL, or should I just
make
CRLs are lists that are published either regularly or irregularly to help
to report the latest revocation status of certs. The list contains of
serial numbers of certs that have been revocated and reseaons for it, if
there is any. If you have interest, you can go to IETF's pkix working group
to se
