Trying to renew an expired certificate that failed to auto renew

Help
1

Hi my companies ssl cert failed to renew yesterday, and I have been trying to figure out what could be the issue. I have checked with the MSP that manages our firewall and they say they aren't seeing any blocks that could indicate a firewall issue.

My domain is: avmail.alliedvaughn.com

I ran this command: sudo certbot renew

It produced this output: Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/avmail.alliedvaughn.com.conf

Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for avmail.alliedvaughn.com
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Attempting to renew cert (avmail.alliedvaughn.com) from /etc/letsencrypt/renewal/avmail.alliedvaughn.com.conf produced an unexpected error: Failed authorization procedure. avmail.alliedvaughn.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: 207.67.108.132: Fetching http://avmail.alliedvaughn.com/.well-known/acme-challenge/OWr7YocTe8Vrdw74K538D2M85jXN175zgWKbhi6jN-k: Timeout during connect (likely firewall problem). Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/avmail.alliedvaughn.com/fullchain.pem (failure)

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/avmail.alliedvaughn.com/fullchain.pem (failure)

1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: avmail.alliedvaughn.com
    Type: connection
    Detail: 207.67.108.132: Fetching
    http://avmail.alliedvaughn.com/.well-known/acme-challenge/OWr7YocTe8Vrdw74K538D2M85jXN175zgWKbhi6jN-k:
    Timeout during connect (likely firewall problem)

    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. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you're using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.

My web server is (include version): Apache 2.4.29

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

My hosting provider, if applicable, is: Perrill

I can login to a root shell on my machine (yes or no, or I don't know): I can get in to the root user once I have ssh'd into the server

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.27.0

2

Hello @manny1, welcome to the Let's Encrypt community. :slightly_smiling_face:

Is very old, I suggest updating Certbot as a first step.

1 Like
3

Updating Certbot 0.27 is a very good idea. But, it won't solve your timeout problem.

This is almost certainly some sort of IP or maybe geographic based firewall. I cannot reach your site from various global locations from a test site I often use. (see here). Another diagnostic site in Germany I sometimes use also cannot reach your domain.

The problem can be reproduced with Let's Debug test site as well.

I know you said you checked but that's by far the most likely explanation.

4 Likes
4

I totally agree!

2 Likes
5

Hi sorry for the delay, I'll be updating certbot over the weekend to get it to its current release. We block a majority of countries and only allow certain IP's in from our clients, but would there be anything I would need to have the MSP that manages our firewall look for to signal a block on port 80? We have Palo Alto firewalls if that helps

1 Like
6

As for Palo Alto, you need to allow acme-protocol.

As for blocking countries, that can interfere with validation. If I were you, I'd look into dns-01 validation.

5 Likes
7

Hi, how would I go about having the acme-protocol allowed? I thought that it was allowed when I had the MSP check i thought I saw it but I may have been mistaken. I don't have access to our firewalls so I cant go take a look myself.

8

Certbot uses multiple remote vantage points for validation from different places in the world (AWS datacenters currently), so geo-blocking is not a good idea. The acme-protocol in the firewall should be allowed from anywhere in the world.

4 Likes
9

It seems like it was a mix of firewall issues, and the authenticator we were using. We were using webroot, and that kept failing we swapped to standalone and made sure the acme rule was above our rules that block countries and I was finally able to renew our ssl cert.
I appreciate everyone's time on this issue. Thank you vey much everyone

1 Like
10

--standalone requires stopping the running web service on port 80.
[unless you do some proxy tricks and run certbot on some other port]

Having to do so, is not ideal.
It seems that you may have used the wrong --webroot path OR your configuration isn't doing what you think it should.

Need I ask, Apache ?

I'd review your configuration, starting with:
apachectl -t -D DUMP_VHOSTS

3 Likes
11

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