cURL error 35

  • Dear Mailpoet-Team,

    we use the free version to send newsletters to max. 300 recipients once a month. It worked wonderfully so far for sending the newsletter in April. Since then, the mail dispatch has been interrupted with the following error:

    cURL error 35: OpenSSL SSL_connect: Connection reset by peer in connection to bridge.mailpoet.com:443

    Although some e-mails are always sent, most of them remain in the queue each time they are sent. We have tried to solve the problem with our hosting provider. They replied that nothing is blocked from their side and that it is also possible to execute a direct curl on the address.

    It would be fantastic if you could support us in this matter.

    Thanks and best regards

    Daniel

    • This topic was modified 2 years, 6 months ago by freundbild.

    The page I need help with: [log in to see the link]

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Support kellymetal a11n

    (@kellymetal)

    Hi there @freundbild,

    We have a troubleshooting doc for the cURL 35 error in our KB here:
    https://kb.mailpoet.com/article/316-curl-issue-35-ssl-connect-error

    As mentioned there, in most cases just updating the versions of PHP and cURL resolve the issue.
    Please try that (and reach out to hosting again for assistance if necessary), then check to see if you still have the same issue.

    Thread Starter freundbild

    (@freundbild)

    Thanks, but we already tested that –?but PHP update to 8.x leads to other issues so we switched back . FYI: cURL is version 7.59.0 and PHP is stable version 7.4.29. Is PHP 8 a requirement for a stable MailPoet Installation?

    Plugin Support kellymetal a11n

    (@kellymetal)

    Hi there @freundbild,

    Nope, PHP 8 is not a requirement for running a stable version of MailPoet.

    Actually, out of curiosity since I wasn’t sure what I’m running personally, I just double checked my own site and see that I’m also running PHP version: 7.4.29

    So, from that “cURL 35 error” on its own, it’s not immediately clear why your site is having issues with the connection. If you check with your hosting one more time, do they have any error logs available on the server that might provide a bit more detail/info about the error?

    Thread Starter freundbild

    (@freundbild)

    Hi @kellymetal

    thanks a lot for responding. Unfortunatly the hosting provider found no errors in the PHP error.log –?the same for WordPress debug.log: no errors in relation to the issue.

    Do you have maybe any other suggestions?

    Thanks again and have a nice weekend

    Daniel

    Hi there @freundbild,

    I apologize for the late reply.

    Can you please ask your host to run the following command to update CA certificates in case they didn’t update properly?

    update-ca-certificates

    Reference: https://www.systutorials.com/docs/linux/man/8-update-ca-certificates/

    If it doesn’t help, please run the following command from your server and share the results here:

    curl –verbose https://bridge.mailpoet.com

    Looking forward to hearing back from you!

    Thread Starter freundbild

    (@freundbild)

    Hi @treibalen

    thanks for responding. The curl command mentioned does not initially provide any further insights here:

    * Rebuilt URL to: https://bridge.mailpoet.com/
* Trying 2a01:7e01:1::ac69:9259...
* TCP_NODELAY set
* Connected to bridge.mailpoet.com (2a01:7e01:1::ac69:9259) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
CAfile: none
CApath: /etc/ssl/certs/
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (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 change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=*.mailpoet.com
* start date: Apr 25 00:00:00 2022 GMT
* expire date: May 26 23:59:59 2023 GMT
* subjectAltName: host "bridge.mailpoet.com" matched cert's "*.mailpoet.com"
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA
* 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 0x8c593c8)
> GET / HTTP/2
> Host: bridge.mailpoet.com
> User-Agent: curl/7.59.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< date: Fri, 03 Jun 2022 08:27:45 GMT
< content-type: application/json
< content-length: 4
< x-content-type-options: nosniff
< strict-transport-security: max-age=15724800; includeSubDomains
<
* Connection #0 to host bridge.mailpoet.com left intact

    I have therefore examined the behaviour more closely via the following loop:

    For IPv4:
    IPv=4; URL=https://bridge.mailpoet.com; while true; do curl –connect-timeout 60 -$[IPv] $URL; done
    HELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELOHELO

    For IPv6:
    IPv=6; URL=https://bridge.mailpoet.com; while true; do curl –connect-timeout 60 -$[IPv] $URL; done
    HELOHELOcurl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to bridge.mailpoet.com:443

    As you can see, the other side seems to “limit” the connection briefly for accesses via IPv6 depending on two outputs. This then causes a timeout.

    Would be great if you could have a look on it.

    Thanks again and regards

    Daniel

    Same problem here, only two outputs and timeout with IPv6

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘cURL error 35’ is closed to new replies.