Timeout - ../well-known/acme-challenge/

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:
simply.ca

I ran this command:
sudo -H /opt/letsencrypt/certbot-auto certonly --standalone -m hdadmin@simply.ca -d jamfpro.simply.ca --agree-tos

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for jamfpro.simply.ca
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. jamfpro.simply.ca (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://jamfpro.simply.ca/.well-known/acme-challenge/KmZxwP5NJHaROBkM2nPqtwJQ1aDYxcGOiKeWj2vrkio: Timeout during connect (likely firewall problem)

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: jamfpro.simply.ca
    Type: connection
    Detail: Fetching
    http://jamfpro.simply.ca/.well-known/acme-challenge/KmZxwP5NJHaROBkM2nPqtwJQ1aDYxcGOiKeWj2vrkio:
    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): Tomcat

The operating system my web server runs on is (include version):
Ubuntu
My hosting provider, if applicable, is:
AWS
I can login to a root shell on my machine (yes or no, or I don’t know):
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): No

I am getting this error and I am not to sure what to do.
This is my first time working with Let’sEncrypt and I apprechiate any sort of help or support!!
Thank you!

Hi @Theresia

your webserver blocks the connection (via https://check-your-website.server-daten.de/?q=jamfpro.simply.ca ):

Domainname Http-Status redirect Sec. G
• http://jamfpro.simply.ca/
34.208.3.77 -14 10.026 T
Timeout - The operation has timed out
• https://jamfpro.simply.ca/
34.208.3.77 -2 1.536 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it 34.208.3.77:443
• http://jamfpro.simply.ca/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
34.208.3.77 -14 10.026 T
Timeout - The operation has timed out

If you want to use http 01 - validation, Certbot creates a file in /.well-known/acme-challenge, so checking a file there must be possible. But there is a timeout.

Is port 80 / http active? Is there a firewall?

OP seems to be running their web software over 8080/8443 (which are the default Tomcat bind ports).

Two things you likely need to do:

  • Adjust your EC2 security group to allow 80 and 443 (though 443 seems to be already permitted)
  • Either:
    • Make sure connections to 80/443 are forwarded transparently through to 8080/8443, e.g. using iptables or
    • Change your Tomcat configuration to listen on 80/443 (but you may need to use setcap or authbind to do this as non-root)
1 Like

Hello and thanks to both of you! Unfortunately, I still wasn’t able to renew the certificate.

First of all, before I run the first time, I disabled the following firewall rules temporarily:
-A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8443
-A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
And I got the output as mentioned previously.

I also checked the firewall rules from EC2, both of the ports are open.

After checking everything I enabled the firewall rules and I got the following output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for jamfpro.simply.ca
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. jamfpro.simply.ca (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://jamfpro.simply.ca:8443/.well-known/acme-challenge/JXBv1ydRcZ1R0-ZhxiqOqeCTDHzfdFA42mnTktgOz14: Invalid port in redirect target. Only ports 80 and 443 are supported, not 8443

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: jamfpro.simply.ca
    Type: connection
    Detail: Fetching
    https://jamfpro.simply.ca:8443/.well-known/acme-challenge/JXBv1ydRcZ1R0-ZhxiqOqeCTDHzfdFA42mnTktgOz14:
    Invalid port in redirect target. Only ports 80 and 443 are
    supported, not 8443

    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.

Well, you fixed half the problem - port 80 is now properly routed through your security group. So that’s good.

Your current issue is a new one, and that has to do with Tomcat using 8080/8443 as its main ports. That’s not a port redirect that Let’s Encrypt is willing to follow.

What you do next depends what you want to do.

  • Do you want to keep your Tomcat application on port 8080/8443?
    • In this case, undo the PREROUTING changes, and just run Certbot in standalone mode.
  • Or do you want your Tomcat application to use ports 80/443 (so you don’t need to input the port to your browser?)
    • In this case, you need to reconfigure your server.xml/web.xml to reflect this.

Hello _az,

Yes, I would liket ot keep it on 8080/8443.
I’ve done what you suggested - disabled the PREROUTING and run Certbot in standalone mode, but unfortunately I still get the following message:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for jamfpro.simply.ca
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. jamfpro.simply.ca (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://jamfpro.simply.ca/.well-known/acme-challenge/kyVniUdNJ1dLiha_3EqzQ5nze08D-IVYuew-P-GhHaY: Timeout during connect (likely firewall problem)

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: jamfpro.simply.ca
    Type: connection
    Detail: Fetching
    http://jamfpro.simply.ca/.well-known/acme-challenge/kyVniUdNJ1dLiha_3EqzQ5nze08D-IVYuew-P-GhHaY:
    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.

Is there anything else I can do to solve this?

Are you sure you have an iptables rule to permit port 80?

Maybe the PREROUTING forwarding rule acted implicitly to permit traffic to 80, and when you get rid of it, it goes back to being dropped.

Hey _az,

I looked up the iptable and indeed it was port 80!
I would have never thought that while the error came from 443.

Thank you for your help - you made my day! :slight_smile:

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