cURL error 35. Are our IPs blocked?

Help
1

Hello!

We are experiencing problems issuing certificates on two Plesk servers. Same error. Many users with this error found that their IP addresses were blocked by LE. Is it possible to check ours?

My domain is: elgift.pp.ua
I ran this command: Plesk LetsEncrypt plugin

It produced this output:

POST request to https://acme-v02.api.letsencrypt.org/acme/authz-v3/279255327316 failed: cURL error 35: OpenSSL SSL_connect: Connection was reset in connection to acme-v02.api.letsencrypt.org:443 (see libcurl - Error Codes) for https://acme-v02.api.letsencrypt.org/acme/authz-v3/279255327316

My web server is (include version): IIS 8.5.9600.16384 / IIS 10.0.20348.1.
The operating system my web server runs on is (include version): Windows Server 2012R2 / Windows Server 2022
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): Plesk Obsidian 18.0.56 Update #3

IP: 188.42.151.19, 188.42.151.10

The output of openssl s_client -connect acme-v02.api.letsencrypt.org:443:

Summary 
CONNECTED(00000138)
depth=1 C = US, O = Let's Encrypt, CN = R3
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = acme-v02.api.letsencrypt.org
verify return:1
---
Certificate chain
 0 s:CN = acme-v02.api.letsencrypt.org
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFwTCCBKmgAwIBAgISBMdF17klkZXq1Qev+QTZ8Q2IMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMzEwMjgxMjE1NTBaFw0yNDAxMjYxMjE1NDlaMCcxJTAjBgNVBAMT
HGFjbWUtdjAyLmFwaS5sZXRzZW5jcnlwdC5vcmcwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQC+4FnyuvJJmbnJRwXPHXv3akYgSjJhGO59AC3n/WCajnWO
oos1HlMFBitDJiS8dNoLXJOPb0QbQjfOn0ld4ItY+7vNlQnumIDmEPtBzuIVo5+y
6zp7U9GmP5F7O+V6QQwyn/eey6f2z1BxiiAmTlZqzfCWcdUGnQdEkEw3YfjDSi5p
pmfYV5KaPi4dJ3bqFm6ixN1UaLW/KlAWNwRGejWZr+tE+wGibdhgWyuNuCD0xPHp
fs01aAMzBYXJpjwlFJHEg1YJREg0U0B3YkLhKdUb6glFYFaaWlMQQ3r0ELgtlcgO
EWqJuMa4/Po3zIncdAYfEOKjU22Dx93BKDnahSZfAgMBAAGjggLaMIIC1jAOBgNV
HQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwGA1Ud
EwEB/wQCMAAwHQYDVR0OBBYEFA46BmeG8uuIOQ6rKbg9yLFvR9nKMB8GA1UdIwQY
MBaAFBQusxe3WFbLrlAJQOYfr52LFMLGMFUGCCsGAQUFBwEBBEkwRzAhBggrBgEF
BQcwAYYVaHR0cDovL3IzLm8ubGVuY3Iub3JnMCIGCCsGAQUFBzAChhZodHRwOi8v
cjMuaS5sZW5jci5vcmcvMIHjBgNVHREEgdswgdiCHmFjbWUtdjAyLTEuYXBpLmxl
dHNlbmNyeXB0Lm9yZ4IeYWNtZS12MDItMi5hcGkubGV0c2VuY3J5cHQub3Jngh5h
Y21lLXYwMi0zLmFwaS5sZXRzZW5jcnlwdC5vcmeCHmFjbWUtdjAyLTQuYXBpLmxl
dHNlbmNyeXB0Lm9yZ4IeYWNtZS12MDItNS5hcGkubGV0c2VuY3J5cHQub3Jnghxh
Y21lLXYwMi5hcGkubGV0c2VuY3J5cHQub3JnghhpbmNpZGVudC5sZXRzZW5jcnlw
dC5vcmcwEwYDVR0gBAwwCjAIBgZngQwBAgEwggEDBgorBgEEAdZ5AgQCBIH0BIHx
AO8AdgA7U3d1Pi25gE6LMFsG/kA7Z9hPw/THvQANLXJv4frUFwAAAYt2bTVdAAAE
AwBHMEUCIQCrJ6ALJJHWcZuYvbvWnvaFrnMRsBV5d+u5jaFuhjhO5wIgT/Jzeqim
XPlVKyShewfQSsoDAZs77jcyLLn093c4kWMAdQB2/4g/Crb7lVHCYcz1h7o0tKTN
uyncaEIKn+ZnTFo6dAAAAYt2bTWcAAAEAwBGMEQCIBbYkZoCUNnmYx/eNrIUuatV
+UMUs3dN6f9CW6G/626dAiBhXNr4X5Cj4Ew1wdFgKcpgoNj8dDCOYcaVgozxNB+e
UDANBgkqhkiG9w0BAQsFAAOCAQEARRCtAQ6SyyJKwAFyha3scmtVGJnn7fbWDU7/
f9vGuytpdMehdG8UXJBsK1x6Scx6KKbXKzzXgd8PrLtYSs6Y6mwiHk0ITKmP+6qi
Ue/L9xOIUKUVBzTSUDLoRNgm2cdE4KdNeULSDYT4ES1si68/ikGut2oSYFz8V068
1STDdspZ2/ypI5AANEV+7bvZGiO90iQuOoqPyhQaHC06oOQ2sN8xlpWpQEpQnvsD
QcnMGLyBjXjjNYAZL3LyuEnimPfhC4iHlMFOzs/GOj8cPZf4hb4SVo3vHN+p3PZz
2KrREU0xkl8Kl24Q/CzVTZaCSGKVrEvflNRwrKr+EDm/L/RFPw==
-----END CERTIFICATE-----
subject=CN = acme-v02.api.letsencrypt.org
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3348 bytes and written 410 bytes
Verification error: unable to get local issuer certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 20 (unable to get local issuer certificate)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 5E1E1816F1374390180619D36FF65F053310FC26126F682E75D6ADBBBE828B59
    Session-ID-ctx:
    Resumption PSK: 3326A7204E387DCD3CE5F489DEEB7525140F67D905EDA3E3E0F66F7F8463B80663D9AC9ED4F8D26FFA041440F913564C
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 86400 (seconds)
    TLS session ticket:
    0000 - f5 e4 86 c4 85 5e 75 0b-06 ec 1d 85 32 44 fc fb   .....^u.....2D..
    0010 - 9b 0c 42 84 9c d5 11 7d-c0 33 c4 22 00 1d b6 ca   ..B....}.3."....
    Start Time: 1698913193
    Timeout   : 7200 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 7F9C89F77A90AE3EC1664376881866F829AF1840BEDDA09ECDBF914E224C8C20
    Session-ID-ctx:
    Resumption PSK: 47EC11D0351B8E9475066927738167EFA2AA302842F6A32DF4AD0F8204627820FDAE5A29B9985E313526006C78A8451A
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 86400 (seconds)
    TLS session ticket:
    0000 - 19 75 a3 0a 93 75 e5 9f-3e b4 a7 71 2b 13 6f 6e   .u...u..>..q+.on
    0010 - 8c 97 dc a8 fb dc 20 f5-35 3d e4 80 6c ff f2 93   ...... .5=..l...
    Start Time: 1698913193
    Timeout   : 7200 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
2

Your OpenSSL s_client successfully connects, so your IP is not blocked.

6 Likes
3

Wherever curl for Windows is validating this cert from...
It doesn't seem to have this root cert in there:
[which it should]

That's a Windows problem - not an IP being blocked problem.

4 Likes
4

Depending on how curl is checking the trust store for root certificates it could just be that ISRG Root X1 isn't found in under Certificate > Local Computer > Trusted Root Certification Authorities. If not, try something like this to install it: Subset of Windows Users See Expired Let's Encrypt Certificates with `curl` - #24 by webprofusion

Assuming curl is present on the machine curl https://acme-v02.api.letsencrypt.org/directory should return a response OK. If the ISRG Root X1 cert is missing, try curl before and after installing and let us know if that fixed it.

1 Like
5

This is still a Windows problem.
I'd review one of their forums/support channels for:
"how to add/update a root cert used by curl for windows"

2 Likes
6

powershell invoke-webrequest -usebasicparsing https://valid-isrgrootx1.letsencrypt.org

or visiting that site with ie mode

5 Likes
7

StatusCode : 200
StatusDescription : OK
Content : 

                <head>
                <meta charset="utf-8">
                <meta name="viewport" content="width=device-width initial-scale=1" />
                <meta http-equiv="X-UA-Compatible" content="IE=edge">

                <title>valid-isrgroot...

RawContent : HTTP/1.1 200 OK
Connection: keep-alive
Vary: Accept-Encoding
Strict-Transport-Security: max-age=604800
X-XSS-Protection: 1; mode=block
Accept-Ranges: bytes
Content-Length: 4067
Content-Type: te...
Forms :
Headers : {[Connection, keep-alive], [Vary, Accept-Encoding], [Strict-Transport-Security, max-age=604800], [X-XSS-Protection, 1; mode=block]...}
Images : {}
InputFields : {}
Links : {@{outerHTML=Let's Encrypt; tagName=A; href=https://letsencrypt.org/}, @{outerHTML=CA; tagName=A;
href=GitHub - letsencrypt/boulder: An ACME-based certificate authority, written in Go.}, @{outerHTML=community support forums; tagName=A; href=https://community.letsencrypt.org/},
@{outerHTML=sponsor; tagName=A; href=Become a Sponsor - Internet Security Research Group}}
ParsedHtml :
RawContentLength : 4067

8

that was to load isrg certifate to local cert store, does curl still broken?

3 Likes
9

I forgot to mention that the certificate is successfully issued when using a VPN, so I don't think it's a Windows or root cert problem.

10

The necessary root certificate was already there, I didn’t change anything.

image
image1072×709 90 KB

11

So...
When NOT using a VPN, something interferes with access to LE on port 443 ? ? ?

2 Likes
12

No, the output of the command openssl s_client -connect from the first post is for the moment when the VPN is turned off

13

We are agreed.
When the VPN is turned off = When NOT using a VPN
The problem exists.
So...

2 Likes
14

Nothing interferes. LE is accessible on 443, accessible from "openssl connect", from IE or any other browser - whenever VPN is on or off, all looks the same. But When VPN is off we got error 35: OpenSSL SSL_connect trying to issue a cert via LE plugin for Plesk. When VPN is on, all works correctly. The one thing is changed is our external IP.

15

More than just the IP is changed when using a VPN.
Primarily: The path to LE changes.
If you VPN to my location, your path to LE becomes:

  • your server
  • your VPN
  • my vpn
  • my path to LE

Everything between your VPN and mine become transparent [to you].

2 Likes
16

The "VPN" endpoint in our case is our router in another location. The VPN is configured on the network gateway, so when turning on the VPN, the Plesk server configuration is not changed.
Well, this way we change our path to LE to another one. LE is accessible on both of them. But one of them causes an error and other does not. So what is this if not IP blocking?

17

Definitely something else.
I'd look for an IPS [or something of the sort] that is inline with that system - but not when it uses the alternate path [via the VPN].

3 Likes
18

We use the same software sets (OS, ISP, plugins, etc) in all of our deployments. LE works correclty wherever the configuration is. The two mentioned servers are both in the same public network subnet. LE on them works correctly too, but only when their network addresses are changed.
Can we just ask LE crew here to CHECK if our IPs are not in a blocklist?

19

Asked and answered:

4 Likes
20

It looks like a conclusion. I don't think there was a check.
Here is the same case - Plesk and could not issue a Let's Encrypt SSL/TLS due cURL error 35
Checked - unblocked - resolved.