"Certificate not standards compliant" on macOS Catalina, iOS 13

[selfagency]

Certificates generated after July 1st, 2019 by versions of mkcert prior to v1.4.0 will not work on macOS 10.15 Catalina and iOS 13. Please update mkcert and regenerate the affected certificates.

The root CA is unaffected and there is no need to rerun mkcert -install.

— @FiloSottile

---

Under MacOS Catalina Public Beta 2, after installing mkcert via Homebrew and running the root certificate installer, my mkcert generated certificates are rejected in Safari with the message 'Certificate is not standards compliant' and in Chrome with 'ERR_CERT_REVOKED'.

[FiloSottile]

Looks like it's a new limit on maximum lifespan. See https://support.apple.com/en-us/HT210176.

Additionally, all TLS server certificates issued after July 1, 2019 (as indicated in the NotBefore field of the certificate) must follow these guidelines:

TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).

It's surprising they would enforce it on private roots, honestly.

I am mildly tempted to fake the notBefore, but one way or another I need to fix it soon, or a bunch of certificates will be generated that will stop working after updating to Catalina.

BTW, if you try Chrome Canary it should give you a better error message.

[FiloSottile]

I opted to backdate the notBefore until the ACME server is implemented. Once ACME is an option, automation should reduce the need for long lifespans.

@selfagency Please test the latest master (brew install mkcert --HEAD), and let me know. If it works, I'll push a new version ASAP so we can minimize the number of doomed certificates that will get issued.

[jarretmoses]

I've recently had this issue as well. Tried the HEAD install but still get rejected certs. (Just so you know @FiloSottile)

[ganapativs]

I'm having a same issue with Chrome on MacOS Catalina public beta 2! Interestingly certificate works on Firefox developer edition 🤷‍♂️

Tried running brew install mkcert --HEAD, but no luck!

➜ brew install mkcert --HEAD --debug
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/mkcert.rb
Error: can't modify frozen String
/usr/local/Homebrew/Library/Homebrew/exceptions.rb:475:in `initialize'
/usr/local/Homebrew/Library/Homebrew/formula_installer.rb:86:in `new'
/usr/local/Homebrew/Library/Homebrew/formula_installer.rb:86:in `prevent_build_flags'
/usr/local/Homebrew/Library/Homebrew/cmd/install.rb:134:in `install'
/usr/local/Homebrew/Library/Homebrew/brew.rb:102:in `<main>'

➜ brew --version
Homebrew 2.1.7
Homebrew/homebrew-core (git revision 276f; last commit 2019-07-10)

Why Apple is limiting certs validity to 825(Magic number?) days though? 🤔

[selfagency]

Same deal, unfortunately, with the head version.

NET::ERR_CERT_REVOKED
Subject: mkcert development certificate

Issuer: mkcert [email protected]

Expires on: Jul 6, 2029

Current date: Jul 11, 2019

[adamdecaf]

825 comes from the CAB forum bylaws for certificates. All of the major products and CA's follow them.

• https://www.sslshopper.com/cab-forum-reduces-max-cert-validity-to-825-days.html
• https://cabforum.org/2017/03/17/ballot-193-825-day-certificate-lifetimes/

[ganapativs]

I'm having a same issue with Chrome on MacOS Catalina public beta 2! Interestingly certificate works on Firefox developer edition 🤷‍♂️

Tried running brew install mkcert --HEAD, but no luck!

➜ brew install mkcert --HEAD --debug
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/mkcert.rb
Error: can't modify frozen String
/usr/local/Homebrew/Library/Homebrew/exceptions.rb:475:in `initialize'
/usr/local/Homebrew/Library/Homebrew/formula_installer.rb:86:in `new'
/usr/local/Homebrew/Library/Homebrew/formula_installer.rb:86:in `prevent_build_flags'
/usr/local/Homebrew/Library/Homebrew/cmd/install.rb:134:in `install'
/usr/local/Homebrew/Library/Homebrew/brew.rb:102:in `<main>'

➜ brew --version
Homebrew 2.1.7
Homebrew/homebrew-core (git revision 276f; last commit 2019-07-10)

Why Apple is limiting certs validity to 825(Magic number?) days though? 🤔

Manually compiling from current master using go on MacOS Catalina public beta 2 works on chrome 🎉

brew install go
go get -u github.com/FiloSottile/mkcert
$(go env GOPATH)/bin/mkcert -install
$(go env GOPATH)/bin/mkcert localhost

[RgtArRr]

I'm having a same issue with Chrome on MacOS Catalina public beta 2! Interestingly certificate works on Firefox developer edition 🤷‍♂️
Tried running brew install mkcert --HEAD, but no luck!

➜ brew install mkcert --HEAD --debug
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/mkcert.rb
Error: can't modify frozen String
/usr/local/Homebrew/Library/Homebrew/exceptions.rb:475:in `initialize'
/usr/local/Homebrew/Library/Homebrew/formula_installer.rb:86:in `new'
/usr/local/Homebrew/Library/Homebrew/formula_installer.rb:86:in `prevent_build_flags'
/usr/local/Homebrew/Library/Homebrew/cmd/install.rb:134:in `install'
/usr/local/Homebrew/Library/Homebrew/brew.rb:102:in `<main>'

➜ brew --version
Homebrew 2.1.7
Homebrew/homebrew-core (git revision 276f; last commit 2019-07-10)

Why Apple is limiting certs validity to 825(Magic number?) days though? 🤔

Manually compiling from current master using go on MacOS Catalina public beta 2 works on chrome 🎉

brew install go
go get -u github.com/FiloSottile/mkcert
$(go env GOPATH)/bin/mkcert -install
$(go env GOPATH)/bin/mkcert localhost

That works for me on macOS Catalina too.

[rfay]

Feeling anxious to get this into a release. I'll think about how I can test, maybe Parallels macOS upgraded to Catalina.

[selfagency]

If you use APFS, you can install it into its own container. https://www.macworld.com/article/3405588/how-to-install-the-macos-catalina-beta-in-its-own-apfs-container.html

…

On Jul 31, 2019, 3:27 PM -0400, Randy Fay ***@***.***>, wrote: Feeling anxious to get this into a release. I'll think about how I can test, maybe Parallels macOS upgraded to Catalina. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[rfay]

Sadly, I'm unable to verify that latest works on Catalina. I've tried a number of things and have failed at every step.

I built mkcert with go install and then have done everything I could think of to make sure no existing remnants still exist:

• Check out 2d05f3b and build with go install
• brew unlink mkcert && cp ~/go/bin/mkcert /usr/local/bin`
• mkcert -uninstall
• rm -rf $(mkcert -CAROOT)
• Restart chrome
• Explicitly delete old certs that were in Chrome (there were 4 of them)

No matter what I do I end up with a cert that has a 2029 expiration date and is thus "revoked".

I assume there's some cleanup step I've missed. I certainly see the important commit df15e0c there.

Suggestions on what I could do differently to verify this?

[rfay]

I confirm this situation with a better test.

• Building mkcert master latest commit 2d05f3b on Catalina (although it doesn't matter where it's built). Clean machine, no other mkcert has ever been installed there.
• mkcert junker99
• openssl x509 -in junker99.pem -text -noout and note the expiration date is still 2029.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            cb:62:fc:d8:82:6a:18:dd:5f:b8:d3:12:1f:48:5d:5b
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=mkcert development CA, [email protected], CN=mkcert [email protected]
        Validity
            Not Before: Jun  1 00:00:00 2019 GMT
            Not After : Aug 14 01:25:38 2029 GMT
        Subject: O=mkcert development certificate, [email protected]

I will try to do some debugging to see why the code that looks so good is not getting us to a shorter expiration.

[FiloSottile]

The code wasn't trying to make a shorter expiration, but to backdate the Not Before so the certificate would be exempt. I finally have time and space to install Catalina and will get to testing today or tomorrow.

[rfay]

And... I spent a lot more time with it tonight, and tried the shorter expiration because of the conversation here. But I discovered I had a lot more complex environment than I was remembering. (A linux mkcert in a container was using the root CA created on macOS, which the macOS browser had to trust... but I was still using the old linux mkcert)

Now I can confirm that the code in 2d05f3b does work. I didn't understand at all given the conversation here how we could still be making 10 years work.

I'd rather do the more obvious code in https://github.com/rfay/mkcert/blob/7642e8ce4edbd274ee79b788423c05e3765a4cc8/cert.go#L67-L75, as it directly addresses the issue here. I'll make a PR of that if you like it. But I think my earlier testing was flawed due to the complexity of my own environment and the disconcerting fact we are still using a 10 year expiration, which I thought was the issue.

[rfay]

I went ahead and made the PR. We'll see if it's useful. I think it's a more direct approach to this problem. #187

Thanks for all your work on this! It means so much to so many of us.

[FiloSottile]

Had to kick macOS to get it to download Catalina, but I managed to test this.

The fix works correctly. Here's a before and after.

I'll make a release tomorrow.

(What didn't work is brew install mkcert --HEAD because Homebrew regrettably removed that very useful feature from its core packages. I will maintain a formula in this repo for these cases.)

[FiloSottile]

Fixed in v1.4.0. https://github.com/FiloSottile/mkcert/releases/tag/v1.4.0

[back-2-95]

How can I install v1.4.0 before it comes through Brew? Is there some magic command or do I need to take the build from source road?

[FiloSottile]

You can get binaries from the release page. https://github.com/FiloSottile/mkcert/releases/tag/v1.4.0

[AlekSi]

Homebrew has 1.4.0 now.

[oberlon]

Looks like it's a new limit on maximum lifespan. See https://support.apple.com/en-us/HT210176.
[...]TLS server certificates must have a validity period of "[max]" 825 days [...]

Thx Filo. After spending hours to figure out why my self signed cert is not acceptable only on chrome I read your post. Get a new cert with only 2 years and everything works.

Edit: Before my Cert was valid for 3 years and Chrome always showed "NET::ERR_CERT_REVOKED"

[lgarron]

I'm still having issues with this. :-(

If I regenerate certs from scratch, both the root and the leaf have a notBefore of today, and I'm getting NET::ERR_CERT_REVOKED in Chrome.

This is with:
mkcert 1.4.0
Chrome 77.0.3865.120
macOS 10.15.0

[lgarron]

I'm still having issues with this. :-(

If I regenerate certs from scratch, both the root and the leaf have a notBefore of today, and I'm getting NET::ERR_CERT_REVOKED in Chrome.

This is with:
mkcert 1.4.0
Chrome 77.0.3865.120
macOS 10.15.0

Reinstalling a few times using Homebrew didn't work. I ended up compiling from scratch. Is it possible the binary 1.4.0 Homebrew distribution has the old version of the code?

[FiloSottile]

AFAIK the Homebrew distribution is the right version. Maybe you had an old version built from source higher in your $PATH?

If you can reproduce this from scratch please open a new issue so we don't lose track of it.

[arimolzer]

I'm still getting this issue, but it still seems to be an issue for me on the latest version. I have built from the source, but my certs still generate with a expiry date of 12 May 2030.

macOS: 10.15.4
mkcert: v1.4.1-dev

[flyinprogrammer]

@arimolzer I believe the screenshot here is of the Root Certificate Authority, and not the end-entity/leaf certificates, where this issue becomes an issue.

I.e. if you run:

mkcert localhost 127.0.0.1 
openssl x509 -in localhost+1-key.pem -noout -startdate
# -startdate is a libressl (macOS) flag

You should see that this end-entity/leaf certificate, which you would use in your application, are properly back dated.

So far I haven't seen an issue with having Root Certificate Authorities create certificates with start dates before its own creation date; however, I'm sure it's only a matter of time before Apple's security theater becomes more problematic.