ConnectionError: HTTPSConnectionPool(host=’acme-v02.api.letsencrypt.org’, port=443)

My domain is: www.tempatkerja.com, tempatkerja.com

I ran this command:

I migrated the server to new ip address, and upgrade from CentOS 7.7 to 8.1.1911. The domain is pointed to the new ip address.

sudo docker-compose up

docker-compose.yml from https://github.com/Verisage/docker-nginx-letsencrypt-odoo

It produced this output:

letsencrypt-nginx-proxy-companion | requests.exceptions.ConnectionError: HTTPSConnectionPool(host=‘acme-v02.api.letsencrypt.org’, port=443): Max retries exceeded with url: /directory (Caused by NewConnectionError(’<urllib3.connection.VerifiedHTTPSConnection object at 0x7fcd8f74a3a0>: Failed to establish a new connection: [Errno -3] Try again’))

My web server is (include version): nginx 1.17.0

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

My hosting provider, if applicable, is: Alibaba Cloud

I can login to a root shell on my machine (yes or no, or I don’t know): disabled.

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): not sure, i use this https://github.com/nginx-proxy/docker-letsencrypt-nginx-proxy-companion

This topic is similar to ConnectionError: HTTPSConnectionPool(host=’acme-v02.api.letsencrypt.org’, port=443)

However, what I don’t get it when I do:
dig acme-v02.api.letsencrypt.org

Output:

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> acme-v02.api.letsencrypt.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35678
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;acme-v02.api.letsencrypt.org.  IN      A

;; ANSWER SECTION:
acme-v02.api.letsencrypt.org. 7200 IN   CNAME   prod.api.letsencrypt.org.
prod.api.letsencrypt.org. 300   IN      CNAME   ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com.
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com. 300 IN A 172.65.32.248

;; Query time: 0 msec
;; SERVER: 100.100.2.136#53(100.100.2.136)
;; WHEN: Mon Apr 20 16:23:47 WIB 2020
;; MSG SIZE  rcvd: 144

I just got this exact same error and diagnostics on a newly provisioned droplet on Digital Ocean (Ubuntu 18.04.3 (LTS) x64). Also looking into it. Any help would be greatly appreciated.

dig acme-v02.api.letsencrypt.org

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> acme-v02.api.letsencrypt.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52773
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;acme-v02.api.letsencrypt.org.	IN	A

;; ANSWER SECTION:
acme-v02.api.letsencrypt.org. 6511 IN	CNAME	prod.api.letsencrypt.org.
prod.api.letsencrypt.org. 33	IN	CNAME	ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com.
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com. 32 IN A 172.65.32.248

;; Query time: 1 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Apr 20 10:08:49 UTC 2020
;; MSG SIZE  rcvd: 155

This is very strange if I run curl -v https://acme-v02.api.letsencrypt.org/directory I get

*   Trying 172.65.32.248...
* TCP_NODELAY set
*   Trying 2606:4700:60:0:f53d:5624:85c7:3a2c...
* TCP_NODELAY set
* Immediate connect fail for 2606:4700:60:0:f53d:5624:85c7:3a2c: Network is unreachable
*   Trying 2606:4700:60:0:f53d:5624:85c7:3a2c...
* TCP_NODELAY set
* Immediate connect fail for 2606:4700:60:0:f53d:5624:85c7:3a2c: Network is unreachable
*   Trying 2606:4700:60:0:f53d:5624:85c7:3a2c...
* TCP_NODELAY set
* Immediate connect fail for 2606:4700:60:0:f53d:5624:85c7:3a2c: Network is unreachable

Run it again I get another response

curl -v https://acme-v02.api.letsencrypt.org/directory
*   Trying 172.65.32.248...
* TCP_NODELAY set
* Connected to acme-v02.api.letsencrypt.org (172.65.32.248) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=acme-v01.api.letsencrypt.org
*  start date: Mar 12 02:20:25 2020 GMT
*  expire date: Jun 10 02:20:25 2020 GMT
*  subjectAltName: host "acme-v02.api.letsencrypt.org" matched cert's "acme-v02.api.letsencrypt.org"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55f0c49757c0)
> GET /directory HTTP/2
> Host: acme-v02.api.letsencrypt.org
> User-Agent: curl/7.58.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< server: nginx
< date: Mon, 20 Apr 2020 10:32:42 GMT
< content-type: application/json
< content-length: 658
< cache-control: public, max-age=0, no-cache
< x-frame-options: DENY
< strict-transport-security: max-age=604800
<
{
  "BXd84pi4Euk": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",
  "keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change",
  "meta": {
    "caaIdentities": [
      "letsencrypt.org"
    ],
    "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf",
    "website": "https://letsencrypt.org"
  },
  "newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct",
  "newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce",
  "newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order",
  "revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert"
* Connection #0 to host acme-v02.api.letsencrypt.org left intact

And again… It I get one of two responses above every other time.

Networking issue?

Hi @kidfromtheast

is this inside your docker?

Must be.

Same with

traceroute acme-v02.api.letsencrypt.org
ping -4 acme-v02.api.letsencrypt.org
ping -6 acme-v02.api.letsencrypt.org

I got it working. Turns out IPv6 was configured on my droplet after initial provisioning. And it needed some additional configuration for IPv6 network to work.

@kidfromtheast what is your response if you run ping6 2001:4860:4860::8888 (Ping google server using IPv6, make sure to use ping6).

Double check so that IPv6 is working on your server. Sorry for hijacking your thread :blush:

Hi,

Yes, it is. Here is the ping acme-v02.api.letsencrypt.org output:

PING ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com (172.65.32.248) 56(84) bytes of data.
64 bytes from 172.65.32.248 (172.65.32.248): icmp_seq=1 ttl=55 time=15.4 ms

I found out this is caused by firewalld interaction with docker / conflicting. I decided to ditch firewalld and use Alibaba Cloud Security Group Rules.

The current problem I have, unable to issue new certificate on different server.

letsencrypt-nginx-proxy-companion | 2020-04-20 12:39:02,029:ERROR:simp_le:1417: CA marked some of the authorizations as invalid, which likely means it could not access http://example.com/.well-known/acme-challenge/X. Did you set correct path in -d example.com:path or --default_root? Are all your domains accessible from the internet? Please check your domains' DNS entries, your host's network/firewall setup and your webserver config. If a domain's DNS entry has both A and AAAA fields set up, some CAs such as Let's Encrypt will perform the challenge validation over IPv6. If your DNS provider does not answer correctly to CAA records request, Let's Encrypt won't issue a certificate for your domain (see https://letsencrypt.org/docs/caa/). Failing authorizations: https://acme-v02.api.letsencrypt.org/acme/authz-v3/4073176478, https://acme-v02.api.letsencrypt.org/acme/authz-v3/4073176479

Sincerely,
Jason.

1 Like

There is a http status 503 reported. So your server doesn’t answer, that can’t work.

Hi.

No problem, it’s always welcomed for those contributing.

ping6 2001:4860:4860::8888
connect: Network is unreachable
1 Like

I will look for the solution.

Looks like you have the exact same issue/response that I did. My issue solved by configuring IPv6 properly on the server (both IP and gateway).

After this ping6 2001:4860:4860::8888 would resolve and I could request certificate as normal.

Please look into your IPv6 config once more maybe this can be the issue?

IPv6 is failing
IPv4 is working

Hi, I will look for the solution. Right now I can’t do IPv6, so it has to be something else.

I am confused since before this I never set up IPv6 before. Is there a recent update from Let’s Encrypt? that requires IPv6 to be configured [on Alibaba Cloud my instance do not have options for IPv6, I need to make new ECS to get IPv6]

This is the output from /etc/sysconfig/network-scripts/ifcfg-eth0:

# Created by cloud-init on instance boot automatically, do not edit.
# If you don't want cloud-init genrated automatically,you can disable it in /et$
# For more information, please refer to: https://help.aliyun.com/document_detai$
#
BOOTPROTO=dhcp
DEVICE=eth0
ONBOOT=yes
STARTMODE=auto
TYPE=Ethernet
USERCTL=no

I use IPv6 and I did not use AAAA for the DNS record:
www 14400 IN A
tempatkerja.com. 14400 IN A 147.139.178.181

LE has always had IPv4 and IPv6 addresses.

Then you need to disable IPv6 on your system.

That is for inbound direction.
Your IPv6 problem is outbound direction.

I disabled the IPv6 on my system
First, I make the config file.
nano /etc/sysctl.d/70-ipv6.conf

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Then, I load the config
sysctl --load /etc/sysctl.d/70-ipv6.conf
Then, I check using ip a, no output for inet6
ip a | grep inet6

But when I did the ACME challenge, I still get this.

letsencrypt-nginx-proxy-companion | 2020-04-20 22:47:35,716:ERROR:simp_le:1417: CA marked some of the authorizations as invalid, which likely means it could not access http://example.com/.well-known/acme-challenge/X. Did you set correct path in -d example.com:path or --default_root? Are all your domains accessible from the internet? Please check your domains' DNS entries, your host's network/firewall setup and your webserver config. If a domain's DNS entry has both A and AAAA fields set up, some CAs such as Let's Encrypt will perform the challenge validation over IPv6. If your DNS provider does not answer correctly to CAA records request, Let's Encrypt won't issue a certificate for your domain (see https://letsencrypt.org/docs/caa/). Failing authorizations: https://acme-v02.api.letsencrypt.org/acme/authz-v3/4081496975

Second time: Please read the result.

There is a http status 503 reported.

  "error": {
    "type": "urn:ietf:params:acme:error:unauthorized",
    "detail": "Invalid response from http://tempatkerja.com/.well-known/acme-challenge/RMh3or27M_VxQ4YLuSSCsp9Ewo5sDP5xmxRzcU5Ryr4 [147.139.178.181]: \"\u003chtml\u003e\\r\\n\u003chead\u003e\u003ctitle\u003e503 Service Temporarily Unavailable\u003c/title\u003e\u003c/head\u003e\\r\\n\u003cbody\u003e\\r\\n\u003ccenter\u003e\u003ch1\u003e503 Service Temporarily Unavailable\"",
    "status": 403

So Letsencrypt is able to connect your server, but your server doesn’t answer correct.

The error reporting of the ACME client you use is incomplete.

You don’t have a connection / ipv4/ipv6 - problem.

Hi,

I agree with your statement. I found out the issue is unrelated to Let’s Encrypt. I misconfigured my webapp.

Thank you for the help.

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