Private keys are the cornerstone of TLS security, but also one of the easier things to get right. These days, CAs aren’t allowed to issue certificates against weak keys. But despite frequent focus on key sizes, the weakest link is usually key management, or the job of keeping the private keys private. We’ll touch upon that in this section. Equally important are certificates, which build upon the keys with important metadata, such as the permission to associate a certificate with a particular domain name.

For the certificate private key, you have a choice of RSA or ECDSA algorithms. The easy option is to use RSA keys because they are universally supported. But at 2,048 bits, which is the current minimum, RSA keys offer less security and worse performance than ECDSA keys.

At the same time, ECDSA is the algorithm of the future and RSA is slowly being left behind. A 256- bit ECDSA key provides 128 bits of security versus only 112 bits for a 2,048-bit RSA key. At these sizes, in addition to providing better security, ECDSA is also significantly faster.

By now, ECDSA is very widely supported and the devices that don’t support it are very rare and probably support only obsolete security protocols. If you’re still concerned about interoperability, it’s possible to deploy services with dual certificates, thus supporting RSA and ECDSA keys simultaneously. The only disadvantage of this setup is the increased maintenance overhead. Some managed providers do this automatically and thus make it trivial.

Although we spend the most time obsessing about key size, issues surrounding key management are more likely to have a real impact on your security. There is ample evidence to suggest that the most successful attacks bypass encryption rather than break it. If someone can break into your server and steal your private key or otherwise compel you to disclose the key, why would they bother with brute-force attacks against cryptography?

Treat your private keys as an important asset, restricting access to the smallest possible group of employees while still keeping the arrangements practical. Some CAs offer to generate private keys for you, but they should know better. The hint is in the name: private keys should stay private, without exception.

The security of encryption keys depends on the quality of the random number generator (RNG) of the computer on which the keys are generated. Keys are often created on servers right after their installation and rebooting, but at that point the server might not have sufficient entropy to generate a strong key. It’s better to generate all your keys in one (offline) location, where you can ensure that a strong RNG is in place.

Your keys should have a passphrase on them from the moment they are created. This helps reduce the attack surface if your backup system is compromised. It also helps prevent leakage of the key material when copying keys from one computer to another (directly or using USB sticks); it’s getting increasingly difficult to safely delete data from modern file systems.

Sharing keys is dangerous: if one system is broken into, its compromised key could be used to attack other systems that use the same key, even if they use different certificates. Different keys allow you to establish strong internal access controls, giving access to the keys only to those who need them.

Treat private keys as a liability. Keep track of when the keys were created to ensure they don’t remain in use for too long. You must change them after a security incident and when a key member of your staff leaves, and you should change them when obtaining a new certificate. When you generate a new key, you remove the old key as an attack vector. This is especially true for systems that do not use or support forward secrecy. In this case, your key can be used to decrypt all previous communications, if your adversary has recorded them. By deleting the key safely, you ensure that it can’t be used against you.

Your default should be to generate a new private key with every certificate renewal. Systems with valuable assets that do not use forward secrecy (which is not advisable) should have their keys changed at least quarterly.

Keep a copy of your keys in a safe location. Losing a server key is usually not a big deal because you can always generate a new one, but it’s a different story altogether with keys used for intermediate and private CAs and keys that are used for public key pinning.

Generating and keeping private keys in tamper resistant hardware is the safest approach you can take, if you can afford it. Such tools are known as Hardware Security Modules (HSMs). If you use such a device, private keys never leave the HSM and, in fact, can’t be extracted. These days, HSMs are commonly available as cloud services. They don’t provide the same level of security as tools that you might be able to host in your data centers, but they’re a great improvement nevertheless.

For a small site that needs only a simple domain-validated certificate, virtually any CA will suffice. You can do what I do—just buy the cheapest certificate you can find. Or, if you can automate certificate renewal (highly recommended), just get your certificates for free from Let’s Encrypt and other similar providers. After all, any public CA can issue a certificate for your web site without asking you; what’s the point of paying more if you don’t have to? If you have complex requirements, you may want to explore the commercial options, at which point you should take your time and select a CA that meets your requirements.

At a minimum, you will want to work with a CA that supports both RSA and ECDSA certificate keys. If you care about revocation, your chosen CA must support OCSP certificate revocation checking backed by robust network availability and performance.

We now finally have end user standards for automated certificate issuance (Automatic Certificate Management Environment, or ACME for short), and you should use them wherever possible. For this, you’ll need a CA that supports automation.

PKI is a field that requires deep expertise and dedication; mistakes are easy to make. If you’re going to be relying on a CA for a critical function, you may as well choose an organization that’s serious about it. This is not quite easy to quantify, but you should examine the selected CA’s history, staff, and business direction. It’s best to work with CAs for which certificate issuance is the core part of their business.

At the end of the day, it’s all about the service. The certificate business is getting more complicated by the day. If you don’t have experts on your staff, perhaps you should work with a CA on which you can rely. Costs matter, but so do the management interfaces and the quality of the support. Determine what level of support you will require from your CA, and choose an organization that will be able to provide it when you need it.

You should be aware that if you’re getting your certificates from only one CA, they are your single point of failure. If your deployments are sufficiently important to justify the additional effort, consider getting your certificates from two different CAs at the same time. With overlapping certificate lifetimes, you will always have a backup certificate to use if the primary fails for whatever reason.

Certificate warnings are not unusual and happen for a number of reasons, but all of them can be prevented. The world of technology is confusing enough; you shouldn’t add to the cognitive load your users are already experiencing. If you don’t pay attention, you will confuse them and weaken their confidence in your technical abilities. In addition, for web sites that disable certificate warnings via HTTP Strict Transport Security (HSTS), misconfigured certificates lead to immediate breakage.

Getting certificates right is not very difficult, especially when compared to everything else you need to do to ensure security. With correct initial configuration, renewal automation, and monitoring, you will ensure a smooth experience for your users.

You should pay attention to ensure you have valid certificates for all different domain names and subdomains. As a rule of thumb, keep track of every DNS name that points to your properties and get certificates for all of them. For example, if your main web site is at www.example.com, the domain name example.com should also have a valid certificate, even though this variant will be configured only to redirect your users to the main location. It’s easy to use just one certificate for all of this.

In PKI, private keys and certificates can be shared among properties. This practice is not necessarily insecure, but only if it’s done correctly. If in doubt, don’t share. Don’t use the same certificate on multiple properties; don’t even put different hostnames on the same certificate. With this approach, each property will be independently secured.

The main issue with sharing is that if one property is compromised, the other ones in the same group can also be attacked. If you have a group of properties that are all managed by the same team and are all part of the same system, sharing is not necessarily bad. On the other hand, multiple teams and multiple distinct properties sharing certificates is always bad.

Wildcard certificates have their place. For example, they are best used by a single property when you need to support an arbitrary number of subdomains, usually one per customer. Avoid them otherwise.

Although we spend a lot of time talking about server certificates, in practice we work with certificate chains. Because server operators have to configure these chains manually, mistakes are common. Most often, you will see TLS servers with just the leaf certificate or a set of certificates that don’t actually form a valid chain.

An invalid certificate chain may render the entire TLS connection invalid, leading to a browser warning. To make things worse, this problem is often difficult to diagnose because some browsers try hard to fix it and others don’t. This is a good example of a problem that should be diagnosed by your monitoring tool.

Certification Authority Authorization (CAA) is an evolving security standard that enables you to restrict what CAs are allowed to issue certificates for your properties. CAA is delivered via DNS. When a new certificate is requested, the CA must look for a CAA policy on the affected hosts and verify that they have permission to proceed. If they don’t, the issuance fails.

In the following example configuration, Let’s Encrypt is allowed to issue nonwildcard certificates (issue), DigiCert and Entrust are allowed to issue wildcard certificates (issuewild), no CA is allowed to issue S/ MIME certificates (issuemail), and there is an advertized email address to use to report issuance problems (iodef):

example.com. CAA 0 issue "letsencrypt.org" example.com. 
CAA 0 issuewild "digicert.com" example.com. 
CAA 0 issuewild "entrust.com" example.com. 
CAA 0 issuemail ";" example.com. 
CAA 0 iodef "pki@example.com"

CAA is a very useful addition to the defense arsenal. Even a policy that allows many CAs is helpful as a way of reducing the attack surface, compared to the default, which allows all CAs. Deploying CAA may be difficult in complex environments because a policy set on the apex domain name applies to all subdomains.

When it comes to certificate lifetimes, renew yearly if you’re still doing this work by hand. Aim to automate certificate renewal, then switch to quarterly issuance. Because it is currently impossible to revoke compromised certificates reliably, certificates with shorter lifespans are effectively more secure.

Don’t leave it until the last moment to initiate the renewal. In fact, it’s better if you renew earlier—for example, about a month before the current certificate expires. Doing so will provide you with a margin of safety should the new issuance fail for whatever reason. Many things can go wrong, among them issues with the CA itself or issues with the CAA configuration.

For best results, deploy new certificates to production about two weeks after they are issued. This practice (1) helps avoid certificate warnings for some users who don’t have the correct time on their computers and also (2) avoids failed revocation checks with CAs that need extra time to propagate their new certificates to their OCSP responders.

Since 2018, all public certificates for web sites are recorded via Certificate Transparency (CT), a Google-led effort to improve transparency of the PKI. There are specialized monitoring services (e.g., Hardenize) that observe all recorded certificates and make it possible to find all certificates issued for your properties. CT monitoring is an easy and cost-effective way to understand issuance in complex environments (in terms of who is doing what and where), enforce policy, and catch unexpected certificates or even misissuance.