Well, one interesting problem is that we're about to switch servers, which means a switch of IP addresses. Right now the domain entries necessarily point to the old servers.

How can I obtain SSL certificates covering the new IP-addresses?

Also: the old servers run a very old version of OS/X – not Linux – and I don't expect that the validation client would run well on them.

We do have control of the last-stage DNS. We should be able to add TXT-entries or whatnot.

What do you folks think is the best way to proceed in this case? I would like to have certs set up on the new boxes before cutover.

letsencrypt certs are issued for the domain name not IP addresses. So it's a non-problem.

1 members found this post helpful.

To expand on TenTenths answer:

LetsEncrypt does not issue certs for IP addresses:
https://community.letsencrypt.org/t/...main-name/6082

But yes, it is possible to get a cert, from a different CA, for a public IP. However rare:
https://cabforum.org/guidance-ip-add...-certificates/

All right, ladies and gentlemen, I thank you for this guidance.

So, here's my situation:

• I can put anything that I want to, for verification purposes and so on, "on the old server." (Which, by the way, controls about 100 different apparently-different web stores.)
• I don't think I have a ghost of a chance for running LetsEncrypt's preferred client there.
• The new server is drop-dead easy: Ubuntu LTS.
• We also control the DNS server, although I don't know how much the gentleman who is in charge of this really knows about the fineries of it, and I haven't personally looked at the tool he uses.

Therefore – recommendations, please. How should I proceed? Start looking seriously at LetsEncrypt's tools on the new machine, and jimmy whatever verification-response is needed on the old one? (DNS? Web content?)

Also, I'm concerned about anything that a tool might try to do "to fiddle with Apache, to set up a virtual host," what have you. I've got a heavily load-balanced multi-whiz-bang thing here and I don't want any tool f*cking with it trying to do anything "clever" with it.

With very little time to "do absolutely the right thing here," I continue to be "grateful in advance." (As in: "priceless.™")

I'd set up the certificates (plain copy from old server) on the new server, where the vhosts will point to them. They are valid for the domains, and the IP doesn't matter. DNS administration is your main task here. Point the domains in question to the new server only when certificates and vhosts on the new server are 100% ready.

Once set up there and things are working, you can start setting up renewal scripts and get that right while sites are up and running. Keeping everything in the default area (/etc/letsencrypt/*) will probably make everything as smooth as possible for you.

Just my .2

... problem being, "the old certificates were not LetsEncrypt," and ... long story ... most of the old sites didn't even have them.

Sorry about not registering that. Validation has to happen where the domains are pointed, so there are 2 choices. On the old one or the new one. I'd pick the new one since that's where it has to work - and continue to work. That leaves you with the need for pointing the domains there so you can have LE validate them.

Set up the framework and migrate the sites. If there are databases involved and you're going to export/import. You'll have some downtime anyway. And it practially takes 5 minutes to validate the sites. A DNS zone change is usually majorly reflected within a couple hours. Do all this at night time and I'd say you're golden. Of course I'd make sure to have control of the DNS when doing it, this thing is just about timing.

Okay, then ... "how would you suggest that I go about doing it?" With the DNS, or with content?

Like I said, content first, DNS after. So the content is ready when the domain is pointing to it. Once you do the changes in the DNS, you just have to keep spamming DNS lookup from the new server to see when you can authenticate new SSLs.

I'd create a local DNS first and see if the vhosts are configured correctly if you're a bit unsure and want to test the configuration before you go "live". Create the real domains in the local private DNS and have your computer use that DNS for looking up all the domains. It will then try the new server instead, and then you can see if the vhosts works. Be sure to have http/80 vhosts going the first time you authenticate, afterwards you can continue using only SSL.

On my Debian 8 box I did this to set up LE.

I'd be more worried about databases if there are any. Those may require very careful planning, if there are any e-commerce sites in the works. SSL is easier to deal with, even if it fails at first.

Databases and so forth are out there but entirely behind the scenes. They can only be reached through OpenVPN tunnels. (Even on the inside.) Thanks for the info.

Hmmm... I have about 75 domains to validate in a very quick hurry, and all of them actually are served from the same underlying software. Might this be a problem for domain validation? It would be both time-consuming and error prone for me to attempt to modify the <VirtualHost> entries in some way to provide each host with a unique location for the challenge-response file.

It was not quite clear to me what the dns-01 challenge consists of. We do have central control of the DNS server which serves all of these sites. But, once again, it serves all of them at once.