Closed FlyingSheepOnSailfish closed 4 years ago
By comparison, the mkcert RootCA.pem has a much shorter validity of two years and a few months:
keytool -printcert -file mkcertRootCA.pem
Owner: OU=christopherlamb@ApplePippa (Christopher Lamb), O=mkcert development certificate
Issuer: CN=mkcert christopherlamb@ApplePippa (Christopher Lamb), OU=christopherlamb@ApplePippa (Christopher Lamb), O=mkcert development CA
Serial number: fde33abec1875b5176206f88c21991e3
Valid from: Wed Nov 25 11:08:00 CET 2020 until: Sat Feb 25 11:08:00 CET 2023
Whereas certificates created with "mkcert -csr" are valid 10 years....
The issue can be reproduced on Windows 10.
Ah, this was fixed in 9c196b6cdb3bfaa43504a52bf52ae41644f0094f which I didn't cut a release for, sorry.
v1.4.3 coming in a second.
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-)
Please test v1.4.3 (or simply install with --HEAD
) and check that this issue should be resolved.
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
Ah, the two quickest options if --HEADis not available are to download a binary form the releases page here, or by using homebrew-gomod.
brew install FiloSottile/gomod/brew-gomod
brew gomod filippo.io/mkcert
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
This is what I get for not testing the CSR path. v1.4.4 and some integration tests coming soon.
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.
keytool -certreq -alias acme_demo -file acme_demo.csr -keystore acme_demo.jks -ext "SAN=dns:acme.demo,dns:localhost,ip:127.0.0.1"
mkcert -csr acme_demo.csr
gives:
Created a new certificate valid for the following names 📜
- "acme.demo"
- "localhost"
- "127.0.0.1"
The certificate is at "./acme.demo+2.pem" ✅
It will expire on 25 February 2023 🗓
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.
...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!
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?
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.
openssl req -in otms_demo.csr.old -noout -text
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=CH, ST=ZH, L=Zurich, O=IBM, CN=otms.demo
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c7:cd:32:c5:9b:f0:90:86:ad:8f:30:7a:47:1d:
4c:e0:5f:b9:ef:e8:42:77:19:0b:70:16:94:80:9a:
22:9b:e4:39:c2:74:bd:a1:58:36:65:85:21:a0:f4:
6b:5b:33:12:c1:4a:1a:62:3d:12:84:8a:95:6f:41:
d7:cf:f5:8d:9f:c0:cd:8d:d4:32:4f:9e:20:0b:f1:
e3:00:ca:f3:0a:c3:e9:85:cd:e0:ab:1c:5d:d6:dd:
3a:1f:6d:6a:dd:ce:33:8e:e7:33:95:35:6d:19:e2:
85:97:52:b2:49:7c:c9:10:56:18:45:de:b6:c3:f8:
3b:70:2e:09:56:56:81:e5:2b:62:2e:1e:45:d2:a1:
09:c8:a8:13:d1:d4:af:92:87:e8:17:19:14:8a:d8:
ac:27:09:03:bb:5a:73:56:c0:e2:b2:9b:2c:b6:9e:
e7:11:44:d6:86:ef:c5:35:8c:32:21:3d:8f:e3:3d:
3a:b2:87:fc:93:78:6c:64:52:03:28:b1:b7:c6:bb:
fb:d9:4e:28:68:33:5d:fc:4b:b4:c5:fc:eb:52:b7:
a0:af:40:3c:f0:ef:e9:d8:3f:83:c1:6c:24:85:59:
2a:9b:85:88:91:ed:22:7c:88:37:b3:b3:64:df:e5:
d6:70:3d:4a:7a:48:6b:85:b2:89:36:53:29:b4:5f:
5e:45
Exponent: 65537 (0x10001)
Attributes:
Requested Extensions:
X509v3 Subject Key Identifier:
E7:E7:89:E8:A1:96:A6:84:F5:0D:8C:D4:F0:44:A1:48:82:9E:6B:66
Signature Algorithm: sha256WithRSAEncryption
20:22:68:10:69:36:87:e9:82:b7:4f:85:19:68:01:02:97:93:
ad:bf:2e:5e:06:35:77:1b:9e:85:d5:4b:f0:79:2c:a8:2e:0d:
6c:99:f3:94:ea:58:0c:dc:ef:37:af:0a:d1:80:64:58:61:5e:
17:09:2d:b6:a3:9d:a0:a9:ca:90:61:dd:b3:40:69:38:3d:d5:
28:a6:69:07:3f:a1:d4:f5:48:97:85:5e:0e:9a:f7:2f:c0:0c:
64:d3:dc:a9:99:ee:61:cf:cb:53:dd:ac:91:83:05:f4:a4:60:
4f:69:9f:1b:f5:48:98:e2:5e:c8:8d:ce:12:75:7c:37:b9:32:
cb:e5:77:27:6d:d9:e1:e6:0c:3c:2a:58:62:32:ce:7f:2a:fa:
05:42:91:5d:d8:f2:2e:f3:00:26:cf:80:70:5f:9c:16:62:53:
13:83:39:47:d2:36:d0:76:c4:b2:c1:db:17:55:34:db:0b:48:
d1:31:db:50:8d:05:90:86:93:3a:0f:2b:61:05:e7:65:07:f8:
be:f8:71:ca:59:51:c2:34:2b:5e:6c:b4:90:32:4c:df:86:89:
6f:ee:3e:3d:ea:e5:67:56:c7:c8:e3:cc:8b:ff:dc:6d:2b:52:
93:80:44:bf:50:aa:ed:b0:b9:6d:df:6d:ae:6c:67:60:74:71:
4c:4d:90:7f
openssl req -in otms_demo.csr -noout -text
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=CH, ST=ZH, L=Zurich, O=IBM, CN=otms.demo
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c7:cd:32:c5:9b:f0:90:86:ad:8f:30:7a:47:1d:
4c:e0:5f:b9:ef:e8:42:77:19:0b:70:16:94:80:9a:
22:9b:e4:39:c2:74:bd:a1:58:36:65:85:21:a0:f4:
6b:5b:33:12:c1:4a:1a:62:3d:12:84:8a:95:6f:41:
d7:cf:f5:8d:9f:c0:cd:8d:d4:32:4f:9e:20:0b:f1:
e3:00:ca:f3:0a:c3:e9:85:cd:e0:ab:1c:5d:d6:dd:
3a:1f:6d:6a:dd:ce:33:8e:e7:33:95:35:6d:19:e2:
85:97:52:b2:49:7c:c9:10:56:18:45:de:b6:c3:f8:
3b:70:2e:09:56:56:81:e5:2b:62:2e:1e:45:d2:a1:
09:c8:a8:13:d1:d4:af:92:87:e8:17:19:14:8a:d8:
ac:27:09:03:bb:5a:73:56:c0:e2:b2:9b:2c:b6:9e:
e7:11:44:d6:86:ef:c5:35:8c:32:21:3d:8f:e3:3d:
3a:b2:87:fc:93:78:6c:64:52:03:28:b1:b7:c6:bb:
fb:d9:4e:28:68:33:5d:fc:4b:b4:c5:fc:eb:52:b7:
a0:af:40:3c:f0:ef:e9:d8:3f:83:c1:6c:24:85:59:
2a:9b:85:88:91:ed:22:7c:88:37:b3:b3:64:df:e5:
d6:70:3d:4a:7a:48:6b:85:b2:89:36:53:29:b4:5f:
5e:45
Exponent: 65537 (0x10001)
Attributes:
Requested Extensions:
X509v3 Subject Key Identifier:
E7:E7:89:E8:A1:96:A6:84:F5:0D:8C:D4:F0:44:A1:48:82:9E:6B:66
X509v3 Subject Alternative Name:
DNS:otms.demo, DNS:localhost, IP Address:127.0.0.1
Signature Algorithm: sha256WithRSAEncryption
76:d4:93:7c:6d:fb:4f:22:ca:24:5e:89:8e:06:4a:ce:62:fd:
ac:a1:f7:6a:2e:04:d3:fc:57:94:30:90:e8:47:86:9a:b4:d6:
b3:9a:af:f4:74:a4:62:3a:3b:17:f9:ab:e3:19:47:3f:cf:44:
ea:e0:aa:66:93:16:12:71:e7:ce:58:3a:a8:69:39:6a:97:cf:
c9:1d:94:77:5c:ad:60:f3:86:b1:49:68:f0:c9:96:37:3a:c7:
e4:a9:2f:49:49:c7:1e:00:29:07:4d:4c:b2:ae:d9:b7:74:e4:
d4:b6:d3:88:4e:1e:f7:72:56:80:cb:63:f0:bc:f3:45:b8:36:
c6:eb:e6:7e:34:7d:1a:1f:e5:c5:fe:93:52:5d:89:be:17:38:
c5:2e:da:88:89:ef:03:5e:c9:a5:b1:8f:aa:11:43:35:ec:ab:
f0:be:6a:c9:23:72:bc:d5:84:68:c0:6c:d9:0e:e1:0c:3c:98:
4f:9a:b2:0d:2d:e4:fc:7b:37:6e:23:26:2a:df:d7:9c:80:7c:
08:23:54:03:71:2e:7c:7e:4d:d3:e1:60:ef:14:d5:8d:28:37:
07:da:43:0f:85:51:6b:6c:24:b8:e5:18:9b:7a:2e:f7:cd:a0:
1a:91:96:5a:03:17:8e:42:6a:f1:68:a5:9e:21:92:98:35:f8:
ba:72:4d:48
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.