I’m trying setup SSL on collection of apache servers (with private IPs) behind a public loadbalancer (who’s IP will eventually be registered with my DNS record).
Reading this:
it seems like certbot need a webserver running in order to work, (either an existing apache server or it creates a standalone server).
If my goal is just to create a certificate, why should I need a webserver running? Is the idea that certbot validates ownership of the domain by contacting the “standalone server” or its server plugin? The docs say “The authenticator validates that you control the domain(s)” but is a little fuzzy on details about how this is done (it can be done for example, by my placing text in my DNS records for my domain). Does it “validates that you control the domain” by contacting the server at the IP address?
If so, is it important that the server or plugin by accessible at the DNS record? (I don’t think this is mentioned in the docs)
If this is the case I need to setup my loadbalancer to forward to the server, and setup the DNS record to point to the loadbalancer) – but then, if I have multiple servers behind the loadbalancer, I can’t be sure its set to the one on which the certbot application is running.
Have I missed a trick here?
This may sound obvious, but not to us – we have many servers (certbot seems to assume we have one), and we generally don’t make our servers accessible to the public internet until SSL is configured.
will make things clearer. There are three ways to prove your control over a domain name; two of them require inbound connections (which does require some server machine to be present at that domain name already), while the third is based on the ability to update DNS records. It sounds like the DNS-01 method is probably the one that would best meet your needs, because it’s the only one that doesn’t require receiving an inbound connection.
Different plugins in Certbot support different challenges, so you need to use an appropriate plugin for the proof-of-control method that you want. Depending on the nature of your DNS service, another Let’s Encrypt client like acme.sh might be a more mature or full-featured choice than Certbot for getting certificates using the DNS-01 challenge method.
Please also note that if you are load balancing at the HTTP level, as is most common, the certificates on your origin servers will only be used to encrypt the connection between your origin servers and the load balancer. You would need to install certificates on the load balancer to encrypt connections between the load balancer and clients on the public Internet.
So you may not need a certificate on the origin servers if you trust your local network, or you might find it easier to generate your own private CA for securing this leg of the connection rather than using Let’s Encrypt, since these certificates won’t be seen publicly anyway.
Worked great – the only sticky part is that it takes an indeterminate amount of time for the edited DNS record update to be reflected and made visible to your servers. If I continue the setup too quickly, after editing the DNS TXT, then the challenge fails. When I run it again, it provides a new challenge text, meaning I have to start all over. If it cached the challenged text, I could simply re-run certbot a few minutes later.
Just don’t continue the setup until your authoritative nameservers return the proper response. You can check the TXT record yourself before proceeding.
Sure – but because DNS is a series of caches, what I see when I do a DNS lookup, may disagree with the DNS that’s queried when the challenged is checked.
That’s why I specified the authoritative nameservers for your domain. Caching isn’t a factor in Let’s Encrypt challenges, as Let’s Encrypt also only checks authoritative nameservers. All that matters is how long it takes your host to update these, which is usually on the order of immediately-15 minutes.
… shows the register TXT field has appeared, but then the certbot challenge sometimes fails.
Digging more, I found that if I re-run the dig request again the TXT record disappears, reappears, and disappears. So it seems my registrar (Network Solutions) has its own cacheing. This probably the effect I was seeing. Hmmpph.