Internal SSL "certificate is not standards compliant" on macOS

pmifek · July 2, 2020, 4:48pm

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 127.0.0.1 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

NET::ERR_CERT_INVALID

Subject:

Issuer: Caddy Local Authority - ECC Intermediate

Expires on: 3 Jul 2020

Current date: 2 Jul 2020

PEM encoded chain:-----BEGIN CERTIFICATE-----
MIIBuzCCAWGgAwIBAgIRAMGDzv0suRkkU3eIWoDbePIwCgYIKoZIzj0EAwIwMzEx
MC8GA1UEAxMoQ2FkZHkgTG9jYWwgQXV0aG9yaXR5IC0gRUNDIEludGVybWVkaWF0
ZTAeFw0yMDA3MDIxNTM1MzZaFw0yMDA3MDMwMzM2MzZaMAAwWTATBgcqhkjOPQIB
BggqhkjOPQMBBwNCAATjupQHoH3xEwQC6PXxX1e0C4oYLfIATo5p3z5osc+9oB3d
p7SWcb0sKtgbqRyzC2mCzVBlKin5Ld9ur5ndhebdo4GIMIGFMA4GA1UdDwEB/wQE
AwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwHQYDVR0OBBYEFBW8
wMrBVJDulZUFtgbxS9xOUVohMB8GA1UdIwQYMBaAFBqZ8rK4lWcHiTn2Z4pu2riK
tto5MBQGA1UdEQQNMAuCCW1hYy5sb2NhbDAKBggqhkjOPQQDAgNIADBFAiEA4M0k
AYt3GuLjWSccvOkBZTex6TTbCAzRootmbVRDhxkCIDNUb0N8iWdbFSIutBu1Fl/M
RL2GKINJEjAPX1cYwJIl
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIByDCCAW6gAwIBAgIRAOyDkcQZDIVb1lv/kE0A1AUwCgYIKoZIzj0EAwIwMDEu
MCwGA1UEAxMlQ2FkZHkgTG9jYWwgQXV0aG9yaXR5IC0gMjAyMCBFQ0MgUm9vdDAe
Fw0yMDA3MDIxNTM2MzZaFw0yMDA3MDkxNTM2MzZaMDMxMTAvBgNVBAMTKENhZGR5
IExvY2FsIEF1dGhvcml0eSAtIEVDQyBJbnRlcm1lZGlhdGUwWTATBgcqhkjOPQIB
BggqhkjOPQMBBwNCAARdJos1Uq4KlWcZViTDNiAOpmLgWQcTbacYOQEaIYZPKxwh
+KeWj/m8n3Zn9BRvT3DNtICKpFoUpj/xwb76825Qo2YwZDAOBgNVHQ8BAf8EBAMC
AQYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUGpnysriVZweJOfZnim7a
uIq22jkwHwYDVR0jBBgwFoAUXF+yBOlGlhXratOfulsmlkGWsIIwCgYIKoZIzj0E
AwIDSAAwRQIgDZNui3GCY6cch8WmnCLaKYV5o7tlo0RO6mKCpo/NyYcCIQC/2CsF
dpRGddv7/Te4xVTCMDCMAFvqwd20dRkM60Z7NA==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIBozCCAUmgAwIBAgIQXAXuCY0O/Fc1gMxKinF94TAKBggqhkjOPQQDAjAwMS4w
LAYDVQQDEyVDYWRkeSBMb2NhbCBBdXRob3JpdHkgLSAyMDIwIEVDQyBSb290MB4X
DTIwMDcwMjE1MzYzNloXDTMwMDUxMTE1MzYzNlowMDEuMCwGA1UEAxMlQ2FkZHkg
TG9jYWwgQXV0aG9yaXR5IC0gMjAyMCBFQ0MgUm9vdDBZMBMGByqGSM49AgEGCCqG
SM49AwEHA0IABCL0no9kPHxEwfnkumytp5G/3FZDH8YEqbpg5SYvMIaZKHZilCH2
AEGBWDhx2xc0ZtZMjd1xka4qyv+qt5twEoujRTBDMA4GA1UdDwEB/wQEAwIBBjAS
BgNVHRMBAf8ECDAGAQH/AgEBMB0GA1UdDgQWBBRcX7IE6UaWFetq05+6WyaWQZaw
gjAKBggqhkjOPQQDAgNIADBFAiEA4DSYd5dWf1POgHJ6WDAmgASgz0TK9cvT8+7y
ZvH0zZcCIH39816+jy9BbKeyfkFwMjsh+An1OW0yg5Ph9XcHQbTR
-----END 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 172.17.0.1:55420: EOF

For Chrome it gives:

2020/07/02 16:11:30 http: TLS handshake error from 172.17.0.1:55610: 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

francislavoie · July 2, 2020, 4:55pm

That sounds similar to this

github.com/FiloSottile/mkcert

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

opened 04:12PM - 06 Jul 19 UTC

closed 09:30PM - 16 Aug 19 UTC

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'.

@matt will need to chime in.

matt · July 2, 2020, 5:34pm

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

Will look into it.

matt · July 2, 2020, 6:30pm

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

github.com

smallstep/cli/blob/fdb4c2bede8ce75c64526afb9b63c072c3f58932/crypto/x509util/leafProfile.go#L74

    
      
          	withOps = append(withOps, WithPublicKey(csr.PublicKey))
          	return newProfile(&Leaf{}, sub, iss, issPriv, withOps...)
          }
          
          
func defaultLeafTemplate(sub pkix.Name, iss pkix.Name) *x509.Certificate {
          	notBefore := time.Now()
          	return &x509.Certificate{
          		IsCA:      false,
          		NotBefore: notBefore,
          		NotAfter:  notBefore.Add(DefaultCertValidity),
          		KeyUsage:  x509.KeyUsageKeyEncipherment | x509.KeyUsageDigitalSignature,
          		ExtKeyUsage: []x509.ExtKeyUsage{
          			x509.ExtKeyUsageServerAuth,
          			x509.ExtKeyUsageClientAuth,
          		},
          		BasicConstraintsValid: false,
          		MaxPathLen:            0,
          		MaxPathLenZero:        false,
          		Issuer:                iss,
          		Subject:               sub,
          	}

We can get this fixed next week probably.

pmifek · July 2, 2020, 6:46pm

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!

pmifek · July 2, 2020, 6:49pm

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

maraino · July 2, 2020, 8:42pm

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.

maraino · July 2, 2020, 10:35pm

@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.

matt · July 2, 2020, 10:47pm

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

pmifek · July 3, 2020, 1:06pm

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 github.com/smallstep/cli 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!

WoofDog · July 7, 2020, 9:32am

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 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?

pmifek · July 9, 2020, 2:32pm

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…

francislavoie · July 9, 2020, 2:55pm

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.

lukas · July 18, 2020, 11:10am

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).

WoofDog · July 20, 2020, 6:56am

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.

joaquimrcarvalho · July 25, 2020, 4:51pm

Hello

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 192.168.0.16:59220: EOF

But it works on 10.13.6

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

Thanks again.

JC

lukas · July 25, 2020, 5:18pm

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.

system · August 1, 2020, 4:48pm

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