Creating certificates for sites with domain names different to the hostname of the server that they run on


#1

I have two websites domain.com and api.domain.com that will both run on a server with hostname server01.companyname.com.

Do I need to add the server hostname to certbot command with an additional -d flag?

certbot certonly -n --webroot ~/www/domain.com/public --agree-tos -m user@domain.com -d domain.com -d server01.companyname.com
certbot certonly -n --webroot ~/www/api.domain.com/public --agree-tos -m user@domain.com -d api.domain.com -d server01.companyname.com

If so will the challange happen only in webroot or do I need to prove ownership via HTTP01 challenge of companyname.com as well?

My web server is (include version):
nginx

The operating system my web server runs on is (include version):
ubuntu 16.04

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
certbot 0.28.0


#2

If you don’t need the hostname included in the certificate, you don’t need to add the hostname to the certbot command.

You didn’t include the hostname companyname.com, so Let’s Encrypt won’t try to validate that one. It will however try to validate server01.companyname.com because that one you did include.

Also, I have no idea what you mean with “(…) happen only in webroot (…)”


#4

So maybe this partly where my confusion is, I thought that the domain in the certificate and the domain in the hostname of the machine have to match. I thought you get certificate mismatch errors otherwise, is that not the case?

Yes I meant server01.companyname.com rather companyname.com.

I thought that the HTTP01 challenge writes a file to the webroot and then checks it’s for existence over http, so how will it do the challenge for a different domain specified in the same certbot command? Do I just need to have both domains dns pointing to the same ip?


#5

The machine can only have one hostname, but a webserver running on that machine can host thousands of different hostnames through “virtual hosts”.

The only reason why someone would get a mismatch error is when the certificate presented to the client doesn’t include the hostname that client typed in his/hers browser address bar. It has nothing to do with the precise hostname of the server.

If those two (or more) domains are also running on the same webserver/machine, then yes, you’d need to point all those hostnames to the same IP. But that isn’t only related to the HTTP-01 challenge. That would have been required to host those domains anyway.

If the sites of the other domains are hosted on a different machine than the server where certbot is running, you’ll need to be “creative” if you want just one machine to run certbot. Also, you’d have to transfer the private key and certificate to the other machines when you create a new certificate.


#6

Thanks for clarifying that. So in my case then I don’t even need to add the second -d flag because the website & api aren’t going to be accessed using server01.companyname.com.

Actually it’s likely that the server hostname won’t be in dns because it will be behind a load balancer only accessible via private ip.

And that brings me to my next question, which I think is answered now that I know that hostnames don’t need to be in the certificate, if I have several servers load balanced (i.e. server01.companyname.com, server02.companyname.com), then I can just use the same certificate on each machine, because the hostname has no bearing on the validity of the certificate?


#7

Correct. But multiple servers behind a load balancer can create difficulties of their own. I.e., when the Let’s Encrypt validation server is trying to connect to your server running the ACME client, which webserver is it going to connect to?

Multiple solutions exist:

  • exempt requests for /.well-known/acme-challenge/ for load balancing and let the load balancer pass thru those request to just one server, the one running the ACME client (not sure if load balancers even support such a solution)
  • redirect every request for /.well-known/acme-challenge/ to a single hostname which bypasses the load balancer, i.e., on every webserver behind the load balancer, redirect to server01.example.com, which is bypassed by the load balancer and run the ACME client on that machine. Note: even when redirecting, it isn’t necessary to include that hostname in the certificate
  • use the DNS challenge

#8

@Osiris Thanks for the added details. I had planned to mount some shared storage for /.well-known/acme-challenge/ on each node so the challenge file would be accessible by all nodes. I read that in another forum post and tested and it does appear to work for certbot test renewals. One thing I haven’t had time to test was what the behaviour is of lets encrypt/certbot when each node renews it’s certs slightly staggered. So for example node1 renews certs, then a bit later node2 renews it’s copy of the certs, etc, will all the renewals succeed?


#9

Are all of those nodes using the same hostnames for their certificate? And are they all running a certbot instance for exactly the same certificate? If the answer is ‘yes’ twice, it’s better to develop a secure synchronization script for the servers. You might run into rate limits otherwise.


#10

Yes, 1 domain in the cert for the website and one for the api

Yes

That’s something I hadn’t thought of, thanks. Reading the limits docs is it the case then that the first limit the servers when renewing certs would run into would be the duplicate certificate limit at 5 per week?


#11

If the certificate hostnames are identical: yes.

It isn’t very good practice to have multiple identical servers running their own certbot. While the rate limits are there for run-away clients which might issue hundreds of certificates, if everybody running a cluster of webservers would let their webservers get a certificate on their own, it would imply quite a load on the Let’s Encrypt systems (mainly the hardware security module required to sign every certificate).

I think it’s good to set up some kind of distribution system so just a single server is handling the challenge validation and certificate issuance. On every renewal, it can be synced to the whole cluster.


#12

Initially it’s unlikely that the cluster will be more than 2 nodes, possibly 3 max. 3 nodes can handle quite a lot of requests. From my perspective having a separate component just to do the cert renewals adds quite a lot of compexity relatively speaking, but I do appreciate what you are saying about added load on the letsencrypt servers, so if the number of nodes gets larger then it makes sense to have, as you suggested, a separate component for renewals. I guess that might be one of the reasons the limit is there.

Thanks for answering my questions.


closed #13

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