Self-Signed certificate not valid on MacOS Catalina

Hi there,

Since Catalina the self-signed certificates in my local trellis environments aren’t being trusted. I believe this is to do with the following issue:

On Chromium (Opera) I saw the following error: NET::ERR_CERT_REVOKED.

I manually modified the expiry time down from 3650 days to 825, but this didn’t help (although I could see the expiry date change reflected in the certificate after destroying and reprovisioning the vm). After doing this the error changed to NET::ERR_CERT_INVALID.

I have tried saving the certificate and importing to the keychain, marking it as always trusted… but no cigar.

I don’t really know what I’m doing with the internals of Trellis. Is this something somebody else can reproduce? I don’t know what to do. Can’t load my local sites, can’t do any development. Any workarounds would be much appreciated.

Other people having this issue:

Somebody has tried to work around it here:
I tried to follow the advice, creating my own CA and wildcard certificate, but it doesn’t seem to ever get used.

I’m running into the same issue. It took a while to solve the Catalina/Vagrant path problem and now that Vagrant can mount and provision correctly I am hit with this new NET::ERR_CERT_REVOKED error.
I hope someone managed to resolve this.

I actually used this method to trust the certificate it is now working for me.


Glad to know it works for you!

I just realised that after reprovisioning, my certificate was somehow configured for and that’s why I was seeing NET::ERR_CERT_INVALID - I think this occurred because I tried turning off self-signed certificates in trellis and hadn’t refreshed.

So I reprovisioned vagrant again, removed the certificates I added from the keychain, and is gone but I am getting a different error now. This one does allow me to bypass it and get to the site (phew), but still I’d like to solve it.

The error is NET::ERR_CERT_COMMON_NAME_INVALID and it’s because the DNS name is “mydomain.testDNS:” instead of “mydomain.test” - somehow “DNS:” has been added to the end of it. Have I accidentally messed up Trellis somehow to cause this?

EDIT: I’ve updated the file trellis/roles/wordpress-setup/tasks/self-signed-certificate.yml to the latest version from the repo and re-provisioned but the error is the same as the original: NET::ERR_CERT_REVOKED

Using keychain to trust the certificate doesn’t seem to work for me on Chromium-based browsers. The only way I can view the site is on Safari, where I have to click through the error messages to let it show me the site. Chromium doesn’t allow this.

Has anyone also got this issue on a fresh install?

1 Like

@robrecord You are not alone! I am getting this issue with a fresh site install (not OS install).

For now I’ve just been running wp search-replace to revert existing sites back to http as I need to work on them. Obviously not really an ideal solution!

1 Like

Just to clarify the situation:

  • Under MAcOS Catalina, self-signed certificates from Trellis are causing NET::ERR_CERT_REVOKED

[no screenshot available]

  • Changing expiry from 3650 to 825 days, as per new MacOS recommendations, changes error to NET::ERR_CERT_COMMON_NAME_INVALID

  • Details of NET::ERR_CERT_COMMON_NAME_INVALID show that Subject Alt Names are malformed, with the string “DNS:” appended to the end of the domains:

  • I believe that removing the www subdomain changes the error to NET::ERR_CERT_INVALID - I have not tried to replicate this, but that’s what I did and that’s what I’m currently getting.

  • If I trust the certificate in Keychain, I still get an error but with more information:

I had the same issue when updating to Catalina 2 weeks ago. As you mentioned playing with the expiry time etc. did not help either. Cert was still refused by chromium based browsers (it worked in Safari, Firefox etc.)

What I did to quasi-solve the problem was to go to keychain and find that certificate and set to “always” trust for all kinds of communication.

I know that this is not a proper solution but for me was more than enough for local environment. That is obviously unacceptable for anything going beyond local.

1 Like

Thanks owi, I tried exactly that and it didn’t work for me so something in my project, or that I’m doing, must be different. I wish I knew what.

I’ve opened a bug report on github:

Are you sure you are having it like that?

Also please make sure that you restart the browser afterwards and clear the cache for that site

1 Like

I did mark it as always for all items, yes - but I did not restart the browser.

Now I’ve done that and I am able to bypass the warning with a few clicks. Thank you!

I am glad that it worked for you - though at the same time I am sad that we do not know what is the root cause of that :wink:

This topic was automatically closed after 42 days. New replies are no longer allowed.