Late last year the CA/Browser Forum decided to limit the maximum valid term of TLS/SSL certificates issued after 1 April 2015. After this time, as the official guidelines put it..

CAs SHALL NOT issue certificates with validity periods longer than 39 months.

I've recently been (re)issued a certificate with a validity period of 2015-04-07 08:57:25 GMT to 2018-07-09 07:00:18 GMT. This looks a lot like 39 months and 2 days to me but every single SSL checker I've used says it's totally valid. It also works fine in Firefox 37.0.1 and Internet Explorer 11.0.9600.

Problem is, Chrome gives me a NET::ERR_CERT_VALIDITY_TOO_LONG error, a point with which I tend to agree. This occurs in versions 42.0.2311.68 m and 44.0.2360.0 canary (64-bit).

Is this an issue with the certificate or a bug in Chrome?

More specifically, how are "months" supposed to be calculated for the purpose of TLS/SSL certs?

Note this shouldn't be related to the sunsetting of SHA-1 signed certificates that happened in Chrome 42, the new cert is definitely signed with SHA256.

Certificate details


1 Answer 1


It should be noted that there's nothing wrong with the certificates from a TLS or x509 point of view. The CA/Browser forum applies to CAs issuing publicly-trusted certificates that subscribe to those guidelines. Not all TLS or x509 use cases involve public trust.

An internal government or enterprise CA, for example, might reasonably choose to completely ignore these guidelines. In fact, if Chrome is applying those rules strictly to non-public certificates it's kinda contradicting x509v3:

In some situations, devices are given certificates for which no good expiration date can be assigned. For example, a device could be issued a certificate that binds its model and serial number to its public key; such a certificate is intended to be used for the entire lifetime of the device.

Obviously Chrome is under no obligation to accept such certificates, but they are a legitimate type of certificate nonetheless. An intranet user who wants to trust their own intranet CA (say, Active Directory) might find Chrome prevents them from doing so, based on requirements that are irrelevant to them because they don't subscribe to the CA/Browser forum.

It is incorrect to say that an x509v3 certificate is invalid because it has a long expiration date in the general case.

It is correct to say that an x509v3 certificate is invalid because it has a long expiration date when it is being issued by a ca which is expected to conform to the CAB requirements and is consumed by a user-agent which expected to conform to the CAB requirements.

It is therefore important to recognise that there's no intrinsic technical mechanism for determining whether a CA is supposed to be CAB conformant or not. Thus, browsers are left to either:

a) Assume the CAs subscribed to the CA/Browser Forum are conforming appropriately and accept false positives if the CA doesn't conform, for whatever reason.

b) Aggressively reject certificates that don't conform to the requirements in every case, regardless of who the CA is, imposing CAB-style requirements even where they might be actively harmful.

Neither is wrong, I think (unless there's a bit of the CAB that puts an obligation on the browser, I can't claim to have memorised the entire thing word for word - See addendum). What is correct is the SSL testers you've used don't reject the certificates as being inherently invalid. Without any context, it would be wrong to say they were invalid.

The outcomes you've described, then, is exactly what one might expect from these requirements and the answer to the question "Is this an issue with the certificate or a bug in Chrome?" is, in my opinion, the certificate, because it was issued by a CAB-forum subscribed CA that failed to implement their obligations in a non-ambiguous manner, forcing the browsers to make up their own mind about whether to enforce those obligations by veto or not.


The Requirements are not mandatory for Certification Authorities unless and until they become adopted and enforced by relying–party Application Software Suppliers.

Chrome (a relying-party Application Sof..... zzzz) have adopted and are enforcing it, thus by the letter of the law we can assert is mandatory for CAs that are dealing with publicly-trusted certificates and are subscribed to the CAB Forum requirements to create certificates that conform to this requirements.

(Unless we're being hyper-pedantic, in which case it's a plural and we'd actual need 2+ browsers to enforce it because otherwise Chrome is only a relying-party Application Software Supplier, not Suppliers.)

I think it's amusing that the obligations CAs are actually bound to changes depending on individual implementation details in every supplier. Any time a web browser or any software associated with the CAB anywhere in the entire world is updated suddenly a CA might have to implement a requirement that they didn't previously.

Thus, until it failed in Chrome, there was no obligation on the CA to conform. The moment Chrome was patched to start throwing this error, the CA was in breach of their obligations. Surprise, MF!

  • As of late 2020, MacOS 10.15+ is now enforcing the 2018 CAB 825 day limit even for Internal CAs. Which propagates to Safari and Chrome but not Firefox and not Chrome on Windows. support.apple.com/en-us/HT210176 It never ends.
    – BaseZen
    May 13, 2021 at 19:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .