Top Cert Myths Debunked

Sean Wright -

Over the past few months I have seen several points about certificates being put out there, and some of them are incorrect and in some cases seem nothing more than to try sow some sort of FUD. The purpose of this post is to take some of these "myths" and try show why they are in fact incorrect.

How Certs Work

Let me start off with stating how certificates play a role in a secure connection to a server. When a client connects to a server it performs a TLS handshake (some may still refer to SSL, hopefully they mean TLS and are not using any SSL protocols since they are weak and insecure). As part of this handshake the client receives a certificate from the server. This certificate helps to identify the server so that the client can with a high degree of confidence say that the server which it is communicating with is in fact the system which it intended to communicate with. In order to validate the certificate it does the following:

  1. Validate that the certificate has been signed by an entity which the client has trust in (almost always this will be a Certificate Authority, a.k.a. CA).
  2. The certificate was generated for the server which is presenting the certificate. This used to confirmed by looking for the hostname in the Common Name (CN) attribute of the Subject field of the certificate. This still happens, but the correct way is to now look for the hostname as a DNS entry in the Subject Alternative Name (SAN) field of the certificate. In addition wildcards may be used to cover several host names.
  3. The certificate is still valid, and it has not yet expired.

I created a post which goes into the details of certificates a bit more if you are interested.

Myth 1 - EV Certs Make Encryption More Secure

When it comes to certificates, the Certificate Authority (CA) needs to validate that the requester owns the resource for which they are requesting the certificate for. This typically comes in 3 flavours:

  1. Domain Validation (DV) - the requester proves they own the domain for the entity which they are requesting the certificate for. This is a largely automated process.
  2. Organization Validation (OV) - the requester needs to prove they own the organisation/business which is attempting to obtain the certificate. This requires more validation than DV certificates.
  3. Extended Validation (EV) - the requester needs to prove that they own the legal entity which owns the resource for which the certificate is being requested for. This is similar to OV certificates, but further checks are required. In addition the organisation's name (used to) appear next to the URL in the browser.

Now let me make it clear, server certificates in a TLS handshake are only used to validate that the server which the client is communicating with, is the server which the client intended to communicate with this. There is NO encryption happening. The encryption portion only starts happening later in the TLS handshake. The client and server both have their own list of cipher suites which they support. As part of the handshake, they agree upon a common cipher suite to use for the duration of the TLS session. This happens after the certificate has been validated by the client. The strength of encryption for the transfer of data over the TLS connection is defined by what cipher suite is used, and NOT by the certificate used. There could be the world's strongest certificate being used, but the cipher suite TLS_RSA_WITH_NULL_SHA is used. This then indicates that the connection is using a NULL cipher, which is incredibly weak since they provide no encryption.

Myth 2 - Free (Let's Encrypt) Certificates Are Insecure

So someone recently suggested that Let's Encrypt certificates are a "really, really, really bad idea". They stated things such as Let's Encrypt having "no skin in the game", since Let's Encrypt is a not for profit organisation and have no owners. Well let me start off by saying that let's look at the facts:

  1. Let's Encrypt is now the world's largest CA.
  2. Let's Encrypt has to comply with the same CA/Browser Forum requirements as any other CA.
  3. Certificates are Domain Validated.
  4. Certificates have a shorter time period than typical CAs (90 days).
  5. Issuance and renew of certificates is automated to a large extend (thanks to the ACME protocol).
  6. Required to transmit certificate issuance to Certificate Transparent (CT) logs.
  7. The ACME protocol (upon which the whole of Let's Encrypt operates) is an IETF standard.
  8. Undergoes WebTrust audits and other CA related audits.

In addition there is the slight issue of CA's who "have skin in the game" who have had issues in the past. Perhaps the best example is Symantec where their legacy CA infrastructure has been pulled from common trust stores such as browser trust stores due to poor practices. Also there is a whole host of sponsors and donors, I'm pretty sure that they help to have some form accountability as well.

In my opinion, not for profit organisations such as Let's Encrypt are more transparent, which allows for greater scrutiny of their services, which leads to increased security. Take for example, their infrastructure. It is largely made public on GitHub. In addition they face the same challenges and risks as any other commercially operated CA, such as the protection of their CA private keys, and appropriate validation of the requester.