Failed to renew certificate

Help
1

Ok, I'm really confused, and I have a few problem renewing certificates that doesn't seem to have a cause.

I'm using MacOS Server to run a website (which I'm fairly certain uses Apache), and a few months ago, I got a certificate. I don't remember the exact steps I took, but I got it to work. Certbot couldn't run on my server machine, so I generated the certificate on my normal computer, then just transferred it over. Everything worked fine.

Now, I'm receiving messages to renew it, so I used the "sudo certbot renew" command on my new machine, with the intention of copying the cert back over, just like before. However, this spit out a bunch of errors (shown below):

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

   Domain: cvprogramming.tk
   Type:   unauthorized
   Detail: Invalid response from
   http://cvprogramming.tk/.well-known/acme-challenge/AmUAqkVkBLksnur35j7n-FMjmdkErPZmoQe1SNeoZMQ:
   "<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
   <html><head>
   <title>404 Not Found</title>
   </head><body>
   <h1>Not Found</h1>
   <p"

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

My next step was to copy over my entire web server to my new machine, re-port forward everything to the new machine, then try again. Still the same error (only with a slightly different file path after "acme-known/".

I also tried generating an entirely new certificate on the new machine, which spat out this error:

Exiting abnormally:
Traceback (most recent call last):
File "/usr/local/bin/certbot", line 11, in <module>
load_entry_point('certbot==0.26.1', 'console_scripts', 'certbot')()
File "/usr/local/Cellar/certbot/0.26.1/libexec/lib/python3.7/site-packages/certbot/main.py", line 1364, in main
return config.func(config, plugins)
File "/usr/local/Cellar/certbot/0.26.1/libexec/lib/python3.7/site-packages/certbot/main.py", line 1246, in certonly
domains, certname = _find_domains_or_certname(config, installer)
File "/usr/local/Cellar/certbot/0.26.1/libexec/lib/python3.7/site-packages/certbot/main.py", line 421, in _find_domains_or_certname
domains = display_ops.choose_names(installer, question)
File "/usr/local/Cellar/certbot/0.26.1/libexec/lib/python3.7/site-packages/certbot/display/ops.py", line 120, in choose_names
return _choose_names_manually()
File "/usr/local/Cellar/certbot/0.26.1/libexec/lib/python3.7/site-packages/certbot/display/ops.py", line 197, in _choose_names_manually
cli_flag="--domains", force_interactive=True)
File "/usr/local/Cellar/certbot/0.26.1/libexec/lib/python3.7/site-packages/certbot/display/util.py", line 185, in input
ans = input_with_timeout(message)
File "/usr/local/Cellar/certbot/0.26.1/libexec/lib/python3.7/site-packages/certbot/display/util.py", line 83, in input_with_timeout
rlist, _, _ = select.select([sys.stdin], [], [], timeout)
KeyboardInterrupt

I also tried reinstalling certbot, which didn't fix the problem.
Any ideas what I'm doing wrong? I've spent hours looking into this, and I'm yet to find anything that helps.

EDIT:
Support form:

My domain is:
cvprogramming.tk

I ran this command:
sudo certbot renew

It produced this output:

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

   Domain: cvprogramming.tk
   Type:   unauthorized
   Detail: Invalid response from
   http://cvprogramming.tk/.well-known/acme-challenge/AmUAqkVkBLksnur35j7n-FMjmdkErPZmoQe1SNeoZMQ:
   "<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
   <html><head>
   <title>404 Not Found</title>
   </head><body>
   <h1>Not Found</h1>
   <p"

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

My web server is (include version): MacOS Server 5.2 (I'm fairly certain uses Apache)

The operating system my web server runs on is (include version):
MacOSX El Capitan V10.11.6

2

Hi,

Could you please fill in this form? It will gave us some extra information in once.

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:

I ran this command:

It produced this output:

My web server is (include version):

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

My hosting provider, if applicable, is:

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

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

Thank you

1 Like
3

Sure, I edited the original post.

4

Hi @UltraProgrammer

looks like Certbot doesn't understand your old config-file and want's a user-input.

Instead of searching, where there are errors: Start new.

https://certbot.eff.org/docs/using.html#certbot-commands

If you run the command on the same machine, where your website is hosted: Use webroot and the http-01 - challenge. Perhaps use certonly to separate the process of creating the cerfificate from installing. And use the --staging or --test-cert - option to use the testsystem. There are limits, but the testsystem has own limits.

5

As I stated in the original post, certbot is not compatible with my server machine, and I’ve already tried restarting with a new certificate.

(That sounds sarcastic, it wasn’t meant to be)

6

Hi @UltraProgrammer,

If you run a Let’s Encrypt client application on the machine that’s not actually the web server, you normally have only three options for authenticating:

(1) A “remote webroot” method [not natively implemented in Certbot]
(2) A “manual” method [not compatible with automated renewal]
(3) A “DNS API” method

Do you understand what these are? Did you choose one and attempt to use it?

7

I remember seeing those when I tried using certbot with the ‘certonly’ option. I didn’t know what they did or how to use them, so I stayed away from it. I just didn’t want to break anything more than I already have. :smile:

8

OK, in order to obtain or renew a certificate, you have to prove your control over the names in the certificate. This requires doing something visible to the certificate authority, with details specified by the certificate authority. In the Certbot context, this is described in some depth at

The two most likely options are “create a file at a specific URL chosen by the CA” and “create a DNS TXT entry at a specific location chosen by the CA”. Certbot can only automate the first one if it’s running on the same machine as the web server or if you can write a script for Certbot that will log into the web server and create the specified file. It can only automate the second one if it has DNS provider API credentials allowing it to ask the DNS provider to create the TXT record (or, again, if you can write a script for Certbot to make the DNS change).

If you can’t do these things, there is the “manual” option in which Certbot will tell you what task needs to be accomplished, and then you can do it yourself. We always recommend obtaining certificates in a way that supports automated renewal, so we don’t recommend the manual method very much, since you would have to repeat the process manually before the certificate expires.

The getssl client has support for the remote webroot concept; if you can give it credentials to log in to your remote web server, it can use them to create the file requested by the CA.

1 Like
9

Alright, it seems like everything was successfu.l I ran this command and followed all the instructions it gave me:

sudo certbot certonly --manual --preferred-challenges http

This is the output (everything was successful):

IMPORTANT NOTES:
Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/cvprogramming.tk/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/cvprogramming.tk/privkey.pem
Your cert will expire on 2018-10-31. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew *all* of your certificates, run
"certbot renew"

However, I went to the specified file path to find that the files specified were just broken aliases. I checked "Get Info", and it turns out they were just aliases to themselves (See pictures below). Any ideas what is wrong?

36%20PM
36%20PM2432×1290 579 KB

10

I don't think that they're aliases to themselves (particularly because a couple of years ago I wrote the code that creates them!); I'm not familiar with the Finder interface for displaying aliases (symlinks). What made you conclude that they're broken? They should point to a corresponding set of files in /etc/letsencrypt/archive.

1 Like
11

I tried using a terminal to view the aliases as text files, and apparently, they do have contents. After running ‘cat /private/etc/letsencrypt/live/cvprogramming.tk/privkey.pem’, I got a text file that appears to have the private keys (go figure). However, when I tried to import the certificate (/private/etc/letsencrypt/live/cvprogramming.tk/letsencrypt_sslcert.p12), this private key didn’t work as the passphrase. Is the certificate’s “private keys” and “passphrase” two different things?

Thanks for all your help so far, by the way.

12

Very much so. It is the private key that would itself be encrypted with a passphrase, if one is used at all. But certbot doesn't encrypt the key, so if your .p12 file has a passphrase, it was added by whatever you did to turn it into a .p12 file.

1 Like
13

Ok, in MacOS server I tried to import “letsencrypt_sslcert.p12”. Is that not the file that I’m supposed to import? It appeared after running certbot, I don’t recall selecting any special options to cause it to be generated.

EDIT:
I tried importing the private key instead, and that appears to have worked! Thanks for all your help everyone!

14

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