Caddy certificates issues

[MarcS1975]

The caddy certificate integration works well and DMS starts without any problems, but the certificates do not allow proper mail exchange. When testing the certificates I get the following errors:
(The same DMS config with letsencrypt certificates works fine.)

<!--StartFragment-->
Connection converted to SSL
--
  |   | SSLVersion in use: TLSv1_3
  |   | Cipher in use: TLS_AES_256_GCM_SHA384
  |   | Perfect Forward Secrecy: yes
  |   | Session Algorithm in use: Curve X25519 DHE(253 bits)
  |   | Certificate #1 of 2 (sent by MX):
  |   | Cert VALIDATION ERROR(S): unable to get local issuer certificate
  |   | This may help: What Is An Intermediate Certificate
  |   | So email is encrypted but the recipient domain is not verified
  |   | Cert Hostname VERIFIED (mail.mydomain.win = \| DNS:mail.mydomain.win)
  |   | Not Valid Before: Jan  3 21:28:22 2025 GMT
  |   | Not Valid After: Jan  4 09:28:22 2025 GMT
  |   | subject:
  |   | issuer: /CN=Caddy Local Authority - ECC Intermediate
  |   | Certificate #2 of 2 (sent by MX):
  |   | Cert VALIDATION ERROR(S): unable to get local issuer certificate
  |   | This may help: What Is An Intermediate Certificate
  |   | So email is encrypted but the recipient domain is not verified
  |   | Not Valid Before: Jan  3 21:28:20 2025 GMT
  |   | Not Valid After: Jan 10 21:28:20 2025 GMT
  |   | subject: /CN=Caddy Local Authority - ECC Intermediate
  |   | issuer: /CN=Caddy Local Authority - 2024 ECC Root

This is my compose file extract:

hostname: mail.mydomain.win

environment:
 - SSL_TYPE=letsencrypt

volumes:
 - /srv/DockerDrive/Dockerapps240/Caddy/caddy_data/caddy/certificates/local/mail.mydomain.win/mail.mydomain.win.crt:/etc/letsencrypt/live/mail.mydomain.win/fullchain.pem
    - /srv/DockerDrive/Dockerapps240/Caddy/caddy_data/caddy/certificates/local/mail.mydomain.win/mail.mydomain.win.key:/etc/letsencrypt/live/mail.mydomain.win/privkey.pem
  

My Caddyfile extract is:

mail.mydomain.win {
  tls internal {
    key_type rsa2048
  }

  # Optional, can be useful for troubleshooting
  # connection to Caddy with correct certificate:
  respond "Hello DMS"
}

[MarcS1975]

OK - here is the solution. In your Caddyfile

replace tls internal {
with
tls {

I dont know why the DMS handbook recoomends internal but Caddy will only create a self-sgned internal certificate which is not usable for email exzchange. Maybe worth updating the DMS handbook here

[polarathene]

I dont know why the DMS handbook recoomends internal but Caddy will only create a self-sgned internal certificate which is not usable for email exzchange. Maybe worth updating the DMS handbook here

Please pay attention to the information at the end of that screenshot from the referenced docs, it clearly explains what tls internal is doing.

It links to the Caddy official docs for more information, but if you're wanting to use public CA like LetsEncrypt, you should be able to just remove the tls line and use the default key type and length (which might be ECDSA instead of RSA, if so some older mail servers may not support it and fallback to delivering mail on port 25 without TLS established).

You can remove the internal part of this directive if you want to set the key type for this site-address, or you could configure that in your global Caddy settings instead.

[MarcS1975]

Thanks for the input. I would assume that the default intention for DMS users is that they want to use letsencrypr certificates. That's also the assumption of all the other certificate setup options mentioned in the DMS handbook. Only Caddy setup instructions create a setup that does not work. All I am saying is that you can provide a default setup by just removing the word internal in your suggested Caddy line. The TLS can remain and Caddy works well now with valid certificates.

…

On Sat, 4 Jan 2025, 23:14 Brennan Kinney, ***@***.***> wrote: I dont know why the DMS handbook recoomends internal but Caddy will only create a self-sgned internal certificate which is not usable for email exzchange. Maybe worth updating the DMS handbook here <https://docker-mailserver.github.io/docker-mailserver/latest/config/security/ssl/#caddy> image.png (view on web) <https://github.com/user-attachments/assets/2bebc91c-7cbd-406e-a26a-fca4d3e00e5a> Please pay attention to the information at the end of that screenshot from the referenced docs, it clearly explains what tls internal is doing. It links to the Caddy official docs for more information, but if you're wanting to use public CA like LetsEncrypt, you should be able to just remove the tls line and use the default key type and length (*which might be ECDSA instead of RSA, if so some older mail servers may not support it and fallback to delivering mail on port 25 without TLS established*). You can remove the internal part of this directive if you want to set the key type for this site-address, or you could configure that in your global Caddy settings instead. — Reply to this email directly, view it on GitHub <#4304 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMNNHGQXFRFVH3IWNESMNIL2JBTOFAVCNFSM6AAAAABUSNNALGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNZTGYYTQNI> . You are receiving this because you authored the thread.Message ID: <docker-mailserver/docker-mailserver/repo-discussions/4304/comments/11736185 @github.com>

[polarathene]

Yeah that's a fair point, thanks for pointing that out. I'll update the docs accordingly :)

Done: #4305 (Direct preview link)

You may want to take the additional note I included there. I haven't verified how Caddy is provisioning the certs, but if they're updated in a way that changes the inode, your certificate will start to fail once it expires until DMS is restarted (properly with docker compose up --force-recrate, or docker compose down).