I don't think we like to use exit as it'll stop DMS (during startup, or the check-for-changes.sh service), the log is only warn. If we really do want to fail hard we use our panic helpers instead.

The other supported SSL_TYPE do allow for panic, so we could issue the warning followed by panic:

I'm not sure if that's the right choice, it's technically a misconfiguration related to it though. The logs would provide context of the warning prior to it and the SSL_TYPE=letsencrypt scope.

Using the panic above would trigger DMS shutdown fully, even from the check-for-changes.sh script noticing an updated acme.json if it fails to extract the cert.

I think we may not have panicked here as the acme.json was less explicit of a config vs the others, and the user had less direct control/influence over that 🤷‍♂️

You don't need to apply the suggestion, we could just revert the exit 1 you've added. Feel free to wait for another maintainer to share their opinion on what should happen 👍

In the extraction method call, you'll see some other failures are logged with warn and a return 1 (which is the proper way to exit a function early).

This is effectively copy/paste of the traefik method with the important distinction being calls to _extract_certs_from_caddy_data() instead of _extract_certs_from_acme().

As you're introducing a variant here, rather than duplicating this logic, you could instead detect caddy vs traefik handling into a common extract method.

Regarding earlier review feedback on a common extraction method, we can observe that there is common logic that can be shared, only a conditional is necessary for when traefik vs caddy differ. A slight refactor would make that a single conditional block?

Common check:

Attempt to retrieve / detect the certificate files (traefik example):

Common step (now that cert content is found, ensure directory for CERT_DOMAIN exists):

NOTE: The above SSL_DOMAIN is planned for removal (unnecessary legacy config contribtued a while back)

Final step, populate a copy of the cert content to internal files DMS is configured to use (traefik example):

The CertMagic referenced code is used for plenty of methods to sanitize a filepath. Most of these should not be relevant for DMS support as CERT_DOMAIN should already be aligned with a valid hostname (mail.example.com or example.com). The only special handling we've had was for SSL_DOMAIN=*.example.com but as no *. value is relevant to supporting the Traefik acme.json feature it's only a UX value that we'd rather just drop.

I've not looked at the filenames Caddy is generating, I assume wildcard_ prefix is the only one you'd encounter? If so you're just wanting to check if wildcard_${DOMAINNAME} is a valid match in the filesystem before $HOSTNAME and $DOMAINNAME, like we do with SSL_DOMAIN?

This method could instead just check for existence of the file like we do in a later step:

@georglauterbach or @casperklein might have a better suggestion to scan your child dirs of /caddy_data/caddy/certificates/ for existence of the directory or file "${CERT_DOMAIN}/${CERT_DOMAIN}.key". Probably with the find command. Then I suppose running the same check first with wildcard_ prepended to ${CERT_DOMAIN} instead would do the trick 😅

Yes, just use find. It was written for this use case.

Shouldn't be necessary once feedback is applied.

Consistency with nginx + traefik example configs:

Consistency with nginx + traefik example configs:

You removed the admonition (example type, the purple collapsible section in our docs): ??? example

Adding that back requires 4 space indentation of the codeblock that follows, like the JSON snippet prior was.

While the Caddy section was outdated a fair bit, you have dropped information about configuring the key type (Caddyfile and JSON examples). The self-generated and nginx-proxy sections both touch on this too, but it's most likely not too relevant / specific to DMS, so dropping these old examples is acceptable.

And here in the old docs we have an example filepath that your PR presumably operates on and is still roughly the same?

Like with certbot section, it advises mounting the relevant cert folder to /etc/letsencrypt/live location that DMS will internally check for with SSL_TYPE=letsencrypt:

Traefik has special support because of the acme.json format. Whereas I feel this PR is adding a very minor convenience to the user?

Our docs do cover SSL_TYPE=manual as an alternative to SSL_TYPE=letsencrypt. Both of which have check-for-changes.sh support as their locations are monitored:

However in your current PR state, your approach for Caddy would miss out on this and would not benefit. The Traefik acme.json support is hard-coded into our /etc/letsencrypt internal location which has been considered acceptable. While for this Caddy support we need to also rely on /caddy_data to monitor for changes (ideally only for those relevant to DMS, which is better supported if mounting the full path to isolate if the reverse-proxy was using the same data folder for other services, as shown with rspamd).

The difference with normal SSL_TYPE=letsencrypt is that unlike SSL_TYPE=manual there is no internal copy made. I'd like to simplify the SSL / TLS support, but haven't found time to. Ideally it'd be more generic in finding a cert from some location and then copying it to a fixed internal location. I understand the desire for convenience though.

And here in the old docs we have an example filepath that your PR presumably operates on and is still roughly the same?

Whereas I feel this PR is adding a very minor convenience to the user?

The reason for implementing Caddy support is that we can't know in advance the path where Caddy will store the certificates. Caddy uses Lets Encrypt or ZeroSSL by default, and may be configured to issue local certs, or use another CA. The paths depends on the issuer, and may look like the paths in the old docs, but they may also have acme.zerossl.com-v2-dv90 (or local, or other) instead of acme-v02.api.letsencrypt.org-directory

Th paths could also change over time, for example if a certificate is initially issued with Lets Encrypt, but for some reason the renewal fails and Caddy falls back to ZeroSSL.