Getting SSL Handshake errors

What is the name of the domain?

tnt-integration.net

What is the error number?

525

What is the error message?

Error occurred, status 525

What is the issue you’re encountering

Getting intermittent monitoring and application failures due to 525 errors being returned by cloudflare

What steps have you taken to resolve the issue?

It’s intermittent, have had 2 x 5 minute or so outages in last few days

Was the site working with SSL prior to adding it to Cloudflare?

Yes

What is the current SSL/TLS setting?

Full

What are the steps to reproduce the issue?

Unable to reliably reproduce, it’s intermittent. I’m unsure of the current SSL/TLS setting, advise me where to find it.

Greetings,

Thank you for asking.

I am sorry to hear this.

Currently, I receive a different one, 521 error as follows:

Before moving to Cloudflare, was your Website working over HTTPS connection?

You could determine this by:

  1. Use the “Pause Cloudflare on Site” option from the Overview tab for your domain at dash.cloudflare.com .
  2. The link is in the lower right corner of that page.
  3. Give it five minutes to take effect, then make sure site is working as expected with HTTPS without any error
  4. Check with your hosting provider / cPanel AutoSSL and renew it
  5. Only then, when your website responds over HTTPS, you should un-pause Cloudflare and double-check your SSL/TLS setting to make sure it’s Full (Strict).

May I ask if and what steps for troubleshooting 525 error have you tried from the below post already? :thinking:

I’m not having any troubles accessing the site. My monitoring via uptime robot is showing the site as up for last 48 hours. Certificate (SSL) valid from July 28 to Oct 26. This site has been on cloudflare for 10 months, it’s never been NOT on cloudflare.

Tomcat server uptime is 35 days

Any update on this issue?

Hey there!

Sorry to hear about your site issues.

At this time, your server is only available on Port 8443. It is not responding on Ports 80 or 443.

Please check your origin configuration to be sure it is available on the ports you wish to use. If 8443 is your only choice, you may use an Origin Rule to route all requests to Port 8443:

If you have any other questions, please post back, and we’ll be happy to assist.

1 Like

Thanks for the help. I’ve implemented the origin rule as suggested and deployed it. Still getting the same failures. 525: SSL handshake failed intermittently.

This cloudflare implementation has been reliable for at least six months until the middle of August and then started failing with the 525 error at random.

It’s a single tomcat embedded server running only on port 8443. I can duplicate the 525 errors either in the application front end or postman, it will reliably work 3 or 4 times, then fails once, then back to working reliably 3 or so times. I can’t identify any pattern.

Now the ssl handshake failures are happening all the time.

I can test succesfully using

openssl s_client -connect tnt-integration.net:8443 -servername tnt-integration.net

when I’m logged onto the server

CONNECTED(00000003)
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R4
verify return:1
depth=1 C = US, O = Google Trust Services, CN = WE1
verify return:1
depth=0 CN = tnt-integration.net
verify return:1

But accessing via postman or browser returns 525

also from the host:

curl -svo /dev/null https://tnt-integration.net:8443 --connect-to ::170.64.173.122 -u

returns

  • processing: https://tnt-integration.net:8443
  • Connecting to hostname: 170.64.173.122
  • Trying 170.64.173.122:8443…
  • Connected to 170.64.173.122 (170.64.173.122) port 8443
  • ALPN: offers h2,http/1.1
    } [5 bytes data]
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
    } [512 bytes data]
  • CAfile: /etc/ssl/certs/ca-certificates.crt
  • CApath: /etc/ssl/certs
    { [5 bytes data]
  • TLSv1.3 (IN), TLS handshake, Server hello (2):
    { [122 bytes data]
  • TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
    { [32 bytes data]
  • TLSv1.3 (IN), TLS handshake, Certificate (11):
    { [2040 bytes data]
  • TLSv1.3 (IN), TLS handshake, CERT verify (15):
    { [78 bytes data]
  • TLSv1.3 (IN), TLS handshake, Finished (20):
    { [52 bytes data]
  • TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
    } [1 bytes data]
  • TLSv1.3 (OUT), TLS handshake, Finished (20):
    } [52 bytes data]
  • SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
  • ALPN: server did not agree on a protocol. Uses default.
  • Server certificate:
  • subject: CN=tnt-integration.net
  • start date: Sep 12 00:10:09 2024 GMT
  • expire date: Dec 11 00:10:08 2024 GMT
  • subjectAltName: host “<hidden to get around 4 url limit>” matched cert’s “<hidden to get around 4 url limit>”
  • issuer: C=US; O=Let’s Encrypt; CN=E6
  • SSL certificate verify ok.
  • using HTTP/1.x
  • Server auth using Basic with user ‘admin’
    } [5 bytes data]

GET / HTTP/1.1
Host: tnt-integration.net:8443
Authorization: Basic
User-Agent: curl/8.2.1
Accept: /

{ [5 bytes data]

  • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
    { [2310 bytes data]
    < HTTP/1.1 200
    < Vary: Origin
    < Vary: Access-Control-Request-Method
    < Vary: Access-Control-Request-Headers
    < X-Content-Type-Options: nosniff
    < X-XSS-Protection: 0
    < Cache-Control: no-cache, no-store, max-age=0, must-revalidate
    < Pragma: no-cache
    < Expires: 0
    < Strict-Transport-Security: max-age=31536000 ; includeSubDomains
    < X-Frame-Options: DENY
    < Content-Type: text/html;charset=UTF-8
    < Content-Language: en
    < Transfer-Encoding: chunked
    < Date: Thu, 12 Sep 2024 05:23:54 GMT
    <
    { [4854 bytes data]
  • Connection #0 to host 170.64.173.122 left intact
    tnt@ubuntu-tntprod-syd1-01:~$
    HTTP/1.1 200

that curl command also worked from a different PC entirely, a macbook

Just went to the cloudflare dashboard and the setting page for SSL shows this

SSL/TLS encryption

Current encryption mode:

FlexibleThis setting was last changed 23 days ago.

I DID NOT change this and my problems started about 23 days ago. Please advise.

Your document states:

Plan Using SSL/TLS recommender? Grace period ends
Non-Enterprise Yes September 9th, 2024

I’m suspecting this may the the root cause? Timing certainly matches my issues.

In the middle of the night while I slept it magically started working again.

Would like to know any public information on the issue.

The ssl certificate and expiry date shown in the browser is different to that on the server. Is that considered normal?

Browser:
Organization Google Trust Services
Not After Sat, 26 Oct 2024 19:48:04 GMT

Server:
Expiry Date: 2024-12-11 00:10:08+00:00 (VALID: 89 days)

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