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"
}
}
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:
@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.
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
You just have to do that manually (or with a custom script) every ~8 weeks.
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.
@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.
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.
@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.
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.