A.8. Certificate Management

Certificates are currently the top-shelf method of proving identity. However, it is important to stress that identity proof (such as authentication) is the only purpose of certificates. Certificates in no way provide proof of reliability, trustworthiness, compatibility, or benevolence of an entity. The only proof provided by a certificate is the identity of that entity. It is a separate and distinct choice to trust in an entity once you know who they are. Certificates are used as the primary means of identity proof on the Internet for e-commerce and resource download sites. However, too many people associate having a certificate with some type of proof of goodness. This is an absolutely incorrect assumption.

A simple understanding of what a certificate is and how they are created can easily dispel this misguided notion. Certificates are issued by CAs after they prove the identity of the requesting subject. The identity is proven through various means, which could be as simple as sending an e-mail to a given e-mail address or checking with public records that a business exists at a specific address and is able to be contacted via a specific phone number. That's it; the CA verifies the identity details of a subject and nothing else.

Further proof: Have you ever downloaded an update from a well-known vendor who proved their identity with a digital certificate only to have that update crash your system? Enough said.

To gain the most from certificate security troubleshooting, follow these guidelines:

• Stop assuming certificates prove trustworthiness.

• Consider why you would want to trust each specific entity whose identity is proven by a CA.

• Consider why you trust the CAs that you do (review the trusted roots list in your web browser to see which CAs you are trusting already).

• Only choose to make the same selection for this certificate in the future when you are denying acceptance or trust of an entity.

• When asked to retrust an entity, reconsider.

• If any utility questions any aspect of a certificate, such as the common name (CN) on the certificate not matching the claimed name of a site, deny acceptance of the certificate.

• Obtain your own certificate from a reputable CA, such as VeriSign. But don't settle for a free or e-mail-only certificate; obtain a certificate that validates more than just a working e-mail inbox.

• Require mutual certificate-based authentication from all Internet sites whenever available.

• Make sure your client tools update their Certificate Revocation Lists (CRLs) before each check of a received certificate.

Certificates themselves cannot currently be spoofed or stolen after use. However, this security does not mean that fake certificates don't exist or that abuse doesn't occur. You need to be vigilant at inspecting certificates and assume the worst even when accepting the identity from a trusted CA.