exemple.com & www.exemple.com = primary website
xxx.exemple.com = other website
mx.exemple.com = mx server
ns1.exemple.com = dns server
api1.exemple.com = nodejs server
etc...
Quite many subdomains for quite many use.
What is the good practice between generate a wildcard for all services / subdomains or separate by server or subdomain or another criterion ?
Wildcard is a simple solution but is it really secure to share a certificate between all subdomains and services ?
We generate all our certificates on a dedicated server cs.exemple.com which connect and copy certificate files with scp after each renewal (post renewal script).
The files transport is secured but is there other dangers against which to guard ?
I would use an acme client on each server, to generate the smallest possible certificate, without moving the private keys. But it's a matter of personal preference. If doing as I say means you have your all-powerful dns credentials on each machine, don't do as I say. If you can use http-01 authentication (with standalone or webroot should work), do as I say.
We have install only one certbot on a virtual machine dedicated to certbot. So we will generate all certificate (for our domains and our clients’ domains) in this server then copy over scp from it.
We hesitate on two approach for our primary domain “example.com” :
1 - Use a single wildcard certificate (example.com & *.example.com) on all our servers (web, mail, nodejs, …)
Another vote for option #2 - it’s the least likely to break, easiest to automate, and provides the smallest blast radius if any key material or credentials get stolen.
Edit: I misread. I think you should generate keys and certs in the same location you use them. I can’t see a good reason to use centralization in your case.
I go for option #2, but it's ultimately your choice and your responsibility to maintain the system. I don't know how complex your system is and how doable is to have an acme client on each server, which may or may not be certbot, which is probably not the best choice here, being certbot a pretty complex python application with several dependencies (it's built with ease of use in mind) -- have a look at acme.sh
Another vote for option #2 - it’s the least likely to break, easiest to automate, and provides the smallest blast radius if any key material or credentials get stolen.
Ok, thx for you vote
Edit: I misread. I think you should generate keys and certs in the same location you use them. I can’t see a good reason to use centralization in your case.
We have a lot of server on different OS (and on old and new releases), so we don't want to install certbot on each server (and reinstall on each certbot update). Centralize is more simple and more robust.
There is a third option you should consider: use one certificate per server with the domains they need only, but generate them on the centralized certbot server and deploy with scp. (You’ll have to use dns authentication)
This has an important advantage over option #1: if one server (other than the certbot one…) is compromised you don’t have to replace all the certificates, just that one.
There is a third option you should consider: use one certificate per server with the domains they need only, but generate them on the centralized certbot server and deploy with scp. (You’ll have to use dns authentication)
This is what we just installed : a "Certification Server" under ubuntu with certbot. This server generate and renew files, with dns auth, then copy over scp command each file on each server.
This has an important advantage over option #1: if one server (other than the certbot one…) is compromised you don’t have to replace all the certificates, just that one.
OK, we will generate a certificate by server
If you have already such a deployment with individual certificates, then you don’t need a wildcard.
Security: Best solution: One ACME-client per server, so the private key is only on that machine.
Edit: I misread. I think you should generate keys and certs in the same location you use them. I can’t see a good reason to use centralization in your case.
I understand but installing and maintain certbot on ALL our machine is very costly in time. Copy with SCP isn't a good practice ?
Effectively acme.sh seems to be a better solution for installing separately certificates on each server. No centralized certification server and can be fast installed on new and old server (written purely in Shell)
Another question on this DNS mode install (7. Use nsupdate to automatically issue cert) :
We created a key by domain (key A for domainA , key B for domain B) but they tell us to a create a single bind key named “/etc/named/keys/update.key” which seems to be used for all domains . Isn’t it dangerous ???
include "/etc/named/keys/update.key";
zone "example.com" {
type master;
update-policy {
grant update subdomain example.com.;
};
}
on a given server create the certificate request but only for its own domain
from a central server pick up the certificate request and get it signed via dns-01 authorization (I am using my own ACME client, by the way: https://github.com/bruncsak/ght-acme.sh , and no need for root access to run it!)
transfer the certificate back to the server and reload the service
Repeat the same procedure for each of the server individualy. Advantages:
no secret is travelling the network, each key stays in his own server (certificate requests and certificates are public information)
no need for the individual servers accessing the DNS service for update
the server does not need to run HTTP service (it can be SMTPS/IMAPS server for example)
the server may be on the intranet even, no external access at all and that is OK too
. Isn’t it dangerous ???