How to change SSL generated by Caddy?

1. Caddy version (caddy version): v2.4.6 h1:HGkGICFGvyrodcqOOclHKfvJC0qTU7vny/7FhYp9hNw=

2. How I run Caddy: Direct from docker with Caddyfile

a. System environment:

Ubuntu / Docker

b. Command:

docker run -d \
   --name postal-caddy \
   --restart always \
   --network host \
   -v /opt/postal/config/Caddyfile:/etc/caddy/Caddyfile \
   -v /opt/postal/caddy-data:/data \
   caddy

c. Service/unit/compose file:

Paste full file contents here.
Make sure backticks stay on their own lines,
and the post looks nice in the preview pane.

d. My complete Caddyfile or JSON config:

# Update this to match the hostname you wish to use for accessing the
# Postal web interface.
post.uhlhosting.ch {
  reverse_proxy 127.0.0.1:5000
}

# If you use open/click tracking you may need to add additional hosts
# to this file using the format below.

click.uhlhosting.ch {
  reverse_proxy 127.0.0.1:5000 {
    header_up X-Postal-Track-Host "1"
  }
}

3. The problem I’m having: The application behind Caddy Postal.io supports SMTP SSL/TLS, yet since the same domain is involved for SMTP, there is a bug that does not allow usage of other TLS than RSA.

4. Error messages and/or full log output: There is no direct error log from Caddy, since that works well, the only issue is that I did not managed to find a way to change the SSL generate by Caddy to RSA on my current config file.

5. What I already tried: Adding the lines found on forum here:

"tls": {
          "automation": {
            "policies": [
              {
                "key_type": "rsa4096"
              }
            ]
          }
        },
# Update this to match the hostname you wish to use for accessing the
# Postal web interface.
post.uhlhosting.ch {
  reverse_proxy 127.0.0.1:5000
}

# If you use open/click tracking you may need to add additional hosts
# to this file using the format below.

click.uhlhosting.ch {
  reverse_proxy 127.0.0.1:5000 {
    header_up X-Postal-Track-Host "1"
  }
}

6. Links to relevant resources: Installation - Postal Documentation

Hi :slight_smile:

I don’t really understand why you need to change how Caddy issues tls certificates because of a mail server suite on the same domain.
Are you trying to reuse the same certificate issued by Caddy in postal?
Would be cool if you could elaborate a bit more on what you are trying to accomplish :))

Anyhow,
you should be able to change the tls key type both globally and on a per vhost basis:

For the former, you need to add the following into the global directive like so:

{
  key_type rsa4096
}

# Update this to match the hostname you wish to use for accessing the
# Postal web interface.
post.uhlhosting.ch {
  reverse_proxy 127.0.0.1:5000
}

# If you use open/click tracking you may need to add additional hosts
# to this file using the format below.

click.uhlhosting.ch {
  reverse_proxy 127.0.0.1:5000 {
    header_up X-Postal-Track-Host "1"
  }
}

You did reference the right thread in point 6., but tried to mix plain json with your Caddyfile, which is not possible.
A post later in the same thread mentioned the (then) new global Caddyfile option:

See Global options (Caddyfile) — Caddy Documentation for all the allowed values in key_type.

For forcing a special key_type on a single vhost, you could utilize the tls directive within that vhost.

2 Likes

@emilylange Hi,
Thanks for the reply, yes we want indeed to reuse in our config file for SMTP the SSL since it shares the same hostname. I know why could had been avoided by generating independent ssl for smtp, yet wanted to have it more robust if its possible.

I feel like this use-case isn’t too uncommon (all things considered). Especially because of how robust Caddy’s tls renewing is.

But as far as I am aware, this isn’t supported in an automated fashion yet.
You could track Feature Request: Allow entry point for post certificate provisioning hooks · Issue #3643 · caddyserver/caddy · GitHub if you want :slight_smile:

That means that even adding the config variable the certificates wont be provisioned, any ways to enforce this?

Oh sorry. The certificates will be provisioned and you will be able to fetch the certificates out of Caddy’s tls storage (Conventions — Caddy Documentation) and use it in your other service. In your case that would be your postal mail server :slight_smile:
You just have to do that manually (or with a custom script) every ~8 weeks.

1 Like

I checked now the SSL folders they still show old certificates, is there some CLI to use to enforce the change?

In that case, it should be enough to delete those certificates from the folder and either restart or reload Caddy :slight_smile:

Isnt there a CLI on top of caddy or wapper that can reissue the SSLs with the valid encryption?

I’m not sure what you mean by “valid” encryption. Caddy will never generate “invalid” private keys.

But no, if you need to change the type of keys, you’ll need to delete them from storage, change your config to specify the key type you need, then reload Caddy. There’s no CLI commands for this right now.

2 Likes

@francislavoie I maybe wrote it wrongly, we just moved from EDHCS certs to RSA, since our mail server does not support only RSA.
We added to our caddyfile, and we expected to get new SSLs generated with the new key type, that did not happened yet. And it seems its not generating new SSLs in place yet.

key_type rsa4096

then reload Caddy.
I have turned down docker for caddy and back on, this did not helped, any other ideas?

Like I said, delete the existing certs and keys in Caddy’s storage, THEN reload Caddy.

Caddy doesn’t look at the configured key type and compare against what’s in storage. It’ll just use what’s in storage first, because it’s still valid/not-expired.

Changing the key type only affects the generation of new keys, and Caddy has no reason to regenerate keys unless it has to make one for a new domain you’ve added to your config which didn’t already have one.

1 Like

We removed the SSL we had, maybe need to check Docker image for stored ssls.

If you’re running Caddy in Docker, then the certs/keys will be in the /data volume. Looks like you’re making a -v mount to /opt/postal/caddy-data. So wipe out the contents of that directory.

1 Like

Thanks, that helped!

1 Like

@francislavoie that worked until running some tests, we then realized we have broken Chain, and since we use our SSL also in SMTP server, we go some issues where we had to disable OPENSSL verification.

Any idea how to fix the broken chain?
https://www.ssllabs.com/ssltest/analyze.html?d=post.uhlhosting.ch
We tried:

root@btc:~/btcpayserver-docker# echo|openssl s_client -connect post.uhlhosting.ch:25 -starttls smtp|head -n 7
depth=0 CN = post.uhlhosting.ch
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = post.uhlhosting.ch
verify error:num=21:unable to verify the first certificate
verify return:1
250 AUTH CRAM-MD5 PLAIN LOGIN
DONE
CONNECTED(00000003)
---
Certificate chain
0 s:CN = post.uhlhosting.ch
i:C = US, O = Let's Encrypt, CN = R3
---
Server certificate

It seems indeed the certificates were generated as RSA as we need them, yet now the Chain for some reason contains expired X3 Root authority from let’s encrypt.

It’s because ISRG Root X1 was cross-signed. Shouldn’t be a problem.

I think your machine that is complaining about trust needs an update to its certificate store. The expired DST Root (IdenTrust’s root cert) is probably removed if you update.

@francislavoie I tried to update, if updating ca-certificates helps. Or is there other procedure to do so?

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