Failed renew cert after transfer old keys to new server


#1

I did the letsencrypt keys on previous server, than moved to new one, copied the keys and connected nginx to the old keys… Now I need to renew it and I got error.
Here is the details:

My domain is:


I ran this command:
letsencrypt -a webroot --webroot-path /var/common-le-root/ -d autodstools.com certonly

It produced this output:
Failed authorization procedure. autodstools.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://autodstools.com/.well-known/acme-challenge/Q1iKXz2mn5IF3ZC8YGSB-rwv2kxS9dMYmmIwrng9wkk: "

404 Not Found

404 Not Found


"

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: autodstools.com
    Type: unauthorized
    Detail: Invalid response from http://autodstools.com/.well-known
    /acme-challenge/Q1iKXz2mn5IF3ZC8YGSB-rwv2kxS9dMYmmIwrng9wkk:
    "

    404 Not Found

    404 Not Found


    "

    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 operating system is (include version):
ubuntu 14.04
My web server is (include version):
nginx
My hosting provider, if applicable, is:
ovh.com
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

is your webroot correct ?

If you add a plain text file at /var/common-le-root/.well-known/acme-challenge/test with contents “ok” can you reach it in your browser at http://autodstools.com/.well-known/acme-challenge/test ?


#3

I can’t even edit this file…


#4

Why not ? permissions ? an error of some sort ?


#5

@lpozin95 expects you to look in your crystal ball @serverco :grin:


#6

mine’s not working so well at the moment :wink:


#7

No such file or directory… however I saw now I posted here wrong path that I tried…
However the path I tried /home/my_user/letsencrype…
Same details there…


#8

The path where the keys and nginx search there is:
/etc/letsencrypt/live/autodstools.com/


#9

Do you know what the webroot for your website is ? i.e. the location where your site index file is usually located


#10

I am using proxy path to gunicorn sock on nginx…
But I know where the index file of my django app, yes…


#11

so if you create a folder in the webroot called “.well-known” and then within “webbroot/.well-known” create a new folder called “acme-challenge” and then create a plain text file called “test” with contents “ok” … can you reach it in your browser at http://autodstools.com/.well-known/acme-challenge/test

Alternatively, you could set your nginx proxy to send requests for .well-known/acme-challenge/* to an alternative location - again you could verify things are working with the above test.


#12

I saw something new… please tell me if I still should do previous check:
" Renewal conf file /etc/letsencrypt/renewal/autodstools.com.conf is x
x broken. Skipping. "
The file is from the previous server, where was apatche… now it’s nginx:
this is file content:

renew_before_expiry = 30 days

version = 0.9.3
cert = /etc/letsencrypt/live/autodstools.com/cert.pem
privkey = /etc/letsencrypt/live/autodstools.com/privkey.pem
chain = /etc/letsencrypt/live/autodstools.com/chain.pem
fullchain = /etc/letsencrypt/live/autodstools.com/fullchain.pem

Options used in the renewal process

[renewalparams]
authenticator = apache
installer = apache

and account id on the bottom…


#13

The easiest approach regarding your existing certificates might be to just delete your /etc/letsencrypt directory entirely (though keeping a backup around just in case is always a good idea), unless you have other certificates that you need to keep as well. Switching the web server and certbot plugin would require quite a number of manual changes to the renewal configuration file - it’s typically not worth the hassle when you can just re-issue the certificate (which needs to happen anyway for renewal).

The webroot plugin expects that your web server serves any file that certbot puts in the directory you provide via the --webroot-path argument, i.e. /var/common-le-root/ in your post. This is typically the path you use for the root directive in your nginx server block. If you use nginx only as a reverse proxy, you typically want to add a special location directive for the ACME challenge path. This could look roughly like this:

server {
  # reverse proxy stuff

  location /.well-known/acme-challenge/ {
    root /var/common-le-root;
  }
}

#14

“/var/common-le-root;” what should be in this directory? this is where I run the command?


#15

Wow! just remove the directory worked great! Thank you all!


#16

That’s the path you tell the client to write the challenge verification files to via --webroot-path. You’ll just need an empty directory, certbot will take care of the rest and nginx should serve the files with the configuration snippet from my previous post.


#17

Misstake… it doesn’t

  • If you lose your account credentials, you can recover through
    e-mails sent to ebayconquermanager@gmail.com.
  • The following errors were reported by the server:

Domain: autodstools.com
Type: unauthorized
Detail: Invalid response from http://autodstools.com/.well-known
/acme-challenge/ZIMkFSLKHOxdlJqJyJ3N2C_ECb41Z-1Oh9XABqXz3G8:
"

404 Not Found

404 Not Found


"

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.

  • Your account credentials have been saved in your Let’s Encrypt
    configuration directory at /etc/letsencrypt. You should make a
    secure backup of this folder now. This configuration directory will
    also contain certificates and private keys obtained by Let’s
    Encrypt so making regular backups of this folder is ideal.

#18

On nginx I have:
location ~ /.well-known {
allow all;
}


#19

To clarify: have you added the configuration snipped I provided to your nginx server block, specfically to the server block that handles HTTP (rather than HTTPS, in case those are separate)? Feel free to post any relevant configuration files as a whole if you’re uncertain if it’s right.

Your nginx access or error log might also give some clues as to why the file was not found.


#20

Can you maybe please add me on skype? and we will post the fix here on the finish?
zzliorxx.
Thank you!