starred/mkcert

Fork 0

mirror of https://github.com/FiloSottile/mkcert.git synced 2026-04-25 13:36:02 +03:00

[GH-ISSUE #238] Chrome error ERR_CERT_VALIDITY_TOO_LONG #153

New issue

Closed

opened 2026-02-25 22:32:44 +03:00 by kerem · 11 comments

kerem commented

2026-02-25 22:32:44 +03:00

Owner

Originally created by @manrueda on GitHub (Feb 10, 2020).
Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/238

Looks like Google Chrome added a new validation for certificates where it checks that the expiration date is not too far into the future.

By default mkcert created a 10 years long certificate and Chrome does not like that. Can we reduce that or add a flag to customize it with a lower number?

Attached example of error page:

Originally created by @manrueda on GitHub (Feb 10, 2020). Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/238 Looks like Google Chrome added a new validation for certificates where it checks that the expiration date is not too far into the future. By default mkcert created a 10 years long certificate and Chrome does not like that. Can we reduce that or add a flag to customize it with a lower number? Attached example of error page: ![Screen Shot 2020-02-10 at 4 06 29 PM](https://user-images.githubusercontent.com/2576444/74189999-835f9d00-4c1f-11ea-9d38-42337b5b1443.png)

kerem closed this issue

2026-02-25 22:32:44 +03:00

kerem commented

2026-02-25 22:32:44 +03:00

Author

Owner

@luser commented on GitHub (Feb 12, 2020):

If I had to guess Chrome is probably following the same rules as Safari:
https://support.apple.com/en-us/HT210176

@luser commented on GitHub (Feb 12, 2020): If I had to guess Chrome is probably following the same rules as Safari: https://support.apple.com/en-us/HT210176

kerem commented

2026-02-25 22:32:44 +03:00

Author

Owner

@Krato commented on GitHub (Mar 12, 2020):

Yes. But the solution?

@Krato commented on GitHub (Mar 12, 2020): Yes. But the solution?

kerem commented

2026-02-25 22:32:44 +03:00

Author

Owner

@chonthu commented on GitHub (May 22, 2020):

This mean you don't have the latest version, please upgrade to 1.4.1

@chonthu commented on GitHub (May 22, 2020): This mean you don't have the latest version, please upgrade to 1.4.1

kerem commented

2026-02-25 22:32:44 +03:00

Author

Owner

@imriz commented on GitHub (Jun 22, 2020):

The fix in 1.4.1 is a bit strange to me... Why is it setting the notBefore date to 2019, but not setting the notAfter to adhere to the new rules? Why not fix the notAfter too? Do note that the validity limitation is for certificates created after April 1st, 2015.

@imriz commented on GitHub (Jun 22, 2020): The fix in 1.4.1 is a bit strange to me... Why is it setting the notBefore date to 2019, but not setting the notAfter to adhere to the new rules? Why not fix the notAfter too? Do note that the validity limitation is for certificates created after *April 1st, 2015*.

kerem commented

2026-02-25 22:32:44 +03:00

Author

Owner

@imriz commented on GitHub (Jun 22, 2020):

Just to be clear - the current fix will still display this error on Chrome.
The fix should have been to just create certificates which are valid for no longer than 39 months.

@imriz commented on GitHub (Jun 22, 2020): Just to be clear - the current fix will still display this error on Chrome. The fix should have been to just create certificates which are valid for no longer than 39 months.

kerem commented

2026-02-25 22:32:44 +03:00

Author

Owner

@polarathene commented on GitHub (Aug 19, 2020):

Just to be clear - the current fix will still display this error on Chrome.

I use mkcert 1.41 on Linux, with Chrome and I do not experience this issue, nor do I on my Android device with Chrome (added the rootCA.pem to my user credentials).

Is it possible that you've got a different configuration causing it? The cert should be issued prior to 1st July 2019 when the 825 days validation period limit was required, which makes it exempt.

~~Can you provide a link where it states that certs need to have validity <= 39 months?~~ Here we go:

Certificates containing a validity period of more than 39 months may continue to be used after April 1st, 2015 without new limitations;
however, if you reissue a certificate with more than 39 months remaining it will be truncated to 39 months.

So it's ok to issue a certificate with an extended lifetime beyond that from April 2015 onwards. The certificate should be rejected only if the validity period has exceeded 39 months since the issue date (the mention of it being truncated). So we should still be good with the fixed June 2019 issue date workaround until 2022 Q3-Q4?

Summary of these validity reductions, note that the rules for each vary a bit. The latest being for public leaf certificates which may not have any impact on mkcert even if the certs were issued from Sep 2020, the 825 days limit may apply though.

April 2015 onwards: 39 months == 3 years + 90 days renewal
July 2019 onwards: 825 days == 2 years + 90 days renewal (not entirely sure about the extra 5 days)
September 2020 onwards: 398 days == 1 year + 33 day(~1 month with some leeway for stuff like leap years I assume) renewal

@polarathene commented on GitHub (Aug 19, 2020): > Just to be clear - the current fix will still display this error on Chrome. I use `mkcert` 1.41 on Linux, with Chrome and I do not experience this issue, nor do I on my Android device with Chrome (added the `rootCA.pem` to my user credentials). Is it possible that you've got a different configuration causing it? The cert should be issued prior to 1st July 2019 when the 825 days validation period limit was required, which makes it exempt. ~Can you provide a link where it states that certs need to have validity <= 39 months?~ [Here we go](https://www.globalsign.com/en/blog/ssl-certificate-validity-to-be-limited-to-39-months): > Certificates containing a validity period of more than 39 months may continue to be used after April 1st, 2015 without new limitations; > however, if you reissue a certificate with more than 39 months remaining it will be truncated to 39 months. So it's ok to issue a certificate with an extended lifetime beyond that from April 2015 onwards. The certificate should be rejected only if the validity period has exceeded 39 months since the issue date (the mention of it being truncated). So we should still be good with the fixed June 2019 issue date workaround until 2022 Q3-Q4? --- Summary of these validity reductions, note that the rules for each vary a bit. The latest being for public leaf certificates which may not have any impact on `mkcert` even if the certs were issued from Sep 2020, the 825 days limit may apply though. - April 2015 onwards: 39 months == 3 years + 90 days renewal - July 2019 onwards: 825 days == 2 years + 90 days renewal (not entirely sure about the extra 5 days) - September 2020 onwards: 398 days == 1 year + 33 day(~1 month with some leeway for stuff like leap years I assume) renewal

kerem commented

2026-02-25 22:32:44 +03:00

Author

Owner

@FiloSottile commented on GitHub (Oct 25, 2020):

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.)

I am going to drop the workaround and reduce the validity to 2 years and 3 months now, by the way.

@FiloSottile commented on GitHub (Oct 25, 2020): 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.) I am going to drop the workaround and reduce the validity to 2 years and 3 months now, by the way.

kerem commented

2026-02-25 22:32:44 +03:00

Author

Owner

@apijay commented on GitHub (Oct 29, 2020):

@manrueda

Do below to fix the issue

Go to the URL with has certificate issue
Click the grey area
Type "thisisunsafe"
Chrome will now allow requests to the URL.

@apijay commented on GitHub (Oct 29, 2020): @manrueda Do below to fix the issue - Go to the URL with has certificate issue - Click the grey area - Type "thisisunsafe" - Chrome will now allow requests to the URL.

kerem commented

2026-02-25 22:32:44 +03:00

Author

Owner

@FlyingSheepOnSailfish commented on GitHub (Nov 25, 2020):

I have a fresh install of mkcert 1.4.2 on MacOS 10.15.7 made last night via HomeBrew.
This creates certificates with 10 years validity, which are rejected by Chrome 87.0.4280.67 with ERR_CERT_VALIDITY_TOO_LONG.
From the comments above I understood that the standard validity in 1.4.2 should no longer be 10 years.

@FlyingSheepOnSailfish commented on GitHub (Nov 25, 2020): I have a fresh install of mkcert 1.4.2 on MacOS 10.15.7 made last night via HomeBrew. This creates certificates with 10 years validity, which are rejected by Chrome 87.0.4280.67 with ERR_CERT_VALIDITY_TOO_LONG. From the comments above I understood that the standard validity in 1.4.2 should no longer be 10 years.

kerem commented

2026-02-25 22:32:44 +03:00

Author

Owner

@FiloSottile commented on GitHub (Nov 25, 2020):

@FlyingSheepOnSailfish it should definitely not be 10 years on v1.4.2.

Can you open a new issue with the commands you ran and the certificate output?

@FiloSottile commented on GitHub (Nov 25, 2020): @FlyingSheepOnSailfish it should definitely not be 10 years on v1.4.2. Can you open a new issue with the commands you ran and the certificate output?

kerem commented

2026-02-25 22:32:44 +03:00

Author

Owner

@FlyingSheepOnSailfish commented on GitHub (Nov 25, 2020):

Thanks for your rapid response, will do, give me a few minutes. I will also try on Windows 10 later today.

@FlyingSheepOnSailfish commented on GitHub (Nov 25, 2020): Thanks for your rapid response, will do, give me a few minutes. I will also try on Windows 10 later today.