Suddenly Timeout during connect (likely firewall problem) for www subdomain

Same issue over here. Identical environment: IONOS, Plesk Obsidian, SSL It! extension, spanish client and partially renewed certificate (main domain renewed and www subdomain failed).

It's not a final solution, but I finally found a partial one to get the renewal while this issue is completely solved. From Plesk panel:

  1. Go to the subscription.
  2. SSL/TLS Certificates.
  3. Deactivate the "Redirect from http to https" option.
  4. Reissue the certificate.
  5. Activate the http to https redirect.

Redirect

1 Like

Thank's for your message FEJIDIF, but don't work for me :sob:

1 Like

Hi FEJIDIF,

I'm doing the same process since the last thursday but in my case it doesn't work always. :no_mouth:

Hi mserra and Wolfix,

mserra: oh, I'm sorry to read that :cry:.

Wolfix: I have only had one server with this issue. Maybe, the partial solution does not always work and I've been so lucky.

I think you are right FEJIDIF.

Sometimes work (1% as I tested) and sometimes not (99%). See this message: Suddenly Timeout during connect (likely firewall problem) for www subdomain - #6 by mserra

after a few retries work, but it is easier to reach some of the let's encrypt renewal limits instead of it being renewed correctly.

Yeah, you are probably right.

From IONOS they have redirected me to this Plesk post which I found yesterday while browsing, but it has not been useful for me.

On my call, their official speech is they are aware of this issue, that they think it's a Plesk issue and they are investigating it, but my server is not IONOS managed :face_with_raised_eyebrow:.

1 Like

FEJIDIF, we are exactly at the same point, but ... I just received another IONOS reply redirecting me to this plesk post.

And seem that work's!!!

It's important to make the two steps...

  1. Remove .well-known directory.
  2. Temporary disable the option Permanent SEO-safe 301 redirect from HTTP to HTTPS
  3. Disable custom redirect rules

I think the step 3 (Disable custom redirect rules) is the reason why sometimes (or some domains) the cert renew works only with the step 2 (what you write before).

My .httaccess file (auto generated by prestashop in this example)...

# ~~start~~ Do not remove this comment, Prestashop will keep automatically the code outside this comment when .htaccess will be generated again
# .htaccess automaticaly generated by PrestaShop e-commerce open-source solution
# http://www.prestashop.com - http://www.prestashop.com/forums

<IfModule mod_rewrite.c>
<IfModule mod_env.c>
SetEnv HTTP_MOD_REWRITE On
</IfModule>

RewriteEngine on


#Domain: 2021.manxaindustrial.com
RewriteRule . - [E=REWRITEBASE:/]
RewriteRule ^api(?:/(.*))?$ %{ENV:REWRITEBASE}webservice/dispatcher.php?url=$1 [QSA,L]

# AlphaImageLoader for IE and fancybox
RewriteRule ^images_ie/?([^/]+)\.(jpe?g|png|gif)$ js/jquery/plugins/fancybox/images/$1.$2 [L]
</IfModule>

AddType application/vnd.ms-fontobject .eot
AddType font/ttf .ttf
AddType font/otf .otf
AddType application/font-woff .woff
AddType font/woff2 .woff2
<IfModule mod_headers.c>
	<FilesMatch "\.(ttf|ttc|otf|eot|woff|woff2|svg)$">
		Header set Access-Control-Allow-Origin "*"
	</FilesMatch>

    <FilesMatch "\.pdf$">
      Header set Content-Disposition "Attachment"
      Header set X-Content-Type-Options "nosniff"
    </FilesMatch>
</IfModule>

<Files composer.lock>
    # Apache 2.2
    <IfModule !mod_authz_core.c>
        Order deny,allow
        Deny from all
    </IfModule>

    # Apache 2.4
    <IfModule mod_authz_core.c>
        Require all denied
    </IfModule>
</Files>
#If rewrite mod isn't enabled
ErrorDocument 404 /index.php?controller=404

# ~~end~~ Do not remove this comment, Prestashop will keep automatically the code outside this comment when .htaccess will be generated again

I don't see nothing strange o related to let's encrypt well-know folder.

2 Likes

I can confirm this temporary solution works for all of my affected domains.

I write temporary because I hope plesk solve this problem as soon as possible. If you have a large number of domains (my case) you waste a lot of time.

3 Likes

@Wolfix @FEJIDIF @pepelucai and all affected users, I think will be a good idea to made pressure to plesk developers here: https://support.plesk.com/hc/en-us/articles/115004728413-Unable-to-issue-a-Let-s-Encr[…]le-is-either-unreadable-or-does-not-have-the-read-permission

Can you write a comment there please?

3 Likes

@mserra thank you very much for your update. It is highly appreciated.

My comment is done.

3 Likes

Hi mserra,

I didn't have luck with that procedure.

In my case, in "windows 2016 server > IIS > rewrite rules" I have a rule related to let's encrypt:

I tested the procedure in both cases (rule enabled and disabled) without luck. I don't have redirect rules in the web.config of the tested domains.

@Wolfix I am not familiar with plesk in windows.

Plesk uses apache or IIS on in windows? If use IIS I can't help you. Sorry.

Exactly the same issue with my client. They are using Arsys hosting too -- www subdomain not working etc.

Thank you @mserra !!!

Plesk use IIS in windows.

I'm waiting news from Arsys. They told me during the morning that the problem is in a external provider and they are talking in order to resolve it.

1 Like

@mserra @FEJIDIF @pepelucai @richpeck @9peppe @MikeMcQ @rg305

Does anyone have any news?

Arsys (IONOS)(1&1) say that there is a problem in the security provider of Let's Encrypt (CloudFlare) and that they need check their services in order to fix it. Maybe something is blocking the return traffic from our ISP.

:face_with_peeking_eye:

They told me that they sent this problem to Let's Encrypt and they suggested that I should do the same.

I have no clue, and they have no clue.

If the problem were with cloudflare, the problem would be a lot bigger and the forum a lot noisier.

1 Like

I'm waiting for my client to provide their hosting account info then I will provide any information I glean from it.

This forum is first line support for LE but your vendor did not report any details here.

5 Likes

@9peppe @MikeMcQ thank you for your support.

I asked my ISP and they told me that they sent an email with the problem to security@letsencrypt.org. I read on the contact page that the issues must be exposed on this forum but they sent an email to that mailbox. :sweat:

1 Like

I would like expose our case in order to find some light at the final of the tunnel. :slightly_smiling_face:

We have 8 servers with Windows Server 2016 + Plesk 18.0.43 + Lets Encrypt 3.0.0-785 and we are having the same issue in all servers since the same day. The last week we had 102 domains with the same problem.

This problem happen with new or renewed certs. We can cert the "raw" domain but we have problems with the "www.". This problem not happens always (it's random). If you try it 4 times maybe you can issue the cert at first try or maybe in other try but sometimes it's impossible and we stop retries in order to don't reach the limits (5 times a week).

We tried to renew certs with the "redirect http to https" option disabled, deleting ".well-known" folder, etc but without luck.


This is an example: marcosanache.es
Server ip: 82.223.1.108
Software: Windows Server 2016 + Plesk 18.0.43 + Lets Encrypt 3.0.0-785
ISP: Arsys (IONOS)(1&1)
Location: Spain

Error: Timeout during connect (likely firewall problem)
Invalid response: https://acme-v02.api.letsencrypt.org/acme/authz-v3/104265492297
Fetching url: http://www.marcosanache.es/.well-known/acme-challenge/aGG7lPdqHhM3UyS1uqXEx9jPrEqpFfNzdETdqt93rO0

When we have this issue, we always can access to the problematic urls (from inside and outside of the server) immediately and without any problem.. Also, we tested the urls with a webpage that test access of the urls from different countries: https://geopeeker.com/fetch/?url=http%3A%2F%2Fwww.marcosanache.es%2F.well-known%2Facme-challenge%2FaGG7lPdqHhM3UyS1uqXEx9jPrEqpFfNzdETdqt93rO0&csrf_token=mLnF3pPPxAfGVWfsh4vp9HKx2jOEacfMJzZOVtfUn4U%3D

capturassl

The Let's debug test seems to be ok: Let's Debug


Some tests from the server (82.223.1.108):

ping acme-v02.api.letsencrypt.org

Haciendo ping a ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com [172.65.32.248] con 32 bytes de datos:
Respuesta desde 172.65.32.248: bytes=32 tiempo=7ms TTL=59
Respuesta desde 172.65.32.248: bytes=32 tiempo=7ms TTL=59
Respuesta desde 172.65.32.248: bytes=32 tiempo=7ms TTL=59
Respuesta desde 172.65.32.248: bytes=32 tiempo=7ms TTL=59

Estadisticas de ping para 172.65.32.248:
    Paquetes: enviados = 4, recibidos = 4, perdidos = 0
    (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Minimo = 7ms, M ximo = 7ms, Media = 7ms

tracert acme-v02.api.letsencrypt.org

Traza a la direccion ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com [172.65.32.248]
sobre un m ximo de 30 saltos:

  1    <1 ms    <1 ms    <1 ms  10.255.255.2 
  2     1 ms     1 ms     1 ms  82.223.41.10 
  3     6 ms     8 ms     6 ms  ae-6.bb-b.epx.mad.es.net.ionos.com [212.227.121.105] 
  4     8 ms     7 ms     8 ms  ae-8.bb-a.mad2.mad.es.oneandone.net [212.227.120.7] 
  5    18 ms    16 ms    15 ms  cloudflare.alta.espanix.net [185.79.175.179] 
  6     7 ms     8 ms    13 ms  172.70.60.2 
  7     7 ms     7 ms     7 ms  172.65.32.248 

Traza completa.

tracetcp acme-v02.api.letsencrypt.org:443 (6 attempts in a row)

Tracing route to 172.65.32.248 on port 443
Over a maximum of 30 hops.
1	1 ms	0 ms	0 ms	10.255.255.2	
2	2 ms	1 ms	3 ms	82.223.41.10	
3	10 ms	9 ms	7 ms	212.227.121.105	[ae-6.bb-b.epx.mad.es.net.ionos.com]
4	9 ms	8 ms	9 ms	212.227.120.7	[ae-8.bb-a.mad2.mad.es.oneandone.net]
5	10 ms	12 ms	9 ms	172.70.60.2	
6	Destination Reached in 9 ms. Connection established to 172.65.32.248
Trace Complete.

Tracing route to 172.65.32.248 on port 443
Over a maximum of 30 hops.
1	1 ms	2 ms	2 ms	10.255.255.2	
2	1 ms	1 ms	2 ms	82.223.41.9	
3	8 ms	9 ms	9 ms	212.227.121.137	[ae-6.bb-a.mad2.mad.es.net.ionos.com]
4	8 ms	35 ms	9 ms	185.79.175.179	[cloudflare.alta.espanix.net]
5	11 ms	9 ms	9 ms	185.79.175.179	[cloudflare.alta.espanix.net]
6	9 ms	Destination Reached in 8 ms. Connection established to 172.65.32.248
Trace Complete.

Tracing route to 172.65.32.248 on port 443
Over a maximum of 30 hops.
1	2 ms	0 ms	0 ms	10.255.255.2	
2	2 ms	1 ms	1 ms	82.223.41.10	
3	9 ms	7 ms	9 ms	212.227.121.105	[ae-6.bb-b.epx.mad.es.net.ionos.com]
4	17 ms	8 ms	10 ms	185.79.175.179	[cloudflare.alta.espanix.net]
5	10 ms	9 ms	33 ms	188.114.108.7	
6	9 ms	Destination Reached in 10 ms. Connection established to 172.65.32.248
Trace Complete.

Tracing route to 172.65.32.248 on port 443
Over a maximum of 30 hops.
1	2 ms	2 ms	2 ms	10.255.255.2	
2	2 ms	2 ms	2 ms	82.223.41.10	
3	9 ms	7 ms	10 ms	212.227.121.137	[ae-6.bb-a.mad2.mad.es.net.ionos.com]
4	10 ms	8 ms	8 ms	212.227.120.7	[ae-8.bb-a.mad2.mad.es.oneandone.net]
5	10 ms	9 ms	8 ms	185.79.175.179	[cloudflare.alta.espanix.net]
6	Destination Reached in 10 ms. Connection established to 172.65.32.248
Trace Complete.

Tracing route to 172.65.32.248 on port 443
Over a maximum of 30 hops.
1	1 ms	0 ms	1 ms	10.255.255.2	
2	1 ms	1 ms	1 ms	82.223.41.10	
3	8 ms	8 ms	9 ms	212.227.121.105	[ae-6.bb-b.epx.mad.es.net.ionos.com]
4	10 ms	9 ms	9 ms	185.79.175.179	[cloudflare.alta.espanix.net]
5	10 ms	20 ms	10 ms	185.79.175.179	[cloudflare.alta.espanix.net]
6	Destination Reached in 10 ms. Connection established to 172.65.32.248
Trace Complete.

Tracing route to 172.65.32.248 on port 443
Over a maximum of 30 hops.
1	1 ms	1 ms	2 ms	10.255.255.2	
2	1 ms	3 ms	1 ms	82.223.41.9	
3	7 ms	9 ms	8 ms	212.227.121.105	[ae-6.bb-b.epx.mad.es.net.ionos.com]
4	10 ms	9 ms	8 ms	212.227.120.7	[ae-8.bb-a.mad2.mad.es.oneandone.net]
5	14 ms	10 ms	11 ms	172.70.58.2	
6	12 ms	Destination Reached in 9 ms. Connection established to 172.65.32.248
Trace Complete.

Thank you in advance!