Nginx takes me to first site with valid config, while migrating. Config error or am I a doofus?

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: accessmontana.com (migration)

I ran this command: see below

It produced this output: see below

My web server is (include version): nginx 1.18.0-6.1+deb11u3

The operating system my web server runs on is (include version): Debian 5.10.179-1

My hosting provider, if applicable, is: myself on a Google Cloud VM

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

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

This is a bit of a catch-22. I migrate wordpress sites to my hosting server a lot, and this has been an ongoing issue ever since I switched from Apache to nginx years ago. I have all sites under a single IP addr that points to my Google Cloud VM that runs my webserver.

To migrate a site I:

  1. Grab the database and files from the wordpress sites and copy them to my server
  2. Set up my host DNS
  3. Set up my nginx config files for the site (For config example see here)
  4. Change my host file on localhost to point at my server for that site

The site on my machine is still set up for https as it was on the original server of course. When I try to access it, my browser throws a warning because it can't find the ssl cert. There isn't one at this point. Instead of bringing up the site anyway so that I can verify that everything is there and working, nginx takes me to the first site alphabetically that has a valid cert. So when I goto example.com, I get a warning, ignore it, and anexample.com shows up instead.

I can't create an ssl certificate with certbot yet, because I'm not the authority until the owner points the site's A record at me.

So, what I do is cross my fingers that everything migrated and I call the client and ask them to change their DNS. I warn them that when they do so, for a moment their URL will bring up the wrong site, so they need to call me the moment they make the change. Then I run "sudo certbot --authenticator webroot --installer nginx --webroot-path /var/www/example.com/", certbot does it's thing and hopefully everything works out. If I miss their call, or I'm not available in that moment it's a disaster.

I haven't read of anyone else going through this stress, so there must be something weird about my setup.

Can someone help me sort this out?

Apologies for the wall of text, but it's better than too little info.

Thank you.

1 Like
2

I'm not going to parse your sequence but there is no reason you can't have a working site before the client switches the DNS

Just get the cert (fullchain.pem) and privkey.pem files from your client. Setup the HTTPS server block using that. Test using your local DNS as you are.

When it is working the client switches DNS to you and voila

Once they are happy you work to setup Certbot and auto-renew.

Would that work?

4 Likes
3

Unfortunately not, because I don't have that kind of access to the original servers and the customers wouldn't know what I was talking about.

4

Do you have access to the clients DNS?

2 Likes
5

Sometimes. Most of the time I have to call them and instruct them over the phone.

6

Hm, that makes using the dns-01 challenge to get a brand new cert to use on the new webserver (before the migration) a bit harder, but not impossible.

2 Likes
7

Agree.

@bearcatsandor Could you have them add DNS CNAMEs for the needed domains to a DNS system you control?

That would allow you to issue a cert for those names. If they are not using an ACME DNS Challenge to get their current cert it won't affect them. Frankly, if they are I would think they would know enough to send you the current certs so I assume they are not.

Example:

_acme-challenge.customer.com     CNAME challenge1.bearcat.domain.com
_acme-challenge.www.customer.com CNAME challenge2.bearcat.domain.com

You could then use a --manual DNS challenge to get your "seed" cert. After testing and when client changes DNS A to your server you setup Certbot using HTTP challenge and auto-renew as prior plan.

The manual DNS challenge describes a TXT record value you place at challengeX.bearcat.domain.com

3 Likes
8

@MikeMcQ Different values for the CNAMEs shouldn't be necessary. Just putting multiple TXT RRs to the same destination hostname should work.

Also, OP could set up an acme-dns instance and use e.g. GitHub - joohoi/acme-dns-certbot-joohoi: Certbot client hook for acme-dns to make Certbot work with acme-dns. Might be easier than using the --manual plugin in combination with "a DNS system you control" (depending on the level of knowledge/DNS access of OP).

1 Like
9

Yeah, but, the "problem" was more how they get started so I went with minimalist approach. They plan to use webroot/nginx long-term so no need to bother with acme-dns. And, the CNAMEs at customer DNS could be removed once bearcat gets Certbot webroot running.

Agree unique CNAMEs not required.

3 Likes
10

Depends, if someone has easy access to a DNS server, sure, no probs, but if getting easy access to a DNS server is much more work than simply spinning up an acme-dns instance, I'd go for the latter :slight_smile:

1 Like
11

Agree. From their first post I think they have DNS access. Maybe I'm wrong :slight_smile:

3 Likes
12

I have DNS access on my own server (the destination) for sure.

1 Like
13

Then the idea in post #7 might work. Adding a CNAME is not that hard even for a novice customer.

You could practice a manual DNS Challenge on your own names first. Also see below and of course the Certbot docs for --manual

3 Likes
14

I guess maybe other people to whom sites get migrated have customers who are more tolerant of the fact that there may be an outage associated with the migration process, especially if the customers are not actively participating at a technical level?

Perhaps you could try using (or reverse proxying with) Caddy, which attempts to get a certificate automatically as soon as any client makes an HTTP connection referencing a specific domain name.

Or maybe write a script to try to detect when the DNS change happens, by querying the authoritative name server in a loop every 30 seconds or something once you know that a migration is likely to happen. The script could then try to request the certificate the first moment that it detects that the DNS record has been pointed at you. There would still be a brief outage during the migration, but it wouldn't have to depend on your being prepared to flip a switch manually. (I'm not actually immediately sure what the most reasonable way to do this while bypassing caches is... I don't know offhand of a library function that does the complete recursive DNS lookup from the root with no caching, and installing something like unbound seems like overkill here.)

Or maybe try to find a way to communicate to your customers that a brief outage is technically unavoidable during the migration unless they are able to get you administrative access to their old infrastructure, or able to get technical staff of the old hosting provider to coordinate with you. Not all customers would necessarily be satisfied with this, but it really isn't your fault at all, so maybe there's a way to say that convinces some people not to blame you for it.

3 Likes
15

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