Renew dry run failed

Hey, I’ve followed the guide Here (With the options None of the above + Ubuntu 18.04 LTS (bionic)), tured off my web server and used the command sudo certbot certonly --standalone. The certificates were created and I’ve configured them in my tomcat server. But when i run the command sudo certbot renew --dry-run i am getting an error (described below).
It seems that it tries to access (/.well-known…) which I didn’t configured in my tomcat server (because i ran the --standalone option).
Do i need to turn off my web server and let certbot run his nginx server? If yes, then how? (sudo certbot certonly --standalone fails when i try to run in once again). If not - then how to fix it?

Thanks in advance :slight_smile:

My domain is: buxsee.com

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

It produced this output:
`/usr/lib/python3/dist-packages/requests/init.py:80: RequestsDependencyWarning: urllib3 (1.25.7) or chardet (3.0.4) doesn’t match a supported version!
RequestsDependencyWarning)
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/buxsee.com.conf


Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator standalone, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for buxsee.com
Waiting for verification…
Cleaning up challenges
Attempting to renew cert (buxsee.com) from /etc/letsencrypt/renewal/buxsee.com.conf produced an unexpected error: Failed authorization procedure. buxsee.com (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from https://buxsee.com/.well-known/acme-challenge/oake1h8hfG2WvywhtEhiosbe2CBfBDKXBCH9vM3hzUs [18.202.251.235]: “<!doctype html><html lang=“en”>HTTP Status 404 \u2013 Not Found<style type=“text/css”>h1 {font-family:Tahoma,A”. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/buxsee.com/fullchain.pem (failure)


** 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/buxsee.com/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: buxsee.com
    Type: unauthorized
    Detail: Invalid response from
    https://buxsee.com/.well-known/acme-challenge/oake1h8hfG2WvywhtEhiosbe2CBfBDKXBCH9vM3hzUs
    [18.202.251.235]: “<!doctype html><html
    lang=“en”>HTTP Status 404 – Not Found<style
    type=“text/css”>h1 {font-family:Tahoma,A”

    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): Apache tomcat 9

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

My hosting provider, if applicable, is: AWS (EC2 instance)

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 0.31.0

1 Like

Have you made any changes to the document root?
Does it match the contents of the renewal.conf file?

1 Like

The document root in my tomcat wasn’t changed.
But maybe because I’ve ran --standalone option (which starting its own nginx server) the document root is different between tomcat and nginx…

If by renewal.conf you mean the file /etc/letsencrypt/renwal/buxsee.com.conf then the content of it:

# renew_before_expiry = 30 days
version = 0.31.0
archive_dir = /etc/letsencrypt/archive/buxsee.com
cert = /etc/letsencrypt/live/buxsee.com/cert.pem
privkey = /etc/letsencrypt/live/buxsee.com/privkey.pem
chain = /etc/letsencrypt/live/buxsee.com/chain.pem
fullchain = /etc/letsencrypt/live/buxsee.com/fullchain.pem

# Options used in the renewal process
[renewalparams]
account = ...
authenticator = standalone
server = https://acme-v02.api.letsencrypt.org/directory 

I see that the authenticator option is set to standalone, maybe it’s trying to access certbot’s nginx server?

1 Like

In order for standalone to work, the existing web server (on port 80) must be stopped first.
That was either done manually prior to the last renewal attempt or scripted within certbot.
If you don’t recall, you can check within the folder:
/etc/letsencrypt/renewal-hooks/pre/

1 Like

I’ve tried to stop my tomcat server and run the command again, and it still fails, this time with this message:
Attempting to renew cert (buxsee.com) from /etc/letsencrypt/renewal/buxsee.com.conf produced an unexpected error: Failed authorization procedure. buxsee.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://buxsee.com/.well-known/acme-challenge/9AO6DZ5KfLDdgOzIOZID_NWnM8qxy2tE-aQyxu3jgsw: Connection refused. Skipping. All renewal attempts failed. The following certs could not be renewed: /etc/letsencrypt/live/buxsee.com/fullchain.pem (failure).

I’ve checked the directory /etc/letsencrypt/renewal-hooks/pre/ and it’s empty… as well as post + deploy folders…

1 Like

Perhaps your server is running multiple web servers.
You need to stop the one that is using port 80.

1 Like

The only server that i am running is the tomcat, and it was stopped.

Does the command sudo certbot renew --dry-run running it’s own server? Or maybe i need to run some other command before that?

1 Like

Well, I would double check that with:
netstat -pant | grep -i listen | grep 80
[While the server is stopped and also while it is running - to compare]

1 Like

When running:

tcp6       0      0 :::8090                 :::*                    LISTEN      -
tcp6       0      0 127.0.0.1:8005          :::*                    LISTEN      -
tcp6       0      0 :::8009                 :::*                    LISTEN      -

When stopped:

tcp6       0      0 :::8090                 :::*                    LISTEN      -

Might be that the 8090 server somehow preventing it? (It is a Jenkins server if it helps)
Because when i run the install command, i didn’t turned off the Jenkins server…

1 Like

8090 won’t interfere with 80.
There must be something missing…
Let’s broaden the search:
netstat -pant | grep -i listen

or
Maybe I’m missing something…

Please show the renewal conf file.

1 Like

Tomcat server On:

tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      -
tcp6       0      0 :::8080                 :::*                    LISTEN      -
tcp6       0      0 :::22                   :::*                    LISTEN      -
tcp6       0      0 :::8090                 :::*                    LISTEN      -
tcp6       0      0 :::8443                 :::*                    LISTEN      -
tcp6       0      0 127.0.0.1:8005          :::*                    LISTEN      -
tcp6       0      0 :::8009                 :::*                    LISTEN      -

Tomcat Server Off:

tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      -
tcp6       0      0 :::22                   :::*                    LISTEN      -
tcp6       0      0 :::8090                 :::*                    LISTEN      -

EDIT:
1 more thing - I do have a forwarding from port 80 to 8080, so I’ve tried to remove this redirection, stopped the server and ran the dry run again - still the same error.

You need to forward 80 to 80.

1 Like

Well, I’ve tried to remove the port forwarding once again, and this time it worked!

Why it didn’t worked previous time?
Because when you add/remove port forwarding at an AWS EC2 instance, it doesn’t affect immediately - you have to wait some time and only then the port forwarding added or removed…

Thanks for the help!!

1 Like

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