Hi friends,
running on a machine where certbot is already configured and operational, which is the correct procedure to be followed to add a new domain with any subdomains?
Adding the new domain and relative subdomains to the configuration file and running certbot is it enough and right, so for renew?
Many thanks!
First, I’d recommend to put only settings in cli.ini which are common between multiple certificates. Settings such as server, email and if you always want the text interface with text = True. All other settings I would recommend putting on the command line: these settings will be remembered in the renewal configuration (which is different from cli.ini).
So, for your question: is this for a complete other certificate? I.e., complete other domain et cetera? If so, I’d recommend just generating a new certificate by using the regular command line call to certbot (or certbot-auto, if you’re using the latter)…
If it’s not a complete new certificate, you should also use the command line options to certbot to generate the previous certificate, but with extra options: of course the extra (sub)domains you’d need and the --expand argument. This makes sure your current certificate will exist in the same lineage/location, but just with the extra (sub)domains added.
If you have done the above just once, you can use certbot renew again for renewal. (After 60 days or so of course…)
Ah, well! In this regard, I take this opportunity to ask you another question:
using "certonly" and "--webroot -w" is it possible to set a unique "document root" for all server domains and subdomains?
ok!
Well..
from User Guide:
--expand
If an existing cert covers some subset of the
requested names, always expand and replace it with the
additional names. (default: False)
If possible, could you give me a simple example usage? It's not clear for me how invoke this option.
Perfect! 
Many many thanks!
As far as I know, the webroot authenticator wants to know the domains you're getting a certificate for with the -d option. But you can certainly use many, many -d attributes with just one -w attribute.[quote="danjde, post:3, topic:19957"]
from User Guide:
--expand
If an existing cert covers some subset of the
requested names, always expand and replace it with the
additional names. (default: False)
If possible, could you give me a simple example usage? It's not clear for me how invoke this option.
[/quote]
Sure.. For example, you've generated a certificate a few weeks ago:
certbot -d example.com -d www.example.com -d foo.bar -d www.foo.bar
All went well!
But then, oh no, you just reminded yourself: your webmail wants TLS too ofcourse! So you want to add mail.example.com and webmail.foo.bar. Ánd you want to keep your previous domains and certificate in the same spot.. No biggy:
Just copy/paste the above and add the extra domains and --expand:
certbot --expand -d example.com -d www.example.com -d foo.bar -d www.foo.bar -d mail.example.com -d webmail.foo.bar
Voila, a new certificate but in the exact same spot in the same directory and the same lineage. But now with extra domains 
..so I could create a directory such as /var/www /letsencrypt/ which serves together the acquiring process of all new certificates?
Wow! Simply perfect! Excellent this possibilities!
But one thing I still do not understand: when I add a new domain (and subdomain, webmail, etc, etc..) it would be better to create a separate certificates for single domain/subdomain or a single certificate which includes every server domain/subdomain? Or certbot creates individual certificates for each domain in any case?
many thanks again (and again)!
It depends what makes best sense for you which names and how many should be in each certificate. Personally I would suggest splitting them by "topic" so that e.g. if you had several DNS names related to a blog about parrots, and then also some for a web forum for people who really like chocolate cake, you'd separate those out. But if operationally it's more convenient to do it some other way, that's fine too.
One practical benefit to having all the names served by a particular IP address in a single certificate is that very old web browsers (e.g. Internet Explorer on Windows XP Service Pack 3) don't know SNI, the method to tell a server which names you're expecting to see on the certificate before it's sent. So for these browsers, having just one certificate means your web server knows it's always sending the right one. On the other hand a practical benefit to having several separate certificates is that if you move some services to another machine, or in the case of a business you sell off some services to another outfit, you can just move the certificates relevant to the service that's moving, rather than having to mess about issuing new ones and so on.
Let's Encrypt only restricts you to 100 names per certificate, and to a certain number of new certificates (it considers a "renewal" to be only when a certificate has precisely the same names as some other certificate issued previously, any additions or removals aren't counted as a "renewal" for Let's Encrypt even though the main purpose may be to get the newer certificate) per week. For a small outfit this shouldn't be any problem regardless of how you divide things up.
Perfect, clear!
To summarize at this point I need to understand well how to proceed to create single or multiple certificates.
If it's right, whenever certbot is invoked, it generates a single certificate. So if I want to split them by category, certbot should run once for each group/category, and/or if groups/category are 5 should run it five times. Is it correct?
Then I've read on another post, that certbot consider the first domains on the command line, as the CN domain. So my other question is:
on a VPS with webserver and email server, should it better make my FQDN as first domain invoked by certbot?
many many thanks again!
Yes you have this correct about how often to invoke certbot.
The use of X.509’s Common Name field for a DNS name was actually deprecated at the turn of the century, in addition to filling out CN, Let’s Encrypt will also (all public CAs are supposed to do this) always fill out every name as a SAN, and all modern browsers will ignore the CN altogether once they detect a SAN. The main purpose to selecting a name to put first, and thus appear as CN, is that inquisitive visitors might see it displayed, whereas they need to dig further to see the SANs.
Perfect, very very clear!
Thanks very much for your help!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.