Let's Encrypt SSL Installtion Problem


#1

Hello,

Recently we have the strange issue while installing the Let’s Encrypt SSL on the server I am getting below error message.

Check the below snapshot for the same.

--------------------++


--------------------++

Also while doing self test from the server end I am getting the below error message.

---------------------------------------------+++
[root@strong ~]# le-cp self-test
[SELF-TEST] Has valid licence … SUCCESS.
[SELF-TEST] Can read config … SUCCESS.
[SELF-TEST] Can connect to Let’s Encrypt …

FAILED: acme: error fetching response: Get https://acme-v02.api.letsencrypt.org/directory: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers).
[SELF-TEST] Can talk to WHM API … SUCCESS.
[SELF-TEST] Can talk to plugin RPC … SUCCESS.

The self-test failed. You should fix the above issues before continuing, or contact support @ https://cpanel.fleetssl.com/contact

Please first run the following command, which will send us your log files and configuration details:
le-cp send-logs

FATA[0060] Self-test failed
[root@strong ~]#
---------------------------------------------+++

So for the same, I have checked this problem with our network team but they are saying issue, not from there end. Also, I have contacted letsencrypt-for-cpanel.com support but they are saying the issue with network end they are not blocking any request. And letsencrypt-for-cpanel.com asked me to do some test from the server end below are the result please have a look into that.

---------------------------------------------+++
[root@strong ~]# curl -X GET -I -m 10 -4 https://acme-v02.api.letsencrypt.org/directory
HTTP/1.1 200 OK
Server: nginx
Content-Type: application/json
Content-Length: 658
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800
Expires: Fri, 18 Jan 2019 15:43:06 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Fri, 18 Jan 2019 15:43:06 GMT
Connection: keep-alive
---------------------------------------------+++

---------------------------------------------+++
[root@strong ~]# curl -X GET -I -m 10 -6 https://acme-v02.api.letsencrypt.org/directory
curl: (7) Failed connect to acme-v02.api.letsencrypt.org:443; Operation now in progress
---------------------------------------------+++

---------------------------------------------+++
[root@strong ~]# curl -X GET -I -m 10 -6 https://google.com
curl: (28) Connection timed out after 10001 milliseconds
[root@strong ~]#
---------------------------------------------+++

While doing the test I have noticed I am getting the Connection timed so for the same I contacted our NOC team and I have got the reply from them is they checked through global route server and they are not observing packet loss while pinging

---------------------------------------------+++
route-server.ams2>ping ipv6
Target IPv6 address: 2401:7500:fff2:1:92b1:1cff:fe57:8637
Repeat count [5]: 500
Datagram size [100]:
Timeout in seconds [2]:
Extended commands? [no]:
Type escape sequence to abort.
Sending 500, 100-byte ICMP Echos to 2401:7500:FFF2:1:92B1:1CFF:FE57:8637, timeout is 2 seconds:
!!!
!!!
!!!
!!!
!!!
!!!
!!!
!!!
Success rate is 100 percent (500/500), round-trip min/avg/max = 76/80/120 ms
---------------------------------------------+++

Can anyone suggest me what is the exact problem how we can fix this issue?

Looking forward to your reply.


#2

Hi,

I’m not sure what’s the exact problem, but I have one question:

Do you have IPV6 connection on your server?
If you do, why curl -6 showed timeout?
(If you do have IPV6, curl probably tried to connect to the IPV6 version of letsencrypt API, which ends up in timeout state)

Thank you


#3

Hello Stevenzhu,

Thanks for your reply.

Yes, we have IPV6 connection on the server that is why I cross check this problem with server network team but they are also saying issue not from there end.


#4

Hi,

Could you please run the below command and share the outputs?
traceroute6 acme-v02.api.letsencrypt.org
ping -6 acme-v02.api.letsencrypt.org
curl -6 acme-v02.api.letsencrypt.org

Thank you


#5

Hello Stevenzhu,

The issue has been fixed.

Below are steps that we performed

This shell script forces acme-v02.api.letsencrypt.org to resolve via IPv4 on servers with IPv6 interfaces that are enabled but dysfunctional in any number of ways.

It works by updating an entry in the server’s /etc/hosts file on a schedule, to the latest IPv4 address found for that domain. This is necessary because the IP address rotates regularly.

Download script

wget -O /usr/local/sbin/letsencrypt-no-ipv6-hosts-cron.sh “https://raw.githubusercontent.com/letsdebug/letsencrypt-no-ipv6-hosts-cron/master/letsencrypt-no-ipv6-hosts-cron.sh
chmod 0700 /usr/local/sbin/letsencrypt-no-ipv6-hosts-cron.sh

Install cron task echo ‘0 * * * * root /usr/local/sbin/letsencrypt-no-ipv6-hosts-cron.sh’ > /etc/cron.d/letsencrypt-no-ipv6-hosts-cron chmod 0600 /etc/cron.d/letsencrypt-no-ipv6-hosts-cron


#6

If you can ping one IPv6 address but can’t access Let’s Encrypt (using a popular CDN) or Google using HTTPS, it sounds like you have serious problems with your Internet connection. You should fix them, not just work around the problem by disabling IPv6 in one application.

Maybe there are MTU issues?


#7

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