What You Need to Know About Shrinking Certificate Lifespans

Keys and certificates comprise the critical fabric that enable privacy on the Internet, or for that matter, any data in motion on a network or stored on computer systems. Transferring data in an encrypted state prevents a middleman from reading intercepted communications. But those same keys and certificates are jeopardized by two things: 1) the impending breakability of current cryptographic algorithms, and 2) how securely they’re stored and accessed.

With Moore’s Law in effect and quantum computing on the horizon, how much longer will your certificates be able to protect your encrypted data before brute forcing them enters the realm of convenience? A shift in the current paradigm of certificate management is looming.

Certificates and cryptography: the fabric of security

In the mid 1990s—early in the days of Internet commerce—Netscape introduced the Secure Sockets Layer (SSL) protocol as a feature of their cutting edge (at the time) Navigator browser. The need to encrypt data in transport was clear, as more websites and services were implementing authentication, making cryptography an important part of the future. It was also the beginning of a wild growth era in online shopping, with credit card numbers being submitted via the browser. It was the Wild West, and a solution for encrypting sensitive data to protect consumers as well as businesses was needed.

The standard for presenting a verified and validated public key associated with a specific identity and signed by an accredited organization was born as the X.509 certificate, a specification that is pretty much unchanged today. The X.509 specification actually predated the use of SSL in browsers, but it was adopted as the standard bundle in the 90s. Public CAs will use their exclusive private key, called a root certificate, to sign the issued certificates in X.509 format.

Fast forward to around 2010. Internet commerce was booming. Google announced that websites using 100% HTTPS/TLS would rank higher in search results—either to altruistically push better security for the Internet, or to protect ad revenue from middlemen positioned to insert their own ads into an unsecured traffic flow. Possibly for both reasons.

This initiative by Google drove a massive increase in the use of encryption for websites. Additionally, its Chrome browser is continually upgraded to play a role in enforcing secure transport method, and since version 90 has defaulted to the HTTPS protocol before trying unencrypted HTTP.

Use cases for encryption

While the above background focuses on the web browser, there are multiple other use cases that require encryption and the use of certificates:

Email is the workhorse of the Internet and relies heavily on the use of SSL/TLS for everything from verification of an email server’s domain identity to the encryption of authentication credentials, data at rest, and transported data.

VPNs, or Virtual Private Networks depend on encryption to establish a tunnel across a public network. This is a popular way for organizations to securely transport data between offices and data centers without worrying about their traffic being compromised by a middle man. It’s also a popular way to mask internet user identity and origin to remain invisible to censors or traffic monitors, such as in peer-to-peer file sharing or in regions where content is regulated by heavy-handed governments.

The clock is counting down on your certificates

How long is a certificate realistically viable today? A few years ago public certificate authorities (CA) would issue certs with 18-36 month expiration dates, but no longer.

The promise of cryptography is that the high bit length keys created by the latest algorithms (RSA, AES, etc.) would require such immense computing power in order to brute-force crack them that no hardware could accomplish it. But with the advent of purpose-built hardware designed for cryptocurrency mining, the prospect of breaking key hashes inside the certificate change interval is starting to come closer to fruition. And we’re all familiar with Moore’s Law, which essentially states: the technological state of computing power doubles every two years. Based on observation of historical advancements, it has mostly held true for transistor-based processor architectures.

Some of the well-known cryptographic algorithms used in the early Internet such as DES, MD5, and SHA were broken in some form over the past 20 years. With hardware innovation in those two decades since, how long will the popular modern algorithms used in networking last, such as RSA, Elliptic Curve, and ElGamal? It’s not necessarily a question of “if” rather than “when/who” given the motives of nation state attackers to break their adversaries’ data.

Throwing horsepower at cryptographic problems entered the mainstream with the advent of cryptocurrency. The entire premise of Bitcoin and its contemporaries is to competitively hash values by brute force to be the first to solve via “proof of work” and claim the entry in the distributed ledger. The evolution from CPU to GPU and now ASIC hardware designs has landed on very specifically designed hardware for cracking hashes. Such hardware also exists for the express purpose of breaking keys and password hashes.

Quantum computing

The juggernaut of technological advancement never stops. Once firmly in the realm of science fiction, quantum computing is actually very close to becoming reality. Based on the premise that instead of a two binary states used in conventional processors, computing can be based on simultaneous states, making mathematical computations much higher performance, such as the type where integers are factored into prime numbers as a way to reverse an algorithmic hash.

Advances in quantum computing will focus on this particular use case—high performance number crunching. And extreme mathematical performance is what’s required to brute force cryptography—more a motive of nation states seeking to break encryption than a consumer one.

Even NIST recognizes there’s a problem down the road in regard to what’s captured now can still be broken in the future. It’s called the store-and-break threat. If there’s an opportunity to steal encrypted data now—data that uses today’s algorithms—adversaries can just keep it on ice until they develop a machine powerful enough to break it. Depending on the data, it could still be sensitive or strategic 20 years from now.

NIST recommends starting the process of preparing for life after quantum computers now. Adhere to better than best practice in encryption and data storage and maximize use of newest available cryptographic standards. For example, use of AES256 algorithm could be future-proof, as computer scientists believe its symmetric algorithm is said to take billions of years to brute force even with a powerful quantum computer.

What is the new ideal certificate life span?

The simplest way to reduce the attack surface as related to certificate and key management is to simply shorten their lifespan. The ramifications of having compromised keys, whether by breach or by being brute forced, are critical and severe.

At present, the longest certificate expiration available from public CAs is just a little over one year at 380 days, and this expiry is expected to continue getting shorter. Some experts are of the opinion that we’re already at a point in time where a 30 day certificate lifespan is best practice, and in a few years will shorten to just one day.

Certificate management is easier than ever

Ask any system administrator and they’ll tell you the dread involved with having to renew and install new certificates. Until recent years it was a very manual process of purchasing the certificates from a public CA, downloading them, then installing in the right place on the server or in hardware. And if an expiration date accidentally went by without renewing? Havoc for users, customers, and everyone involved as stuff breaks. At enterprise scale it can be a nightmare.

But with the advent of scriptable infrastructure—virtualized servers that are built fresh using a repeatable recipe via orchestration, then deployed using containers—the stage is set for automation to cycle certificates at any set interval. This convenience in automatically refreshing certificates has placed greater demands on the public certificate authorities, but it’s a step in the right direction for the shorter certificate lifespan increasing computing power has necessitated.

Let’s Encrypt

One solution that’s helped to usher in scripted certificate renewal is Let’s Encrypt. It’s a free, automated open certificate authority created by the Internet Security Research Group, and uses a protocol called ACME to request certs and verify domain ownership. Using one of several available client tools, such as acme.sh, new certificates can be installed and set up to refresh at a set interval. The user experience for Let’s Encrypt is based on achieving total automation in data encryption to remove the cumbersome manual steps. As Let’s Encrypt has gained in popularity so has ACME, and now several public CAs and private trust CAs support it.

Best practices for key and certificate management

Armed with some background on cryptographic security and having made the case for shortened certificate lifespans, let’s look at some best practices for certificate and key management.

There’s no metaphor strong enough to emphasize the criticality of protecting keys. They are literally a key to gain entry to systems and networks without knowing any information such as a password. Storage of keys, especially in an environment necessitating higher volumes of unique keys, can be the lynchpin of an organization’s security.

If you’re wondering what the acceptable and best practices for cryptographic technologies are, the National Institute of Standards and Technology (NIST) has compiled standards and guidelines to almost every use case.

Shorten key and certificate lifespans

While the best practices that follow are key storage related, an irrefutably wise technique is to reduce the amount of time a particular certificate or key is in use. The longer it’s in use, the more time adversaries have to steal or brute force it. By shortening the lifespan to 30 days or less, which is definitely made less painful by the automated techniques mentioned above, there just isn’t enough time for a modern computer to brute force current encryption.

HSMs

Best practice for key storage is to use a Hardware Security Module (HSM), an appliance that is purpose built to generate and store keys in a “vault” and makes using them convenient and secure. There are both cloud and on-premises versions of HSMs today. While we advocate for on-premises versions, cloud versions offer many of the same protections.

Software Key Vaults

If it’s not possible to host a HSM, the next best solution is a purpose-built software solution. The top choices include Kubernetes Cert Manager and Hashicorp Vault for protecting keys and secrets.

Not recommended

Using standard servers as an ad hoc key storage solution is not recommended. Without a security-focused OS and with more lenient network access, a server used as a key manager can fall victim to any number of attacks. Once the keys have been breached, anything and everything becomes accessible to attackers.

Conclusion

While the prospect of faster hardware and quantum computing on the horizon is exciting, it poses some grave risks to the security and privacy we currently enjoy with encrypted Internet traffic.

Most researchers are in agreement that maximum security takes long planning and implementation cycles—it’s taken 20 years to achieve the current level of encryption rollout—so it’s best to start today. Among the lowest hanging fruit to ensure your encryption holds up is to just renew certificates and cycle out keys on a shorter interval. The tools to manage and automate the process hands-off are readily available and documented.

Start planning today to first achieve 30-day certificate lifespan, then work toward 1 day intervals. The industry will be there in a matter of a few years.