mirror of
https://github.com/FiloSottile/mkcert.git
synced 2026-04-25 13:36:02 +03:00
[GH-ISSUE #313] Chrome error ERR_CERT_VALIDITY_TOO_LONG with mkcert 1.4.2 #200
Labels
No labels
TLS stack issue
Windows
bug
duplicate
duplicate
enhancement
help wanted
help wanted
pull-request
question
question
root store
waiting for info
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mkcert#200
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @FlyingSheepOnSailfish on GitHub (Nov 25, 2020).
Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/313
This is a follow on to the issue "Chrome error ERR_CERT_VALIDITY_TOO_LONG #238". I am opening a new issue as requested by FiloSottile.
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 in the issue #238 I understood that the standard validity in 1.4.2 should no longer be 10 years.
Both the Root Authority and a certificate created by it are valid 10 years:
Root Certificate Authority
Expires: Sunday, 24 November 2030 at 23:14:42 Central European Standard Time
Certificate Created with “mkcert -csr xxxx”
Expires: Monday, 25 November 2030 at 11:09:18 Central European Standard Time
The commands I ran were:
This process is essentially the same as I would follow using an "official" Certificate Authority.
Viewing the certificate with Java keytool gives:
I will try an install on Windows 10 next.
@FlyingSheepOnSailfish commented on GitHub (Nov 25, 2020):
By comparison, the mkcert RootCA.pem has a much shorter validity of two years and a few months:
Whereas certificates created with "mkcert -csr" are valid 10 years....
The issue can be reproduced on Windows 10.
@FiloSottile commented on GitHub (Nov 25, 2020):
Ah, this was fixed in
9c196b6cdbwhich I didn't cut a release for, sorry.v1.4.3 coming in a second.
@FlyingSheepOnSailfish commented on GitHub (Nov 25, 2020):
I am very impressed, thank you.
Our goal has always been to do Https / SSL properly, and as close a final production setup as possible, from the first day of development.
Using mkcert for development should allow us to this 8-)
@FiloSottile commented on GitHub (Nov 25, 2020):
Please test v1.4.3 (or simply install with
--HEAD) and check that this issue should be resolved.@FlyingSheepOnSailfish commented on GitHub (Nov 25, 2020):
Thanks, what is the quickest / easiest way for me to get 1.4.3? So far I have been using Homebrew:
brew upgrade mkcert
Warning: mkcert 1.4.2 already installed
brew install --HEAD mkcert
Error: No head is defined for mkcert
@FiloSottile commented on GitHub (Nov 25, 2020):
Ah, the two quickest options if --HEADis not available are to download a binary form the releases page here, or by using homebrew-gomod.
@FlyingSheepOnSailfish commented on GitHub (Nov 25, 2020):
I was able to install on MacOS with homebrew-gomod, but now get this error:
mkcert -csr acme_demo.csr
panic: runtime error: index out of range [0] with length 0
goroutine 1 [running]:
main.(*mkcert).fileNames(0xc000113f00, 0x0, 0x0, 0x0, 0x0, 0x0, 0x121fc40, 0xc0000b22a0, 0xc00048a000, 0x470)
/Users/christopherlamb/go/pkg/mod/filippo.io/mkcert@v1.4.3/cert.go:177 +0x3cc
main.(*mkcert).makeCertFromCSR(0xc000113f00)
/Users/christopherlamb/go/pkg/mod/filippo.io/mkcert@v1.4.3/cert.go:266 +0x7c8
main.(*mkcert).Run(0xc000113f00, 0xc00009c1a0, 0x0, 0x0)
/Users/christopherlamb/go/pkg/mod/filippo.io/mkcert@v1.4.3/main.go:203 +0x64a
main.main()
/Users/christopherlamb/go/pkg/mod/filippo.io/mkcert@v1.4.3/main.go:145 +0x851
Using the asset https://github.com/FiloSottile/mkcert/releases/download/v1.4.3/mkcert-v1.4.3-windows-amd64.exe
I get the same error on Windows 10.
mkcert-v1.4.3-windows-amd64.exe -uninstall and -install work with 1.4.3
@FiloSottile commented on GitHub (Nov 25, 2020):
This is what I get for not testing the CSR path. v1.4.4 and some integration tests coming soon.
@FlyingSheepOnSailfish commented on GitHub (Nov 25, 2020):
My CSR was created without the -ext attribute (and was accepted by 1.4.2)
https://stackoverflow.com/questions/30755220/how-to-create-csr-with-sans-using-keytool/43637750#43637750
Reading your 1.4.3 code, it looks like some extensions are expected.
gives:
@FiloSottile commented on GitHub (Nov 25, 2020):
Yeah, mkcert is supposed to fill those in if they are missing, but I was not testing for that, I'll fix it, thank you.
@FlyingSheepOnSailfish commented on GitHub (Nov 25, 2020):
...that was my first time desk-checking golang code!
And the really important thing, Chrome now accepts that the certificate is valid, and that the connection is secure! Yippee!
@FiloSottile commented on GitHub (Nov 26, 2020):
Hmm, the code does set DNSNames to CommonName if there is no SAN extension. It sounds as if there was a SAN extension but it was empty, which would be weird. Can you share the CSR that causes issues?
@FlyingSheepOnSailfish commented on GitHub (Nov 26, 2020):
Below are the two csr as viewed by openssl. otms_demo.csr.old is the "bad" version without extensions. Both csrs are in the attached zip file.
csrs.zip