Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Self-signed certificates under MacOS Catalina cause error: revoked or invalid #1117
Self-signed certificates under MacOS Catalina cause error: revoked or invalid
Since upgrading to MacOS Catalina the self-signed certificates in my local trellis environments aren’t being trusted, and the error screens are not possible to bypass
I believe this is to do with the following issue: https://support.apple.com/en-us/HT210176
On Chromium (Opera) I saw the following error: NET::ERR_CERT_REVOKED.
I manually modified the expiry time down from 3650 days to 825 to conform, and this changed the error message but did not fix the situation (see below).
WORKAROUND: Saving the certificate to disk and importing to the keychain, then marking it as always trusted, and restarting the browser will allow you to bypass the error screen.
Steps to reproduce
Certificate warning, bypassable - or no certificate warning
Certificate warning, non-bypassable
Reproduces how often: [What percentage of the time does it reproduce?]
100% (2 out of 2 times)
This happened to me on one existing site. I then reproduced this on a fresh install of trellis and bedrock. Two other people have come forward with this error (see discourse thread linked below). Upon searching I have seen the issue echoed across the internet.
The initial issue is with how MacOS now handles self-signed certificates: https://support.apple.com/en-us/HT210176
Changing certificate expiry from 3650 days to 825 should fix the issue, but reveals another one for me: NET::ERR_CERT_INVALID
On further enquiry this appears to be because the domain names in the Subject Alt Name section of the certificate have the string "DNS:" appended to the end. I do not know if this is part of the same issue, or a separate one.
This thread has some of my findings so far
Newer findings are attached to this thread.
I subsequently edited
If save this certificate in MacOS Keychain, marking all categories as "Always Trust", (I also removed the www subdomain from the trellis config, not sure if necessary), I get a new error:
This error explains that the Subject Alternative Name doesn't match the domain, because it has "DNS:" appended to the end of the domain name.
This error screen is possible to bypass after clicking through to the "more information" section.
HOWEVER it does allow me to proceed to the website:
So the first (and easier) fix to make in Trellis is just to reduce the expiry length? Would one of you like to make that change?
Ideally Trellis could handle the trusting automatically; maybe use an existing tool to make it easier. However, this also might be something that better belongs in trellis-cli (cc @TangRufus)
I did something simular last year https://github.com/TangRufus/insecurecert/blob/master/cert.go but I forgot what made me stop.
I suggest we go for a non-Trellis-specific tool (which download insecure cert from website and add to OS trust list) and make trellis-cli depends on it.
I also have been using ianjamieson's suggestion,
I'm new to PRs but I could try to do one for reducing the expiry time.
Are any of you getting the secondary issue, with the string "DNS:" being appended to the end of the host names in the Subject Alt section? (I can't see anything wrong in the trellis code, so am quite confused about how/where this is happening).
The issue with the string "DNS:" appended to the end was most likely caused by a previous version of trellis.
I had to delete the existing certificates and let them be regenerated, and the newer trellis code output some working certificates. Result!
# log in to your virtual machine vagrant ssh # (or `trellis ssh development`)
...and now in the VM shell:
# set a root password sudo passwd root # change to the root user su - # enter the same password again... # remove old keys and certs rm /etc/nginx/ssl/*.key /etc/nginx/ssl/*.cert exit exit
...back in your native shell:
# re-provision SKIP_GALAXY=true ANSIBLE_TAGS=wordpress vagrant provision # or if you use trellis-cli: # SKIP_GALAXY=true ANSIBLE_TAGS=wordpress trellis exec vagrant provision # or when trellis-cli supports the provision command (doesn't work yet): # SKIP_GALAXY=true trellis provision --tags wordpress development
Don't forget to remove any previously "trusted" certificates from the keychain, then restart your browser. Finally, trust the certificate—either with the keychain method, or by using the trellis-cert plugin as follows:
# optional vagrant trellis-cert trust # if you use trellis-cli: # trellis exec vagrant trellis-cert trust
Since everyone here knows the background, can you guys give it a test?
Build from https://github.com/TangRufus/insecurecert/tree/cli-v2 with goland v1.13.4
$ git clone https://github.com/TangRufus/insecurecert.git $ cd insecurecert $ git checkout cli-v2 $ go build
It should generates a
$ sudo /path/to/insecurecert trust --hostname self-signed.badssl.com $ sudo /path/to/insecurecert trust --hostname untrusted-root.badssl.com --result-type trustAsRoot
For Trellis vagrant sites:
Note: Only support macOS. Firefox is not supported. Tested on Chrome & Safari, should work on broswers that uses macOS keychain.
What's the benefit of using that over the Vagrant plugin? If anything I'd rather build something into trellis-cli.
https://github.com/FiloSottile/mkcert would be great since it has better OS support but unfortunately it can't simply trust an existing cert not made by it.