398-day limit on cert lifespan starting Sept 1, 2020 - will this break mkcert?

[rfay]

I know there's been lots of talk about this but I don't see an open issue. As of September 1, 2020,

Starting with September 1, 2020, browsers and devices from Apple, Google, and Mozilla will show errors for new TLS certificates that have a lifespan greater than 398 days

(zdnet article)

mkcert certs have an 11-year lifespan, but the issue date is May 31, 2019. IIRC the issue date dodged another clamp-down last year, and certs issued before June 1, 2019 were allowed.

But I'm concerned and would like reassurance that mkcert certs will work OK in Fall, 2020.

Thanks!

[mtodd]

I'm actually seeing Chrome enforce this with net::ERR_CERT_VALIDITY_TOO_LONG errors (Chrome version 84.0.4147.89) on a certificate that was generated today with mkcert, even though the enforcement shouldn't apply to certificates that are created before September 1st (according to https://chromium.googlesource.com/chromium/src/+/master/net/docs/certificate_lifetimes.md).

Someone pointed out to me that imriz@6c86a71 would fix this, but I also noticed that there's not a way to control the expiration, which would be handy to at least get me a functional certificate while I figure out why Chrome has decided to apply this rule prematurely.

[rfay]

Agreed that @imriz PR #271 is the right approach for this. And it should be followed by a release so we can all get ready.

@mtodd I'd sure be interested to know why that's happening to you already, even though it's not happening to others.

[mtodd]

@rfay me too 😭 🙈

[polarathene]

I'm actually seeing Chrome enforce this with net::ERR_CERT_VALIDITY_TOO_LONG errors (Chrome version 84.0.4147.89) on a certificate that was generated today with mkcert

I am on Linux with Chrome version 86.0.4214.2, just created a cert via mkcert (version 1.4.1) and I have not encountered this issue. The cert was issued to example.localhost hostname and the machines local IP(HTTPS access from Android Chrome, as no custom DNS service setup and support for mDNS isn't available).

---

enforcement shouldn't apply to certificates that are created before September 1st (according to https://chromium.googlesource.com/chromium/src/+/master/net/docs/certificate_lifetimes.md).

I don't believe it applies to mkcert at all?:

Beginning with Chrome 85, TLS server certificates issued on or after 2020-09-01 00:00:00 UTC will be required to have a validity period of 398 days or less. This will only apply to TLS server certificates from CAs that are trusted in a default installation of Google Chrome, commonly known as “publicly trusted CAs”, and will not apply to locally-operated CAs that have been manually configured.

Does not apply to locally-operated CAs, only publicly trusted CAs as acknowledged by Google.

The linked Apple document also states the following:

This change will affect only TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS.
This change will not affect certificates issued from user-added or administrator-added Root CAs.

The previous change to 825 days from June 2019 seemed a bit more broad of an enforcement than this one.

Mozilla has further clarification:

The intent would be to not affect the duration of leaf certificates from non-built in roots, unless there is some other technical implication of which I am unaware.

SSL.com coverage:

My company has a privately-trusted root CA. Are privately-trusted SSL/TLS certificates subject to the new 398-day limit?
No. Apple’s change only extends to publicly-trusted root CA certificates pre-installed on its devices, including SSL.com’s roots. Root certificates installed by a user or administrator are not affected by the 398-day restriction.

There has been another link shared in one of the related issues about this change(not the ZDNet one), this one has a bit more clarity from the comments section with the author responding:

Does this also apply to the CA’s intermediate and root certs? Those things are good for 10-20 years.
I’ve updated the beginning of the article to specify that it’s the leaf certificates specifically that will be affected.
To be clear, these announced changes are for public TLS leaf certificates only. Other certificate types, including intermediates, are unaffected. Likewise private-trust certs are unaffected.

---

TL;DR

Only public leaf certificates should be affected. These have publicly trusted root CAs, as in the default ones installed with your system/client. See public vs private trust.

I could be mistaken with desktops. On Android, I imported my rootCA.pem and it is categorized as a user credential, not trusted credential. It has a 10 year validity period(18th Aug 2020 - 2030), it's unaffected by the earlier 825 days restriction that leaf certs are working around via a Not Before issue date starting prior to the restriction coming into effect(1st July 2019): 1st June 2019 6/1/19 - 18th Aug 2030 8/18/30.

So I don't see this being an issue for leaf certs, nor the root CAs, only the leaf certs that are issued with a start date from 1st Sep 2020, which won't happen with mkcert?

Related: #241
Related PR: #271

Related(but not specific to Sep 2020 change): #238

[orlandothoeny]

I'm getting NET::ERR_CERT_VALIDITY_TOO_LONG as well. After updating to MacOS Catalina.
On Chrome 85.0.4183.121.
It worked before.

[polarathene]

@orlandothoeny it's in your systems trust store? What if you make a leaf certificate from it(eg with Caddy)?

I'm on v87 of Chrome (dev/beta) but on Linux and I haven't noticed any issues with private root certs having 10 years validity. I haven't used mkcert in September with an issue date to verify though, last testing was earlier in the month with Caddy, it issues a 10 year root certificate that I added to my trust store, then intermediate and leaf certificates from that. Presently working with smallstep certs where root is again 10 years, but I've not tried these with Chrome yet.

Have you tried issuing the certificate for something other than localhost? Say sub.localhost or example.test (test is a TLD that won't resolve publicly as you can't register a public domain with it, but it's valid for testing locally). I don't have macOS myself to investigate, but resources I came across were pretty clear that private CA certs shouldn't have been affected.

[orlandothoeny]

It works again after updating mkcert & generating a new certificate:

[FiloSottile]

None of the 1 year rules affect publicly trusted certificates. The only rule that applies is the 825 days one, which since mkcert v1.4.1 we are bypassing by backdating the certificates. If anyone encounters the ERR_CERT_VALIDITY_TOO_LONG error, they should update mkcert to the latest version and generate a new certificate. (No need to reinstall the root.)