HTTPS client error "The certificate of X doesn't have a known issuer"

[eriknelson]

1. The problem I’m having:

I’m attempting to use Caddy as a fileserver and reverse proxy to serve files over https using (*.nsk.io) a PositiveSSL Wildcard Cert.

The fileserver and reverse proxy are both working when I attempt to load a file using firefox, but I get an error from curl and other clients stating that it’s not trusted and it doesn’t have a known issuer.

I’m not an expert when it comes to certs; my understanding is that many platforms have a library of trusted CAs, which I would expect my issuer to be a part of since it was purchased, with which the CA is verified against of my cert. So a couple questions:

• In addition to my .crt and .key files, I was provided a STAR_nsk_io.ca-bundle file. Does this last file need to be configured with Caddy in some way to ensure all clients trust my cert and use the ca-bundle to verify the authority automatically?
• Why would my browser work fine, but curl does not? Is there a set of trusted CAs that work with firefox but not curl/wget because firefox trusts the CA but my system does not?

2. Error messages and/or full log output:

# wget -O /tmp/ipxe.efi https://boot.nsk.io/ipxe.efi
--2023-07-21 14:32:55--  https://boot.nsk.io/ipxe.efi
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving boot.nsk.io (boot.nsk.io)... 192.168.2.3
Connecting to boot.nsk.io (boot.nsk.io)|192.168.2.3|:443... connected.
ERROR: The certificate of ‘boot.nsk.io’ is not trusted.
ERROR: The certificate of ‘boot.nsk.io’ doesn't have a known issuer.

3. Caddy version:

Docker caddy 2.6-alpine.

4. How I installed and ran Caddy:

Docker compose via systemd service.

c. Service/unit/compose file:

Systemd unit:

[Unit]
Description=Caddy docker-compose service
Requires=docker.service
After=docker.service
StartLimitIntervalSec=60

[Service]
WorkingDirectory=/srv/caddy
ExecStart=/usr/bin/docker compose up
ExecStop=/usr/bin/docker compose down
TimeoutStartSec=0
Restart=on-failure
StartLimitBurst=3

[Install]
WantedBy=multi-user.target

docker-compose.yml

---
version: "3.4"
services:
  caddy:
    container_name: caddy
    image: caddy:2.6-alpine
    ports:
      - 80:80
      - 443:443
    volumes:
      - /mnt/smb/vol/caddy/data:/data
      - /mnt/smb/private_static:/private_static
      - /srv/caddy/pki:/pki
      - /srv/caddy/Caddyfile:/etc/caddy/Caddyfile

d. My complete Caddy config:

Caddyfile

{
  admin :2019
  auto_https off
}

mux.nsk.io {
  tls /pki/nsk.io.crt /pki/nsk.io.key
  root * /private_static
  file_server browse
}

boot.nsk.io {
  tls /pki/nsk.io.crt /pki/nsk.io.key
  reverse_proxy "http://{$DOCKER_GATEWAY}:1337"
}

[matt (Matt Holt)]

Just curious, why purchase a cert? Why not use a free one?

@eriknelson

I’m not an expert when it comes to certs; my understanding is that many platforms have a library of trusted CAs, which I would expect my issuer to be a part of since it was purchased, with which the CA is verified against of my cert.

That’s basically correct, but purchased != trusted.

I would expect PositiveSSL (Comodo) to be in most trust stores, but if you’re using containers, all bets are off since it depends how your container is built. Try without a container.

Another possibility is that the client couldn’t verify the trust chain (i.e. missing intermediate). The error message isn’t very helpful unfortunately.

@eriknelson

In addition to my .crt and .key files, I was provided a STAR_nsk_io.ca-bundle file. Does this last file need to be configured with Caddy in some way to ensure all clients trust my cert and use the ca-bundle to verify the authority automatically?

I don’t know, you’ll have to consult the CA’s documentation for that one. If the bundle contains both the private and public keys, that’s only useful with Caddy if you’re loading a folder full of them.

@eriknelson

Why would my browser work fine, but curl does not? Is there a set of trusted CAs that work with firefox but not curl/wget because firefox trusts the CA but my system does not?

They use different root stores and have different verification logic.

---

I feel like you’re missing out on Caddy’s best feature though: free, automatic HTTPS. The whole point is to avoid this complexity

[eriknelson]

@matt

I feel like you’re missing out on Caddy’s best feature though: free, automatic HTTPS. The whole point is to avoid this complexity

I know. It’s a 5 year cert I’ve got and would like to use. I’m a fan of how simple the Caddyfile is and in the future would like to utilize the auto certificates, so I’d like to get comfortable with Caddy now.

@matt

I would expect PositiveSSL (Comodo) to be in most trust stores, but if you’re using containers, all bets are off since it depends how your container is built.

Likewise would have expected it to be present. The verification of the CA occurs client-side, correct? So are you referring to using a container on the client-side?

I’m actually encountering the problem setting up a UEFI HTTP Boot, which I think begs the question – how is the trust store configured for this scenario? I ultimately will probably just use http on my home network to sidestep this, but it will remain an issue for any other subdomains for the wildcard.

@matt

the client couldn’t verify the trust chain (i.e. missing intermediate).

I suspect this is the problem, but I don’t know how to verify.

EDIT:

I recognize this is veering quickly offtopic and probably outside the scope of Caddy. I think the main question I want to verify is: this is not a problem with my Caddy configuration, and is really a clientside issue with the trust store.

My cert is issued by Sectigo Limited:

# openssl x509 -in ./nsk.io.crt -noout -issuer
issuer=C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA

I’m using Arch LInux as my workstation, according to the docs, Arch uses CA certs from the Mozilla CA Certificate Store as a default set. Sectigo is in the Participating CAs according to the Mozilla link, so I’d expect it to be present.

I see a couple authorities when inspecting the cert in firefox:

Listing the CAs has no results for Sectigo, but it does have USERTrust RSA Certification Authority:

(.venv) {> baldur:pki/nsk.io/2023 <}
# trust list | grep -i sectigo
(.venv) {> baldur:pki/nsk.io/2023 <}
# trust list | grep -i usertrust
    label: USERTrust ECC Certification Authority
    label: USERTrust RSA Certification Authority

I have a vague understanding that it’s essentially a chain of digital signatures, so is it correct that USERTrust signed Sectigo’s cert, and in turn Sectigo signed mine?

Is it expected that an intermediary CA’s cert would be validated by my local machine if I trust its parent, or is there something wrong here?

[francislavoie]

@eriknelson

I know. It’s a 5 year cert I’ve got and would like to use.

But why? What advantage do you think you’re getting by continuing to use your old cert?

@eriknelson

• In addition to my .crt and .key files, I was provided a STAR_nsk_io.ca-bundle file.

Typically the .crt file you provide to Caddy has the full chain in it. It would typically be multiple -----BEGIN CERTIFICATE----- sections one after the other, concatenated together. The first one is your leaf cert, then the rest of the chain follows in order (so the intermediate next, and the root last).

If you only provided the leaf cert, then the clients would need to have the matching intermediate cert in their trust store for it to work; if they only have the root cert, then it wouldn’t work because the full chain can’t be resolved by the client verifying it.

You might need to assemble the concatenated .crt file yourself using those two files the CA provided you.

But anyway, why? Just let Caddy be smart and automatically issue certs for you. It’ll be more robust and future-proof, you won’t need to redo these steps when the cert expires etc.

[matt (Matt Holt)]

@francislavoie

But why? What advantage do you think you’re getting by continuing to use your old cert?

It sounds like he wants to “ease in” to Caddy, and get the most value from his paid cert, I guess.

What happens when you run your site through SSL Server Test (Powered by Qualys SSL Labs) ?

That’s the best resource I can suggest for starters

[eriknelson]

@francislavoie

Typically the .crt file you provide to Caddy has the full chain in it. It would typically be multiple -----BEGIN CERTIFICATE----- sections one after the other, concatenated together. The first one is your leaf cert, then the rest of the chain follows in order (so the intermediate next, and the root last).

If you only provided the leaf cert, then the clients would need to have the matching intermediate cert in their trust store for it to work; if they only have the root cert, then it wouldn’t work because the full chain can’t be resolved by the client verifying it.

Issue still seems to persist actually after concatenating the certs in order.