Failed to issue certificate

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: monitor.packetfilters.net

I ran this command: certbot certonly --manual --preferred-challenges http -d monitor.packetfilters.net

It produced this output: Failed authorization procedure. monitor.packetfilters.net (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://monitor.packetfilters.net/.well-known/acme-challenge/ETXrnCEGPMtt6ZpWkwMFcuQ6o44kf1XtOILFQArs3I4: Timeout during connect (likely firewall problem)

My web server is (include version): Apache/2.4.7

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

My hosting provider, if applicable, is:

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): 0.28.0

dig @8.8.8.8 monitor.packetfilters.net

; <<>> DiG 9.9.5-3ubuntu0.18-Ubuntu <<>> @8.8.8.8 monitor.packetfilters.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39916
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;monitor.packetfilters.net. IN A

;; ANSWER SECTION:
monitor.packetfilters.net. 11117 IN A 146.196.88.3

;; Query time: 15 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Feb 01 15:48:17 HKT 2019
;; MSG SIZE rcvd: 70

curl http://monitor.packetfilters.net/.well-known/acme-challenge/ETXrnCEGPMtt6ZpWkwMFcuQ6o44kf1XtOILFQArs3I4
ETXrnCEGPMtt6ZpWkwMFcuQ6o44kf1XtOILFQArs3I4.jo7CLeOmeYsRu8WMlTyc3ZUocXXQ1eBPhkdsS4UMad8

port 80 is opened and i can do curl to retrieve the file from internet, however, timeout still occurred and failed to authenticate my server, what could be wrong?

2

It seems likely that your server (or some firewall in front of it) has blocked the Let's Encrypt validation servers.

Do you have anything like that, such as Apache fail2ban plugins, CSF, that kind of thing?

3

there’s no firewall in front of this server and the server itself does not block any packet

the plugins stated also not enable in this web server

[root@ntc-do-sf-1 tmp]# nc -zv -w5 monitor.packetfilters.net 80
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 146.196.88.3:80.
Ncat: 0 bytes sent, 0 bytes received in 0.38 seconds.

4

Hi @kennethlui

there is something blocking your website ( https://check-your-website.server-daten.de/?q=monitor.packetfilters.net ):

Domainname Http-Status redirect Sec. G
• http://monitor.packetfilters.net/
146.196.88.3 -14 10.030 T
Timeout - The operation has timed out
• https://monitor.packetfilters.net/
146.196.88.3 -14 10.030 T
Timeout - The operation has timed out
• http://monitor.packetfilters.net/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
146.196.88.3 -14 10.030 T
Timeout - The operation has timed out

Your site is completely invisible.

If you can't change that, you have to use dns-01 - validation, then you don't need an open port 80 to start.

But now, your port 80 is dead (same with your port 443, but this isn't so important).

5

it’s very strange, i don’t encounter such issue when i make the connection to my server from digital ocean and godaddy vps

6

For what it’s worth, the site works for me just fine from a few locations - e.g. https://letsdebug.net/monitor.packetfilters.net/20508?debug=y shows that it’s accessible from the letsdebug test, but not from Let’s Encrypt staging.

The fact that it is only partially unavailable (depending on location) is pretty compelling to suggest that it is a firewalling issue.

7

thanks guy for helping me in this issue, i’m quite sure there’s routing issue on my upstream, which leads to the failure in authentication

8

Curious. check-your-website ... is located in Berlin, Germany, rechecked your test - version with

net
net667×837 56 KB

there is a lot of red.

And Letsencrypt plans to add multiple checks from different locations:

The feature we’re most excited about is multi-perspective validation. Currently, when a subscriber requests a certificate, we validate domain control from a single network perspective. This is standard practice for CAs. If an attacker along the network path for the validation check can interfere with traffic they can potentially cause certificates to be issued that should not be issued. We’re most concerned about this happening via BGP hijacking, and since BGP is not going to be secured any time soon, we needed to find another mitigation. The solution we intend to deploy in 2019 is multi-perspective validation, in which we will check from multiple network perspectives (distinct Autonomous Systems).

So in the future it's not enough to allow only US-traffic.

9

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