Moved a domain to another sever and renewal won’t work – what now?

Help
1

I have had a Let’s Encrypt cert for quite some time now on my home server and it grew when I started adding new services and therefore domains.

What happened is that as the old server died, I moved everything to a new server (or actually two servers now). It seems I forgot to change something though (thatfunkyplace.* points to a NextCloud instance), as renewal won’t work.

The cert expires by tomorrow and the services are just for me and my family, so I wonder if there’s a quick and easy solution, or would it actually be easier to let it expire end generate new cert(s).

My domain is:

I ran this command:

sudo certbot renew --dry-run

It produced this output:

Waiting for verification...
Cleaning up challenges
Attempting to renew cert from /etc/letsencrypt/renewal/dafaq.wheremymonkeyis.at.conf produced an unexpected error: Failed authorization procedure. thatfunkyplace.wheremymonkeyis.at (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://thatfunkyplace.wheremymonkeyis.at/.well-known/acme-challenge/cdZY4Yk0UV9S_df5md26weMVhz5RQGkpJndQ1ib6TA8: "<!DOCTYPE html>
<html class="ng-csp" data-placeholder-focus="false" lang="en" >
        <head data-requesttoken="CiVlldCm5lCpw5L8L+PTwU". Skipping.
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/dafaq.wheremymonkeyis.at/fullchain.pem (failure)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: thatfunkyplace.wheremymonkeyis.at
   Type:   unauthorized
   Detail: Invalid response from
   http://thatfunkyplace.wheremymonkeyis.at/.well-known/acme-challenge/cdZY4Yk0UV9S_df5md26weMVhz5RQGkpJndQ1ib6TA8:
   "<!DOCTYPE html>
   <html class="ng-csp" data-placeholder-focus="false" lang="en" >
           <head data-requesttoken="CiVlldCm5lCpw5L8L+PTwU"

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address.

My web server is (include version):

nginx-1.6.2

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

Debian 8 (with Armbian kernel)

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

2

Hi @hook,

I guess you mean that the certificate should no longer apply to thatfunkyplace, but it should still continue to apply to the other names?

In that case, you should probably run

sudo certbot certonly --cert-name dafaq.wheremymonkeyis.at -d dafaq.wheremymonkeyis.at -d explorethe7seas.wheremymonkeyis.at -d lostboys.wheremymonkeyis.at -d matija.suklje.name

(@bmw, am I right to remember that certonly will get all the renewal parameters from the existing renewal configuration file when we specify domains but no authenticator?)

Another option might be

sudo certbot renew --allow-subset-of-names

which means not to give up if one or more names fail to renew (although this can be risky because other names that unexpectedly failed would then also be lacking in the new certificate).

Once a single renewal has been completed without thatfunkyplace, it will no longer be included in subsequent renewals so they can be done with an ordinary certbot renew command.

3

Thank you. That makes a lot of sense.

Actually, I do want to keep thatfunkyplace.* more than any other domain, but I might move some other domain to the other server, so that is useful.

I suppose the issue I have to fix is to get thatfunkyplace.* to forward the acme challenge somehow. Any ideas? Simply copy stuff (from where?) into the .well-known/ folder?

4

Yes, you can forward challenges by sending an HTTP 301 redirect. The verifier will follow the redirection.

This has been discussed in a number of threads here:

https://community.letsencrypt.org/search?q=301%20http-01

(Edit: this only works for the HTTP-01 challenge type, but that is the one that you’re using.)

5

Thank you :slight_smile:

This sounds like how I had it fixed on the old server as well (don’t ask me why asking online is much faster than recovering the data from the disks …I’ll just say LVM RAID1).

6

Since we want to keep thatfunkyplace.* in the cert, I'm not sure this matters anymore, but to respond to the question asked of me above.

Unfortunately, that is not correct. renew is the only subcommand that uses any renewal parameters from an existing renewal configuration file. Erica and I talked about changing this behavior a while ago and I created this thread for feedback but afterwards we decided to leave things as is.

7

I’m sorry for forgetting about this behavior, and thanks for the correction. That will definitely help me give more accurate advice to people who want to make changes to their certificates. :slight_smile:

8

I think I managed to fix it. Or at least temporarily work around it.

In any case, thank you for your help :slight_smile:

9

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