Assume I have the following DNS A records for example.com on Cloudflare:
example.com, demo.example.com, forum.example.com and help.example.com all point to server A with the IP address of 11.111.11.1.
mail.example.com points to server B with an IP address of 22.222.22.2.
At present I have 5 individual certificates. One for each domain/sub-domain. I use the dns_cloudflare plugin to obtain certificates and manage their renewal. If I want to consolidate the 4 certificates on server A, what's the best way?
Should I have a single certificate for example.com and add each named sub-domain to it individually, or is it better to have a wildcard certificate for example.com that'll cover all existing and any future sub-domains along with www.example.com?
My concern with a wildcard certificate for example.com is that it'll cover the mail.example.com sub-domain – for which there is already an existing certificate albeit issued on a different server – and I don't want that to happen. The certificates issued on server A and B should remain separate.
If someone has access to the private key of a wildcard certificate (e.g. app admin, sysadmin, storage admin, backup admin) - they can perform man-in-the-middle interception and injection attacks on all hosts that match that wildcard.
If all servers have the same trust level (i.e. same users, same access control and same security policies) - sure, no issue in using a wildcard cert on all of them.
If a server is less trusted and you don't want to disclose or risk compromise of the wildcard private key - then get for it a separate named certificate with different keys.
For example you could use an *.example.com wildcard cert on production servers, and use individual test.example.com certs or a *.dev.example.com subdomain wildcard cert on non-prod servers.
If you have valid certificates use of which you are decommissioning and not going to use again - you can revoke them.
Of course if you think certificate private keys have been re-used on non-trusted servers, or otherwise compromised - you also should revoke the cert and change the keys.
Your title for the post starts with "Best Practice"
Only if a private key is "compromised" "stolen" or "lost" should it be revoked. Keep in mind that " If you don’t use delete to remove the certificate completely, it will be renewed automatically at the next renewal event." FYI
I'd not considered that. I have a cron job that run's daily to renew any expiring certificates. In the past, if I no longer needed a certificate I simply appended .ignore to its renewal config filename so that it wouldn't get renewed, but I'll use certbot delete in the future.
There are differing opinions about the need for wildcard certificates. If you maintain a small number of hosts, you might use your option #2.
If you are planning on adding and removing hosts often for testing, and other unforseen reasons.. wildcards make automation much simpler.
But really part of a cert management plan really does require consideration of @rg305's question...
As they're hosted on different servers I just assumed it's easier to manage if they have separate individual certificates. Are you saying I can use the same single certificate on 2 or more different servers? I didn't think that was possible.
If you have different applications administered by different people who can't be trusted with a shared key - you might want to have separate certificates with different keys for them.
If everyone has the same level of trust for a group of hosts, but can't be trusted with other hosts under the same domain - a single certificate with multiple SAN records.
If all hosts have highest level of trust - use wildcard certificate.
There are more reasons and use cases for other choices:
4. You could have multiple certificates for each of the above options using different algorithms for broader compatibility - i.e. a server presenting dual certificates one ECDSA and one RSA.
5. You could have different certificates to cater for different server capabilities - e.g. a certificate with Must Staple flag for servers that support OCSP Stapling and one without for servers that don't support it - even for servers with the same hostname, but listening on different ports/services.
You are not really constrained in your approach:
Same wildcard or SAN certificate could be re-used across different hosts.
Different certificates with identical CN and SAN records (including wildcards) but with different keys could be used on the same host.
Certificates with the same key, but different CN and SAN records could be used across different hosts.
It all comes down to trust:
Trust over which hosts the certificate controls.
Trust over who / what has access to certificate keys (and therefore controls the certificate and its hosts).
Trust over host storing certificate keys not being compromised.
Wildcard certs require DNS-01 challenge verification, so if you don't control your DNS to the point of being able to automate DNS-01 - you will have to stick with other options.
A single certificate could cover multiple domains such as example.com and example.net - same principle applies - it's all about trust.
You may wish to use the same certificate to simplify operations, or you may wish to use different certificates to minimise impact of compromise of one of the hosts.
If you want to use the same SAN or wildcard certificate across multiple hosts - you would need to consider the mechanism for distribution of the certificate between them on renewal and reload of running services.
If this can't be easily done - it could be easier for hosts to manage procurement of their own certificates themselves.
But it is very easy when all hostnames are hosted on the same box.
A heads-up to anyone doing this and using the certonly command like I do: Don't forget to update the certificate name in the appropriate virtual host configuration files!!!
By the way, that's exactly what the "only" in "certonly" meant, but sometimes it feels like only about 5-10% of our users have understood that intuitively! It contrasts with an implicit default that we thought of as something like "certpluswebserverconfiguration". (Note that "certpluswebserverconfiguration" isn't a real Certbot subcommand—the actual command that corresponds to that is called "run"!)
In drafting the handbook, I've started discussing with the devs the lack of semantic value of run and the oddity of certonly as an adjective as opposed to the verb acquire (think -a), which is far more clear semantically alongside install (think -i), which is the forgotten certbot child. I'm trying to clarify these things and possibly make suggestions for future direction.