I find caddy fast and efficient with reverse_proxy to py4web and that it generates and maintains ssl certificates. I see that it generates the proper key and crt files but not a CAfile, which I can use and point to for SSL/TLS in postfix and dovecot.
does caddy already have the capability to also generate and maintain a CAfile along with the key and crt files and if so how do I turn that on?
if not, then how to I point caddy to a letsencrypt location of certificates, keys, pems, etc., so that caddy can use those and either maintain those certificates in the letsencrypt location or turn that feature off?
thank you in advance. Lucas
oh, sorry, setting up a Debian 13.2 server with linux kernel 6.12.
I do not mean to lecture you. This is just to help me explain more clearly what I am trying to say.
In a typical client-server setup, there are a few situations where Caddy might need a custom CA file:
When Caddy is the server:
This usually comes up with TLS client authentication. In that case, have a look at the trust_pool directive.
When Caddy is the client:
By default, Caddy uses the system-wide CA certificate bundle, also known as the system trust store. If your operating system trusts the remote server, then Caddy does as well. As @Bruce5051 mentioned, this trust store is part of the OS.
If Caddy needs to connect to an ACME CA endpoint that is not trusted by your system, for example, a custom or internal ACME CA, then the ca_root directive is what you want.
Another case where Caddy acts as a client and might need a custom CA certificate is when it is used as a reverse proxy and connects to a TLS upstream that uses a certificate signed by a CA that is not included in the system trust store. In that situation, check out the tls_trust_pool directive.
If I completely missed the point of your question, please feel free to clarify. I will be happy to take another look.
This brings up one more case where Caddy acts as a server. It happens when you use the tls internal directive to let Caddy issue certificates using its own internal CA.
If other systems or applications need to connect to that Caddy instance, they will not trust the certificate by default unless you provide them with Caddy’s internal CA certificate. In that case, take a look at the tls internal documentation, specifically this part:
Caddy will attempt to install the root CA certificate to the system trust store, but this may fail when Caddy is running as an unprivileged user, or when running in a Docker container. In that case, the root CA certificate will need to be manually installed, either by using the caddy trust command, or by copying out of the container.
For example, you would need to take this file (the path in your deployment may differ):
/data/caddy/pki/authorities/local/root.crt
and deploy it on other systems that need to talk to your Caddy. There are some helpful instructions for that here:
In the Postfix world, smtp_tls_CAfile is used when Postfix needs to trust remote servers. In other words, when Postfix is acting as a client. For comparison, see what I wrote in:
On the other hand, the smtpd_tls_ directives in Postfix apply when it is acting as a server. That lines up with what I mentioned here: