Hi Martin,
in our tests (0.9.2.1) we are experiencing some weird behaviour with regard to expired certificates. Sometimes the status displayed does not reflect the true certificate status (e. g. cert is reported to be "Not expired" but in fact it is).
Mmh, I hope you use - like always - DBI and then it is a bug.
After reading the corresponding code I am pretty sure that the reason for this is keeping the VALID and EXPIRED state of a certificate in the database.
No, the database never stores a certificate EXPIRED physically into the database. We always store VALID and the status VALID/EXPIRED depends on the notbefore column.
In my opinion this is a bug because the validity of the certificate changes automatically when reaching the notAfter (or the notBefore) date. This does not trigger a database action, so the status in the database does not reflect the true certificate status. OpenSSL index.txt is not doing any better, of course.
I'd like to propose the following change for the next release:
- for each certificate the notBefore and notAfter dates are stored in the database
We can only add NOTBEFORE. NOTAFTER is already present.
- the following certificate status are kept in the database:
- ISSUED (certificate was issued and may or may not be valid)
- REVOKED (certificate was explicitly revoked)
- maybe we also need RENEWED which might be set for the old cert
if the same DN is issued again later
ISSUED is liek the todays VALID. What happens with SUSPENDED?
- a library function should exist that determines the current and up-to-date certificate status for an ISSUED certificate. This function must be called in order to get the true status of the cert in terms of validity.
This is done by DBI automatically. The next release only supports DBI. So you should always get the correct state.
(In addition I think we will have to recreate the OpenSSL index.txt prior to any issuance or revocation action to work around the same bug in OpenSSL, but I think this is already done in the CVS head code.)
The new release will have a complete new understanding of index.txt. If you create a new cert then index.txt is always empty (otherwise you get a really big performance problem if you have several thousand active certificates). If you issue a CRL then a fresh index.txt with only the revoked certficates will be created. This solution has an acceptable performance and we solve a lot of problems with the old index.txt handling.
Michael -- _______________________________________________________________
Michael Bell Humboldt-Universitaet zu Berlin
Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 [EMAIL PROTECTED] D-10099 Berlin _______________________________________________________________
smime.p7s
Description: S/MIME Cryptographic Signature
