Domain and subdomains in different locations, but one cert only

Hi

Having three servers (Apache 2.4) where I have:

  • 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)

=> root@RasPi3:/home/pi/letsencrypt# time ./letsencrypt-auto => List: example.com, www.example.com

  • 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

This is working fine. Cases A and B have their own certs requested for case A example.com, www.example.com, and for case B raspi.example.com, blog.example.com.

But now, I’m stating the following restrictions:

  1. I cannot request a single cert for example.com, www.example.com, raspi.example.com, and blog.example.com
  2. 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?

Regards,

Louis

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.

Sorry, I never heard about this method. Could you give me an advise or a link for further information?

Instead of “*.example.com” I would specify all servers FQDN: example.com, www.example.com, raspi.example.com, and blog.example.com.

Would this be possible?

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):

  • sudo a2enmod headers
  • cd /etc/apache2/sites-available
  • sudo nano 000-default-le-ssl.conf => insert => Header always set Strict-Transport-Security “max-age=31556926; includeSubDomains”
  • sudo nano default-ssl.conf => insert => Header always set Strict-Transport-Security “max-age=31556926; includeSubDomains”
  • sudo service apache2 restart
  • curl -I https://blog.example.com
    Now test in a browser: https://www.ssllabs.com/ssltest/analyze.html?d=blog.example.com You should get an A+

Perhaps, this is the reason, why root@RasPi31:/home/pi/letsencrypt# time ./letsencrypt-auto is not working for all (I mean the following list): example.com, www.example.com, raspi.example.com, blog.example.com

The following table should give an overview:

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

See also under link https://itigloo.com/security/how-to-configure-http-strict-transport-security-hsts-on-apache-nginx/

Nope, the Let's Encrypt CA ignores HSTS entirely when performing TLS-SNI-01 and HTTP-01 validations.

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

  1. sudo bash
  2. pushd letsencrypt
  3. 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.

While

https://www.ssllabs.com/ssltest/analyze.html?d=www.example.com and … ?d=example.com

both, have got an A+, only the link https://www.sslshopper.com/ssl-checker.html#hostname=example.com 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?

The certificate authority needs to connect to your site to confirm that you still control the domain name.

https://certbot.eff.org/docs/challenges.html

Perhaps you used certonly and haven't restarted your web server after the certificate renewal?

Otherwise, could you tell us your domain name?

I made a reboot, but no success. Yes: here is the link: https://www.ifit.li/
https://www.sslshopper.com/ssl-checker.html#hostname=www.ifit.li => 9 Days Not OK
https://www.sslshopper.com/ssl-checker.html#hostname=ifit.li => 89 Day Is OK

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.

Wau, I see, it works! Thanks a lot!

Hi

Another issue occurred: Moving the certified and working webserver https://raspi.ifittest.ch from IP 84.74.0.135 to 144.2.80.139 result in an Assessment failed: No secure protocols supported while relaunching https://www.ssllabs.com/ssltest/analyze.html?d=raspi.ifittest.ch (even if clearing the cache and re-creating the cert). Also the link https://www.sslshopper.com/ssl-checker.html#hostname=raspi.ifittest.ch result in a wrong resolution (84.74.0.135 instead of 144.2.80.139). Is it a matter of refreshing?

Regards,

Louis

It seems that is not possible since there are two more webservers with the same domain address. Sorry. Forget it.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.