September ushers in halved TLS cert lifespans

From September 1, X.509 Transport Layer Security (TLS) digital certificates with a validity period of more than 13 months or 398 days will no longer be issued.

This is down from the existing 27 months or 835 days life span and is being implemented despite a vote in September last year by members the industry Certificate Authority/Browser Forum that went against the move.

Certificate authorities felt that shortening the validity periods of TLS certificates would lead to problems for users when it came to managing the more frequent renewals.

On the other hand, long-validity TLS certificates were seen by browser vendors as a security problem, should the digital credentials fall into the wrong hands.

In March this year, Apple decided it would shorten the maximum allowed lifetimes of new TLS certificates to 398 days issued from September 1 2020 onwards, despite the CA/Browser Forum vote.

The move forced Certificate Authorities and organisations opposed to the shortened vailidity time to fall in line in May.

Mozilla and Google, both proponents of shorter TLS certificate lifespans, joined Apple in July this year, and announced that they too would go with 398 days validity only.

Existing certificates with 27-month validity periods will continue to be accepted by browsers until they expire.

The funny thing about the Certificate Authority ecosystem is the authorities... don’t actually have any. That dynamic has rapidly become evident in recent years. The TLS stack owners (browsers) write the code and rules. Everything else functions by their grace alone.

— SwiftOnSecurity (@SwiftOnSecurity) August 30, 2020

Apart from limiting exposure time to compromise, another reason for shortening the lifetime of TLS certificates is that they could outlive domain name ownership otherwise.

The mismatch in lifespans meant someone could sell their domain name to another person or organisation, and still have a valid TLS certificate for it.

In that scenario, the valid TLS certificate could be used for man-in-the-middle interception attacks.

TLS certificates with subject alternative names for domains also presented a hazard.

If it was no longer owned by the owner of the credential, certificates with the vulnerable alt-name and other domains could be revoked, which would stop TLS authentication and secure communications for a site or service.