maximum_certificate_lifespan should be 398

[garster]

The maximum_certificate_lifespan should be updated to 398 to match the current CAB Forum guidelines and as implemented by major vendors such as Google and Apple.

https://cabforum.org/2021/04/22/ballot-sc042-398-day-re-use-period/

[gstrauss]

FYI: providing more context for discussion:

This was previously discussed back in 2020 in #271, where 398 days was mentioned as the limit for Apple products that went into effect in Sept 2020. In mid-2020, the server-side-tls guideline version 5.5 changed the maximum_certificate_lifespan for Intermediate and Old from 730 days (2 years, excluding leap day) to 366 days (1 year + leap day).

While matching the CAB Forum guidelines is a reasonable request, is there a huge difference between 366 and 398 when those are the maximums in the guidelines?

https://wiki.mozilla.org/Security/Server_Side_TLS notes that while the Intermediate and Old guidelines suggest a maximum certificate lifespan of 366 days, the recommended maximum certificate lifespan is 90 days in the server-side-tls guidelines. On the wiki, under the Rationale for Intermediate, the wiki says

90 days is the recommended maximum certificate lifespan, to encourage certificate issuance automation

[garster]

I am opening this issue because 366 days is arbitrary where 398 is set by CAB which Mozilla is a member.

398 days matters because it allows for renewing of certs on the same day each year (since their is slop in 13 months) for all the folks that still must renew manually or even renew automated but want to keep an eye on it so the robots don't break things in the middle of the night on a holiday.

There are validation tools that use your guidelines and they are failing validation on perfectly valid certs.

[gstrauss]

I am opening this issue because 366 days is arbitrary

Please keep in mind that such statements, easily proven incorrect, damage the overall credibility of your post.

366 days is not arbitrary. There are 365 days in a typical year, and 366 days in a leap year.

The rest of your post is more observation-based. Thank you for that part.

There are validation tools that use your guidelines and they are failing validation on perfectly valid certs.

Do you by chance have some examples?
As I noted, 366 has been part of the server-side-tls guidelines since version 5.5, published in mid-2020, so can you help us to understand what recently changed that would make it more important to match the CAB guideline?

Please keep in mind that the server-side-tls maximum_certificate_lifespan is intended as a maximum, and as I previously noted, a much shorter time frames (90 days) is recommended.

I found Apple's policy here: https://support.apple.com/en-us/102028
Some SSL providers gave more context:
The change was from 27 months down to ~13 months (plus 2 days; or leap year + 1 day)
https://www.entrust.com/knowledgebase/ssl/apple-reduces-validity-period-for-tls-ssl-certificates-to-398-days
https://www.ssl.com/blogs/apple-limits-ssl-tls-certificate-lifetimes-to-398-days/

https://www.zdnet.com/article/apple-strong-arms-entire-ca-industry-into-one-year-certificate-lifespans/

[clintwilson]

It may also be worth noting that the CA/B Forum is currently discussing a ~4-year phased reduction from 398 -> 200 -> 100 -> 47 days as the maximum certificate validity period: cabforum/servercert#553

[garster]

Mozilla's own policy states a certificate of 398 days is considered valid and the Firefox browser follows that policy:

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

This documentation should follow that policy for consistency.

An example of a tool that uses these guidelines is https://github.com/nabla-c0d3/sslyze and will fail a cert that works fine in all browsers giving a false positive.

The value is named "maximum_certificate_lifespan" and the correct value is 398 as of today.