I have developed several Caddy modules for on-demand TLS certificate lifecycle management, specifically for services that host an effectively unbounded number of third-party domains. These modules are designed to improve control, scalability, and abuse prevention. I’m sharing them here for peer review and welcome constructive feedback.
An on-demand TLS permission module that controls which hostnames Caddy is allowed to obtain certificates for. It supports allow and deny rules based on regular expressions or subdomain labels, enforces maximum subdomain depth, and can verify that the requesting hostname resolves to the server address before issuance is permitted. This helps prevent Caddy from attempting to issue certificates for domains not legitimately pointed at the service.
caddy-tls-issuer-opportunistic
A TLS issuer wrapper that automatically selects the most suitable issuance method based on DNS configuration. If an _acme-challenge CNAME delegation is detected (matching dns_challenge_override_domain), the module directs the configured ACME issuer to request a wildcard certificate using ACME DNS-01 validation. Domains without delegation fall back to the standard HTTP-01 or TLS-ALPN-01 issuance challenge and receive a single-host certificate instead.
A TLS issuer wrapper that applies configurable issuance rate limits after any subject transformation has occurred. This ensures limits are counted against actual certificates issued rather than raw requested hostnames, so multiple domains covered by the same wildcard certificate consume only a single slot. Renewals bypass rate-limit checks and are never blocked. The module is intended to help operators remain within CA limits such as those published by Let’s Encrypt.
These modules are production-oriented experiments, and I’d particularly value feedback on architecture, naming, edge cases, and whether any functionality would be better upstreamed into core Caddy.