From September onwards, HTTPS certificates may only be issued for a maximum of one year.
Reading time: 1 min.
The maximum validity of certificates for proof of identity on the web will be further reduced – in the next step to one year. Although a vote on this issue in the CA/Browser Forum failed in September due to resistance from the certification authorities, it is still being discussed. But in March Apple came forward and declared that Safari will only accept certificates issued after September 1, 2020 if they are not valid for more than one year.
Now Mozilla and Google are following suit and creating facts. In the past, terms of 5 years were not unusual. Currently, certificates may still be issued for 2 years (more precisely: 825 days — i.e. plus some grace period). With the renewed tightening, Chrome, for example, delivers an ERR_CERT_VALIDITY_TOO_LONG if a certificate was issued after September 1, 2020 and is valid for more than 398 days.
Revocation broken
The main reason for the constant shortening of the certificate lifetime is the fact that there is no generally functioning revocation mechanism by which a certificate could be revoked. Revocation lists (CRLs) and the Online Certificate Status Protocol (OCSP) have proven to be unsuitable and are now switched off by default.
The browser manufacturers still maintain their own internal revocation lists, which they can use to react to acute incidents. But this is a quasi manual procedure that can only cover significant problem cases. Ultimately, the browser manufacturers are now focusing on damage limitation: if, for example, the secret key of a certificate is stolen, an expiration date that is approaching as soon as possible should solve the problem.
No need for action for users
Lets Encrypt, which meanwhile dominates the market, is the pioneer and only issues certificates for 3 months anyway. Renewal is then automated via ACME. According to Mozilla, however, the other certification authorities have also agreed to only issue certificates for 398 days from September 1. In view of the demonstration of power of the browser manufacturers, they probably don’t have much choice.
As a web site operator, you don’t have to do anything else – even if you still have a certificate with a longer validity in operation. The new rule only applies to certificates issued after September 1, 2020.
If the browser vendors were really interested in a secure and open web, they would properly implement DANE.
Can someone verify whether this is a restriction on policies of included CAs or a restriction on certificates themselves?
I did not check (yet), but I would imagine that checking the certificate lifetime directly would break too many things, and the browsers will be made responsible for that by their own users.
On the other hand, placing an additional restriction on CA policies is less work (or at least not more work) to implement and leaves a workaround for many things that would break otherwise. And the CAs will be made responsible for resulting problems (“Why did you not implement auto-renewal?”).
The CAs themselves have a quick and cheap excuse for their own customers: “It’s the browser’s fault”
But, the good news, CAcert would not be affected, at least on short terms…
Having said this, of course it makes sense to implement auto-renewal for CAcert. But I’d prefer to do it on our own schedule…
I just did it myself and checked the references from https://bugs.cacert.org/view.php?id=1482.
The from Apple is “This change will affect only TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS.”
Chromium’s statement is “Enforce publicly trusted TLS server certificates …”, which is not as specific as Apple’s, but could be interpreted the same way…
This seems to support my view on the topic, that CAcert is not affected (since we are not included in preinstalled CAs) are there other opinions?