Certificate expired and validation fails

Help
1

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. https://crt.sh/?q=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: pretalx.charmedhypno.org

I ran this command: certbot --nginx

It produced this output:

root@instance-1:/etc/nginx/sites-available# certbot --nginx
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx

Which names would you like to activate HTTPS for?

1: pretalx.charmedhypno.org

Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter ‘c’ to cancel):
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for pretalx.charmedhypno.org
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. pretalx.charmedhypno.org (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://pretalx.charmedhypno.org/.well-known/acme-challenge/P3d9SUdRUPxS_8utzgMzct3qgRL0nbB9b7FBqQjzEZA: Timeout during connect (likely firewall problem)

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: pretalx.charmedhypno.org
    Type: connection
    Detail: Fetching
    http://pretalx.charmedhypno.org/.well-known/acme-challenge/P3d9SUdRUPxS_8utzgMzct3qgRL0nbB9b7FBqQjzEZA:
    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):

NGINX v1.14.0 (Ubuntu)

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

Ubuntu 18.04

My hosting provider, if applicable, is:

This is a VM instance running on Google Cloud

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): 0.31.0

The certificate has been working for 6 months, meaning one successful renewal, but it didn’t auto-renew this time and it expired today. It reads like it can’t get to port 80, but port 80 is open (and redirected) just as it has always been. Nobody futzes with this server – I had to look up my login credentials it’s been so long. What gives?

2

The validations are now over port 80.
But port 80 appears to be closed.

Furthermore, it seems that port 443 is serving clear-text HTTP content.

3

It not closed, but the only thing on it is a redirect to 443. It never did anything on 80.

Did something change in the validator??

4

Perhaps, at some point HTTPS validations became "insecure" and is no longer allowed.
[natively - there is an ALPN validation that uses port 443 - but that is not in use here]

You need to forward 443 to 443 and 80 to 80.
[not 80 to 443 - nor 443 to 80]

5

For me, trying to connect to port 80 times out, and trying to connect to port 443 results in a "connection refused" error. It appears that port 80 is likely blocked by a firewall.

1 Like
6

It’s not firewall. Firewall is open on 80 and 443.

root@instance-1:/etc/nginx/sites-enabled# ufw status
Status: active

To Action From

22/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere
443/tcp ALLOW Anywhere
22/tcp (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)
443/tcp (v6) ALLOW Anywhere (v6)

It’s allowed in GCP, too, just as it’s always been.

I tried deleting the SSL configuration entirely, but it doesn’t work with the default site on 80 either. Same error, that nothing is listening.

7

This confuses me. I want all traffic on 443; 80 only exists for redirect purposes. That’s how it’s been since the site went up in February 2019. The only difference is that now validation fails, where it succeeded before. That really point to the validator having changed, I’ll guess because it is no longer allowed. What is the ALPN validator, and how do I try that?

8

Okay, I found a workaround.

By using ‘certbot certonly --manual --preferred-challenges dns’ I was able to get the cert renewed. So now the question is simply how to get auto renew working again. I really don’t want to have to keep doing it manually.

1 Like
9

You should figure out why port 80 is not working.

ufw thinks inbound traffic to port 80 is allowed.

Is it correct?

Are the outbound reply packets allowed?

Are the Google Cloud firewall rules blocking it?

Is the IP address correct?

Is there a strange technical problem with the network?

3 Likes
10

[repeating]

1 Like
11

I guess so. It used to work, but now it definitely doesn’t. I’ll have to dig into the nginx config to figure that one out. I’ve got 60 days to crack that one, I guess.

Thanks everyone.

2 Likes
12

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