For managed certificates, Caddy always uses 1 subject per certificate. There are numerous reasons this is considered a best practice:
X.509v3 certificates can use extensions, one of which is Subject Alternative Name (SAN). The client provides a list of names to be validated when requesting a certificate, and the names which are validated by the CA are added as SANs.
Although it is possible to map many names to one certificate (M:1), a one-to-one (1:1) mapping is recommended. 1:1 is easy to manage, less error-prone, reduces failures at scale, reduces the impact of revocation, and speeds up certificate maintenance. It also can enhance security since each certificate can use a different private key; thus if one key is compromised, the security of connections to the other sites is not automatically compromised as well. The only notable downside is that it may use more storage space since you will have more certificates.
M:1 might be required if:
- Storage space is extremely limited (unlikely, because storage is cheap).
- The web host / service provider charges for certificates and you need to reduce that cost.
- You need to manage fewer certificates due to CA-enforced rate limits.
- Your server software only allows one certificate per virtual host, and the virtual host serves multiple domains.
Using M:1 has little benefit in automated settings, complicates the addition and removal of names, slows down certificate issuance, and increases the chance of validation errors. There will be greater logical and operational complexity by combining many names onto one certificate. In addition, all those names necessarily share a single private key, so if one key is lost, all those sites need a new certificate with a different key. Multi-SAN certificates also have a larger size, so they slow down TLS handshakes.
If a single web server or cluster of servers is handling all subdomains of a single registered domain, it is often better to use and manage a single wildcard certificate. With Let’s Encrypt, this implies configuring the ACME DNS challenge, which requires control over the DNS for the registered domain. Managing certificates for many subdomains of the same registered domain without control over the DNS is not recommended.
(Upon re-reading, I just realized that one other reason is missing from that document: multiple SANs per certificate creates a small information leak by implicitly associating two subjects to be related to each other. This might not be desirable in some situations.)
This actually has nothing to do with the number of names per certificate(s). Rather, your config does not tell Caddy to serve on the IP address, so it doesn’t manage any certificate for the IP address. You only gave it wildcard DNS names, no IP addresses.
X.509 certificates support multiple subjects.
To clarify, Caddy only supports SAN certificates. It just doesn’t use more than 1 SAN per certificate. (For reasons described above.)
And fortunately, this is often not the rate limit people hit.