Certificate renewal tied to IP of old server

Help
1

My domain is: staging.amhealth.com

I ran this command: certbot renew --dry-run

It produced this output: (see below)

My web server is (include version): OpenLiteSpeed 1.7.19

The operating system my web server runs on is (include version): Ubuntu 22.04 LTS

My hosting provider, if applicable, is: Linode

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 control panel

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

I recently migrated my /etc/letsencrypt folder from server 15.204.85.129 to a new server on Linode. I copied the entire folder to the new server, preserving permissions and symlinks. However, when I attempt to verify that a renewal will occur, I get 404 failures when certbot tries to access the test file. I can successfully manually create the .well-known/acme-challenge folder and place an object in there that is visible to the open Internet. I know that I don't have to, and that the agent will do that automatically. The file is visible, so its not a webserver permission problem.

The problem seems to be that every cert for every virtual host is trying to validate itself against the old server, and since I am running this command on the NEW server, it fails. Somewhere the old server IP address of 15.204.85.129 is hard-coded, and certbot still thinks its running there. Is there a configuration change I need to make to remove this hard-coded IP address of the old server? The errors I am seeing (for two sample sites) are shown below:

Processing /etc/letsencrypt/renewal/staging.detoxcenterla.com.conf

Simulating renewal of an existing certificate for staging.detoxcenterla.com

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: staging.detoxcenterla.com
Type: unauthorized
Detail: 15.204.85.129: Invalid response from http://staging.detoxcenterla.com/.well-known/acme-challenge/gVpN38AMIffrekz_kkOEuvXBBw3YG2WJTleB-eqJs0U: 404

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

Failed to renew certificate staging.detoxcenterla.com with error: Some challenges have failed.

Processing /etc/letsencrypt/renewal/staging.goldfinchservicesnj.com.conf

Simulating renewal of an existing certificate for staging.goldfinchservicesnj.com

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: staging.goldfinchservicesnj.com
Type: unauthorized
Detail: 15.204.85.129: Invalid response from http://staging.goldfinchservicesnj.com/.well-known/acme-challenge/nL7y9ui1GSUaD5qPmuysl8fNMJP1hbyW2GIUAgavbK4: 404

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

The following simulated renewals failed:
/etc/letsencrypt/live/staging.detoxcenterla.com/fullchain.pem (failure)
/etc/letsencrypt/live/staging.goldfinchservicesnj.com/fullchain.pem (failure)

2

Welcome @cosjef

Certbot does not remember the IP address used. Both it and the Let's Encrypt servers use the public DNS system to lookup IP addresses when needed

Your DNS still has the old IP

;; ANSWER SECTION:
staging.detoxcenterla.com.	0	IN	A	15.204.85.129

You said your domain name was staging.amhealth.com. The error message shows the detoxcenterla domain. Could you be redirecting amhealth to that?

The goldfinch domain DNS is the same as detoxcenterla

3 Likes
3

Mike: Thanks for the prompt response. I have not changed the public DNS yet, but instead added entries to the server /etc/hosts file to spoof the proper IP address for each of the multiple sites hosted on the new server. An on-server ping shows that the domain names properly resolve to the Linode IP address instead of the 15.204.85.129 address. Does Certbot ignore the local hosts file in favor of a public DNS lookup? I always understood hosts to take precedence. Is there a way to force certbot to use the local DNS resolve (hosts file)?

And sorry for the confusion; staging.amhealth.com is another of sites hosted on the same server. I was trying to limit the problem domain to just the staging.detoxcenterla.com and staging.goldfinchservicesnf.com websites, as there are a total of 10 sites on the server. They all resolve to the same IP address, and the litespeed webserver directs the traffic to the proper virtual host.

1 Like
4

Certbot is not the issue here. It is the Let's Encrypt Servers (Certbot is the client). The LE servers use the public internet to connect to your domain name. The only IP it knows is what is in the public DNS.

The hosts takes precedence when using local connections. LE uses the public internet. Getting the correct response from the server pointed to by the public DNS is essential to proving you control that domain name.

You could consider using a DNS Challenge rather than an HTTP Challenge. But, that is probably more work than it is worth.

Why can't you just use the existing cert on your new system while testing? No one on the public internet can see it until you change the DNS.

4 Likes
5

Thanks, that clears up alot. Certbot is tied to public DNS, regardless of challenge type. I am not in control of the DNS, but will ask my client to make the update and test after that. I do have the existing cert on the new server, and was trying to validate that renewal would work properly before cutting over to the new server.

2 Likes
6

That sounds like a good plan.

Both of these certs still have many days before expiration so you have plenty of time to test the Certbot renewal process once the DNS points to the new server.

3 Likes
7

No, as mentioned by Mike earlier, not Certbot. Certbot is just the client. The ACME server does all the validation, not the client. It's useful to have the concept and terminology clear and use it correctly :slight_smile:

2 Likes
8

Got it. Certbot makes the outbound queries to public DNS, but the ACME server does the heavy lifting. I appreciate the correction here. #learning

9

Not really.

Only to connect to the ACME server, NOT with regard to any of the domains in the certificate. That's ALL the ACME server. The ACME server gets a list of domains the ACME client wants in the certificate. That's all the client does: provide the names. The ACME server, when validating those domains, uses a local resolving DNS server (Unbound for Let's Encrypt) to resolve the IP address, does CAA lookups et cetera and, if applicable, connects to the IP address. (Which isn't required for the dns-01 challenge.)

3 Likes
10

OK, this is super helpful. I appreciate the backstory of the moving parts.

3 Likes
11

To be clear: certbot doesn't do anything related to DNS [and your requests domain name].

3 Likes
12

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