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.