Internal SSL "certificate is not standards compliant" on macOS

1. Caddy version (caddy version):

v2.1.1 h1:X9k1+ehZPYYrSqBvf/ocUgdLSRIuiNiMo7CvyGUQKeA=

2. How I run Caddy:

docker run -d -p 80:80 -p 443:443 caddy caddy file-server --domain mac.local

a. System environment:

server: Docker version 19.03.8, build afacb8b
clients: macOS10.15.5, Safari 13.1.1, Chrome 83.0.4103.116
alternate clients: macOS 10.14.5 Safari 13.1.1, Chrome 83
works on (clients): macOS10.15.5, Firefox 78.0.1

b. Command:

#prep a "domain"
sudo bash -c "echo mac.local >> /etc/hosts"
#run caddy (fresh docker image)
docker pull caddy
docker run -d -p 80:80 -p 443:443 caddy caddy file-server --domain mac.local
#get caddy's root.crt
docker exec $(docker ps |grep caddy|awk '{ print $1; }') cat /data/caddy/pki/authorities/local/root.crt >./caddy-docker.crt
#install root crt
open ./caddy-docker.crt
#install to system keychain, set trust (ssl, x.509)

3. The problem I’m having:

Trying to use Caddy 2.1 to serve https on internal domains to (mostly) mac clients. All is working except for Safari and Chrome (both using Keychain) on macOS. No matter what I do so far they are giving errors and not connecting. AFAICT the certs are complying with [1], but they both give the “certificate invalid” message with an additional info “certificate is not standards compliant” (please see below). Firefox on the same machines works (it also uses the separate cert store and handling).

4. Error messages and/or full log output:

Chrome’s certificate details:

Chrome’s message:

Your connection is not private

Attackers might be trying to steal your information from mac.local (for example, passwords, messages or credit cards). Learn more



Issuer: Caddy Local Authority - ECC Intermediate

Expires on: 3 Jul 2020

Current date: 2 Jul 2020

PEM encoded chain:-----BEGIN CERTIFICATE-----

Help improve Chrome security by sending URLs of some pages that you visit, limited system information and some page content to Google. Privacy Policy

ReloadHide advanced

mac.local normally uses encryption to protect your information. When Google Chrome tried to connect to mac.local this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be mac.local, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Google Chrome stopped the connection before any data was exchanged.

You cannot visit mac.local at the moment because the website sent scrambled credentials that Google Chrome cannot process. Network errors and attacks are usually temporary, so this page will probably work later.

caddy’s output (when reloading that page)

For Safari it gives:

2020/07/02 15:52:05 http: TLS handshake error from EOF

For Chrome it gives:

2020/07/02 16:11:30 http: TLS handshake error from remote error: tls: unknown certificate

5. What I already tried:

Tried caddy 2.0, tried macOS14 and 15. Multiple machines. Multiple domains with more or less specific Caddy configurations. Multiple ways of “delegating” those domains. Tried Caddy in Docker, bare Debian, and macOS. Longer cert expiry. And yes, rebooted…

I seem to be running out of the obvious options to try (less of reimplementing/using external certs) and if anyone was able to give me a hint of what I might’ve been doing wrong I’d be deeply obliged! Thanks!

6. Links to relevant resources:

[1] Requirements for trusted certificates in iOS 13 and macOS 10.15 - Apple Support

1 Like

That sounds similar to this

@matt will need to chime in.

Hm, I’m seeing this too. (I don’t use Chrome, so, this is news to me.)

Will look into it.

The Smallstep team (which is awesome, as usual) has found the bug in this file:

We can get this fixed next week probably.

Ah, yep, that was like the only google match I’ve got, though as I understand it, they had issue only on macOS 10.15 and due to long expiration (with a slightly different Chrome error message. I tested “rolling” clock a few days back and there was no change. Thanks for looking though!

That would be terrific, thanks Matt! Hats off to you and the Smallstep team! Feel free to ask for any testing if needed.

I’m not able to reproduce the error on Chrome 83.0.4103.116, macOS, but after reading the RFCs I’ve created a PR to fix this issue and only provide key encipherment for RSA keys.

1 Like

@matt step certificates v0.14.6 has been released with the key encipherment fix. Only if you sign a CSR with an RSA key you will get the Key Encipherment key usage in it.


Excellent! That was fast :smiley: You and your team are great. I will check it after the holiday.

Great work @maraino @matt @francislavoie! I just made a quick test with the master branch, just swapping certificates v0.15.0-rc.1.0.20200506212953-e855707dc274 and v0.14.4 for their respective v0.14.6 versions and the certificates now do work great! (haven’t run other tests though and that v0.15.0-rc to v0.14.6 switch is a bit large (quite a few changes between the versions) so I hope there won’t be an issue integrating this into a release some time soon!

Thanks again everybody!

1 Like

I think 'm getting the same sort of certificate error on Chrome and Safari on Mac 10.15.5 (19F101) which is making testing website a bit tricky :wink: Firefox says certificate issuer not recognised - but seems to work.

Is there any news about when this fix will be pushed to homebrew - currently 2.1.1?

The fix that works (for me) is in master branch already go.mod: Upgrade and downgrade smallstep, quic-go, and cpuid · caddyserver/caddy@2a5599e · GitHub, so I guess whenever a new release gets pushed out…

1 Like

We don’t maintain the homebrew releases, so we can’t say. It’ll probably be released as part of v2.2 which might be in a few weeks, but there’s no release date set. We usually just cut a release when we feel there’s enough changes to warrant one.

The Homebrew formula is updated whenever there is a new Caddy release on GitHub. However, you can already install the development version on the master branch with the following commands:

brew uninstall caddy
brew install --HEAD caddy

Please note that this will compile Caddy from source, which will take a bit longer than the release installation (which uses a Homebrew Bottle by default).

1 Like

Thanks lukas, I changed to the HEAD version and then ran
caddy untrust and then caddy trust and rebooted. That seemed to do the trick and local certificate are now working on macOS.


I am having the issue reported here, problems on local access.

I did the brew install --HEAD caddy

Now running version
v2.1.2-0.20200720231738-2bc30bb780f3 h1:Bl/1M0VZEoh8jKz22WePMXvECV52ptNO+vR32QOuZss=

is this the one I should have?

Safari still fails to accept the certicate on MacOs 10.15.6
In the log:

2020/07/25 17:46:28 http: TLS handshake error from [fe80::10e3:c219:2759:51ce%en1]:61220: EOF

Also fails in iPadOS
2020/07/25 17:49:11 http: TLS handshake error from EOF

But it works on 10.13.6

Other that the install from source above should I have done anything else?

Thanks again.


You could try deleting the cached certificates from ~/Library/Application Support/Caddy/certificates/local and restarting Caddy. This will make sure that new valid certificates are generated.

If this doesn’t fix it, you are running into an unrelated issue.

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