2

I am trying to set up a CA for my company, and issuing every employee a digital certificate and a private key. I am worrying about revocation and expiration.

In my case, the root certificate of CA is used to verify client identities, id est user must present a valid certificate and private key to access specific web pages (Apache VerifyClient require or Nginx ssl_verify_client on). If a user leaves the company or his/her private key is compromised, the certificate is added to CRL.

As we can see, the CRL will grow longer and longer as employees come and go. This is not what I want. However, as every certificate has an expiration date (I set it to 180 days), can I remove expired certificates from the CRL? This can somewhat reduce the issue with over-sized CRL.

Wikipedia article on "CRL" says that expiration should not be used as a substitution of revocation. I think they are talking about web browsers verifying web servers, as some users' computer may have incorrect time (thus trusting the expired certificates provided by web servers). However in my case, it is the web server that verifies users, so if I can ensure that the time on the web server is correct, can I remove those expired compromised certificates from CRL?

| improve this question | |
  • 2
    The wikipedia article is just trying to say that expiration date should not be the ONLY check made for certificate verification. As you stated, the expiration date could be valid, but the certificate should be invalidated if an employee leaves. CRL's themselves have an expiration. I would say it's safe to remove those certificates if they're expired. It all depends on how software ends up validating them though. – RoraΖ Aug 21 '14 at 11:53
  • Thanks. In openssl crl I can see "Last Update" and "Next Update", is this what you mean "CRL expiration date"? Aren't they just meant to tell clients how frequent should they "check for updates"? – Zhuoyun Wei Aug 21 '14 at 12:04
  • 1
    You shouldn't be issuing private keys. – user49075 Aug 22 '14 at 2:18
  • @RickyDemer It's too complicated for every employee in my company to understand the relationship between public / private key and csr. So I just generate the key pair and csr for them and sign with CA private key for them. – Zhuoyun Wei Aug 24 '14 at 14:14
6

From RFC 5280 3.3 Revocation

An entry MUST NOT be removed from the CRL until it appears on one regularly scheduled CRL issued beyond the revoked certificate's validity period.

If you have a lot of changes (people leaving etc.) it's best to not make the certificate validity too long otherwise the CRL can grow large (some CRLs are > 30MB which might not be handled by some applications).

Your server should always have the correct time. It's your server that should check the validity of the certificate not the web client.

| improve this answer | |
  • "It's your server that should check the validity of the certificate not the web client." I think this is the most important remark here. The server is something you control and which usually has a somewhat-correct time (not off by weeks at least). – Luc Aug 21 '14 at 13:27
  • Thanks. I feel safe now, seeing the RFC. So if I can ensure my server has the correct time, and disallows expired certificates (which I think is the default behavior for most web servers?), I can safely remove expired certificates from the CRL. – Zhuoyun Wei Aug 21 '14 at 17:11
3

Expiration date is "baked" into certificate itself, so even if time on client is incorrect this wouldn't cause server to mistakenly accept the certificate. Server clock, on the contrary, have to be correct.

Now, whether or not it is safe to remove expired certificates from the CRL depends on how server verifies certificates and, in particular, whether it disallows expired certificates. If it disallows them then you can safely remove expired certificates from the CRL.

| improve this answer | |
  • Thanks. Since the time of the client can be controlled by "bad guys", it is more important to ensure the time on the server is correct. :-) – Zhuoyun Wei Aug 21 '14 at 17:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.