Certificate Revocation






Certificate Revocation

Most certificates are given a lifespan when created, but there are times that you might want to revoke a certificate to keep it from being used. For example, a person might lose his keys or change positions within the company, or an e-commerce site using SSL may merge with another company. In these situations, and many more, a certificate should be revoked. But, this is much easier said than done.

Do you remember the days when merchants had little booklets of bad credit card numbers? (Yes, much simpler and more trusting days.) A certificate revocation is much like that. It uses a Certificate Revocation List (CRL) which is a list of certificate serial numbers signed by the CA. When someone attempts to validate the certificate, the CA can look up the serial number to see if it is good and form a response. However, this is yet another job that CAs find very time consuming and it slows down the process of issuing certificates and the other jobs that a CA is responsible for. The usual answer is to put the CRL on an LDAP server.

This, though, brings up other problems. How often should the CRL server send updates to the CA? Should it even send them to the CA or should the authentication process work some other way? Ideally persons, applications, and other computers ought to be able to query the CRL via the LDAP which then queries the CA. These are some of the issues you’ll have to contend with when you are dealing with Digital Certificates. It’s not a hard job when you have a limited number of certificates, but when the numbers of certificates reaches into the tens of thousands, it becomes quite a large task.

There is something you can do to reduce the burden of updating CRLs — and this is something you can do when certificates are initially issued. There is a field in the certificate in which you can set an expiration date. When that date comes around, the certificate automatically becomes unusable for new transactions. Of course, you’d still have the job of issuing a new certificate to replace the expired one (like getting a new credit card when your old one reaches its expiration date). Reissuing a new certificate in this case is a lot easier and less labor intensive than revoking one and updating the CRL. As I mentioned before, it’s not such a big deal when you are dealing with a limited number of certificates, but setting expiration dates should be standard procedure when you are dealing with large numbers of certificates.



 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows