Approach to offer local root.crt for download by a browser to install trust

Our team is examining best approach to detect if a client HTTPS connection trusts the Caddy local root CA and if not, offer the CA certificate for download with some instructions for the various desktop OS’s to properly install it for “trust”.

The caddy root CA certificate is in /var/lib/caddy/.local/share/caddy/pki/authorities/local/root.crt by default. We are using the API to configure UNIQUE root CA certificate subject DN string values per caddy deployment (we do this via API after finalizing the unique details of each deployment with regard to IP/FQDN’s being configured).

Right now we’re evaluating if we can do this from our application that caddy frontend’s, but I wanted to put the question out to the community to see if anyone has been working over the Caddy as a root CA (either centralized caddy CA shared across caddy deployments) or isolated but potentially multiple instances of local CA’s like ours.

Well, since if the certificate isn’t trusted, the TLS handshake will never succeed, so there’s no way to return anything to display to the browser.

What you could do though is have users make an HTTP request (not HTTPS) to some endpoint which returns some JS, that JS could try to connect to the actual HTTPS endpoint. If it connects okay, then you can trigger a redirect, and otherwise display instructions.

Depends what you’re trying to do and who you’re deploying for, but that’s about the best I can suggest right now.

As far as possible approaches were looking at discussions like this: Check in JavaScript if an SSL Certificate is valid - Stack Overflow

Yeah its more along the lines of once the user accepts the security exception and connects, direct them to a tls trust setup page, which would get us past the initial tls connection warning stage…

Hey Todd, interesting question.

Off the top of my head I can’t think of a good way to do this purely from the server-side without any client support. You could maybe offer multiple certificate chains where one is trusted to begin with, and which uses a different signature algorithm (say, RSA) and the untrusted one uses, say, EC, and then check which cipher suite was negotiated to see if the client took the trusted or untrusted chain. But I don’t think that’s a sure indicator. And you’d need a trusted cert in the first place.

:warning: Please don’t make them do this. Asking users to bypass security warnings is the whole thing we’re trying to avoid by automating certificates. It weakens the efficacy of security warnings and conditions users to ignore them. It also puts them at risk for attack by installing nefarious certs. Since the security warnings are being bypassed, attackers could simply take advantage of that. It defeats the whole purpose of using certificates in the first place.

Thanks for that pointer Matt.

I’m experimenting with serving an inital setup page over HTTP but It seems like serving both HTTP and HTTPS path off the same config is not working. I’m wondering if aggressive chrome security is messing with this approach in that its forcing a connection to HTTPS instead, but firefox does the same thing. I’ll resubmit a “question” type of post to try and work through that approach. Thanks for the input. I’ll leave this open a bit in case anyone has some input/tips for ways they have addressed this.

1 Like

I recommend putting your HTTP page on a different port like 8080 or something, and ask users to connect there first for instructions, or something like that.

1 Like

That worked, thanks.

2 Likes

Ok I’ve got things working, at least in a rudimentary way, thanks for the tips!

2 Likes