caddy: Certificate is invalid on Chrome

If I start a reverse proxy like this

sudo caddy reverse-proxy --to 127.0.0.1:1234

where under :1234 there’s a server running, it works perfectly on Firefox when I visit https://localhost. If I visit the same on chromium-based browsers (Chrome, Brave) I get an NET::ERR_CERT_INVALID error.

On the command line I get this error: http: TLS handshake error from [::1]:43216: remote error: tls: unknown certificate

Caddy version is v2.1.0 h1:MC4d65RCVaEKy1iOFjsD51mybOwS8qdEVBi7ESDhUfE=

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 1
Comments: 24 (10 by maintainers)

Most upvoted comments

I can confirm that the current master fixed the issue for me. Thank you.

mikaelhg on Jul 6, 2020

While I don’t know if it’s any different with the fix, I also agree it’s not great for Firefox or Chrome UI detail cert view, as the leaf cert is literally an invisible/blank field(in Firefox it’s indicated via tabs, in Chrome it’s a tree view of the cert chain). CommonName might not be required but at least provides a better UX for humans inspecting the certificate chain via browsers UI.

Thank you for putting this in a better argument that i could , just because something is not required per say , doesn’t mean it has no value. 😃

aduzsardi on Sep 25, 2020

Is this supposed to be fixed in v2.2.0-rc.3? I just tried this version, and I still experience the same issue in Chromium (NET::ERR_CERT_INVALID).

thomaskonrad on Sep 24, 2020

We don’t publish beta and RC versions to Docker.

You can build the latest from source though, with xcaddy and the golang image as a base.

francislavoie on Sep 10, 2020

@mholt I just updated to latest Docker tag from 6 hours ago. This is still 2.1.1, so perhaps not?

caddy version
v2.1.1 h1:X9k1+ehZPYYrSqBvf/ocUgdLSRIuiNiMo7CvyGUQKeA=

I have imported the root.crt and intermediate.crt into my local OS trust store (where they’ve been converted to caddy PEM files), as well as used Chrome settings UI for security to import the authority (not sure if intermediate import was required but did that as well).

Still fails to be recognized as secure. Firefox accepts it. Providing leaf cert I generate from mkcert for Caddy to use is fine in Chrome.

While I don’t know if it’s any different with the fix, I also agree it’s not great for Firefox or Chrome UI detail cert view, as the leaf cert is literally an invisible/blank field(in Firefox it’s indicated via tabs, in Chrome it’s a tree view of the cert chain). CommonName might not be required but at least provides a better UX for humans inspecting the certificate chain via browsers UI.

polarathene on Sep 10, 2020

Indeed, when I made a small change to InternalIssuer.Issue

csr.Subject.CommonName = "hardcoded.name"

and

rm -rf ~/.local/share/caddy

suddenly the issue went away, and Chrome accepted the certificate, no problem.

I would love to create a PR of this, but I’m completely ignorant of the Go language, and can’t really figure out where I’d get the name for the CSR. I could give it a shot, if you point me in the right direction.

mikaelhg on Jul 5, 2020