in case A: for the first (main) server A having a real domain “example.com” and an alias or subdomain “www.example.com” with the same external IP A (server A is with other servers behind a pfSense/HAProxy)
in case B: The two other servers B1 and B2 each having a real alias or subdomain “raspi.example.com” and “blog.example.com” with the same external IP B (servers B1 and B2 are with other servers behind a pfSense/HAProxy)
B1 => root@RasPi31:/home/pi/letsencrypt# time ./letsencrypt-auto => only "raspi.example.com"
B2 => root@RasPi32:/home/pi/letsencrypt# time ./letsencrypt-auto => only “blog.example.com”
As soon as I transfer one of server B1 and/or server B2 to environment A, the request of a collective cert for *.example.com failed, and also for the full list.
How can I achive this collective cert for environment A?
For restriction 1, this is true if you’re using the TLS or HTTP validation methods as certbot-auto (formerly letsencrypt-auto) can’t modify the other server. If you use a different method such as DNS, you could get a single certificate.
For item 2, I’m not all that clear. What method are you using with certbot there? The TLS method should work, assuming the IP for all domain names point to server A. Alternately, if you’re using webroot http validation then you may need to map the roots for all the names so the challenge can go in the right areas to be read.
Also, not sure if you literally mean you’re trying to get a certificate for “*.example.com”. If so, wildcard certificates aren’t currently supported.
The DNS method is relatively new and supported by some clients better than others. The basic idea is that you put a TXT record up on your domain's DNS and that is used to prove ownership. This only really works if your DNS provider has an API to change records. If they don't, it's a manual update every two to three months.
Certbot can work with the DNS validation method via the manual plugin, but other clients like acme.sh and dehydrated have better support for the DNS method.
Certainly. This should work fine for the tls-sni-01 method or http-01 method.
For the TLS method, your server gets configured temporarily to serve a specially generated certificate to validate ownership. This is usually the common configuration for the nginx or apache plugin.
For the HTTP method, you just need to make sure certbot can place a validation file in a directory that will be served under the /.well-known/ path of the website. Depending on how you have things set up, you can use a single directory and alias it in for each of the sites or use multiple directories and just pass those to certbot. You can read a bit more about this in the webroot plugin documentation for certbot.
There is one exception to this which has often been discussed on this forum: if both servers speak HTTP and can receive connections from the public, and you can make one server redirect /.well-known/acme-challenge to the other server, then the other server can get a certificate that covers both servers, because the certificate authority will follow HTTP redirects encountered during validation.
Please take a note, that all of the three servers A and B1 and B2 have HSTS enabled: Here is an example code for blog.example.com (see server B2 above):
Server => pfSense/HAProxy => Domain/Subdomain ===============> HSTS enabled
A =====> ext. IP A ========> example.com and www.example.com ==> yes
B1 ====> ext. IP B ========> raspi.example.com ================> yes
B2 ====> ext. IP B ========> blog.example.com ================> yes
May be that there is another reason, I've found out recently when renewing a cert on a simple domain like example.com with an alias/subdomain www.example.com. After an apt-get update/upgrade, I renewed the cert on Raspbian with
sudo bash
pushd letsencrypt
time ./letsencrypt-auto renew
Here I've got an error. May I send you the logfile?
At this point, I had to open firewall (with an appropriate NAT rule) for ports 80 and 443 during the renewal process. After that, I startet the renewal process again with
time ./letsencrypt-auto renew
This time the renewal process has been successful, and I closed the firewall for ports 80 and 443 immediately.
both, have got an A+, only the link SSL Checker have got a correct chain, but the link ...hostname=www.example.com has shown a chain, but with a wrong duration of days (9 days instead of 89).
Why do I have to open the firewall? And why have I got wrong days of duration?
It looks like you got it fixed in the meantime because my own test showed a certificate valid until November for both names. While the SSL Shopper page still showed 9 days for one of them, it said that it last saw that result about 7 hours ago, and when I told it to check again now, both of them came back showing 89 days.