New post
Question
· Jun 18

SSL/TLS unsupported protocol error

#API #SSL #Caché

I'm using a %Net.HttpRequest which had been successful in the past, but started failing at some point with a SSL/TLS protocol error.

ERROR #6085: Unable to write to socket with SSL/TLS configuration 'groundca', error reported 'SSL/TLS error in SSL_connect(), SSL_ERROR_SSL: protocol error, error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol'

The SSL/TLS configuration:

The request's SSLConfig is set to the "groundca" config when making the request.

A request using the same URL, API key, and CA file through Curl receives the desired response from the API at "https://osrd.atlassian.net/rest/api/2/issue/<issue-name>", so I believe the issue isn't with the OS, networking, or API server. It shows that Curl is using TLSv1.3.

This thread makes me think perhaps an older version of SSL is being used in the Caché request instead of TLS even though the SSL/TLS config is set to use TLS, since the post also shows "SSL23" in the error, and suggests it comes from the OP's config being set to use 'SSL23' rather than 'tls12': https://github.com/lefcha/imapfilter/issues/140#issuecomment-259671735

Another IS thread shows a similar issue that was worked around. They believed a lack of SNI was the issue, though this was a handshake error rather than a protocol error: https://community.intersystems.com/post/how-do-not-use-sslv3-force-tls-variant-httprequest-aws-api-gateway

 

Edit - adding ^REDEBUG log output:

06/19/25-09:52:07:258 (11524) 0 tpopen for host osrd.atlassian.net device number 25334188 port 443  mode 0x8848 tcpmode 0x24 terminators  ibfsz 8192 obfsz 8192 queuesize 5 timeout 30 tcpsbuf=0 tcprbuf=0, XY=off, BINDTO=
06/19/25-09:52:07:275 (11524) 0 TCPConnect: SNDBUF sys size=65536, dev size=0
06/19/25-09:52:07:276 (11524) 0 TCPConnect: RCVBUF sys size=65536, dev size=0
06/19/25-09:52:07:281 (11524) 0 
TCP connected to site 13.227.180.4 port 443
06/19/25-09:52:07:282 (11524) 0 StreamInit: SNDBUF sys size=65536, dev size=0
06/19/25-09:52:07:283 (11524) 0 StreamInit: RCVBUF sys size=65536, dev size=0
06/19/25-09:52:07:284 (11524) 0 
SSL/TLS configuration: groundca
06/19/25-09:52:07:285 (11524) 0 
Cipher list: ALL:!aNULL:!eNULL:!EXP:!SSLv2
06/19/25-09:52:07:285 (11524) 0 
Trusted certificate file: c:\Users\dwp\downloads\cacert.pem
06/19/25-09:52:07:296 (11524) 0 

Peer verification option = 1, certificate depth = 9
06/19/25-09:52:07:297 (11524) 0 
SSL/TLS client requested.
06/19/25-09:52:07:300 (11524) 0 
SSL/TLS error return from SSL_connect().
06/19/25-09:52:07:301 (11524) 0 
SSL_ERROR_SSL: protocol error
06/19/25-09:52:07:302 (11524) 0 
error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol
06/19/25-09:52:07:304 (11524) 0 
TPXMIT saw TCP device fail

 

Edit 2:

We're calling out to Curl with zf(-1) and having Curl write the result to a file so it can be read in that way. I'm still wondering whether the wrong version of SSL is being used because of the other post mentioning the same error for another tool, but I doubt we'll look into it further for now.

Product version: Caché 2017.1
$ZV: Cache for Windows (x86-64) 2017.1.2 (Build 217_0_17784)
Discussion (3)2
Log in or sign up to continue
DC AI Bot · Jun 18

The error you are encountering, SSL23_GET_SERVER_HELLO:unsupported protocol, often indicates that the SSL/TLS configuration being used is attempting to negotiate an unsupported SSL/TLS version for the connection. This can occur if a server supports a newer protocol like TLS 1.3 and your implementation is limited to older versions like SSL 3.0 or TLS 1.2.

Here are some troubleshooting steps and points of consideration based on the documents:

  1. Update SSL/TLS Configuration:

    • Ensure your SSLConfiguration in the %Net.HttpRequest object is correctly configured to use the protocols supported by the server. For example:
      objectscript
      Set request = ##class(%Net.HttpRequest).%New()
      Set request.SSLConfiguration = "groundca"
      Set request.Server = "osrd.atlassian.net"
      Set request.Https = 1
      Set tSc = request.Get("/rest/api/2/issue/<issue-name>")
      You may need to verify that the SSL/TLS configuration named groundca supports the correct set of protocols (e.g., TLS 1.2 or TLS 1.3) [1][2].

  2. Enable Supported TLS Versions:

    • If the error is due to protocol mismatch, check whether your Caché system supports the required protocols. Older versions of Caché may not support TLS 1.3, as indicated in some discussions around outdated versions [3][4]. If upgrading to a newer version is not currently an option, you could use an external tool like Stunnel in client mode to handle the TLS encryption [3].

  3. Verify Server Certificate and SNI:

    • If the server uses Server Name Indication (SNI), your configuration might need to explicitly include the SNI name. Some versions of Caché do not support SNI, and you may need a workaround for older setups [5]. For instance:
      objectscript
      Set request = ##class(%Net.HttpRequest).%New()
      Set request.SSLCheckServerIdentity = 0

  4. Troubleshoot Using curl:

    • Since Curl successfully connects using TLS 1.3, it confirms that the server and API key are working as expected. Compare Curl's configurations (e.g., certificates, protocols used) with your Caché setup to identify discrepancies [1].

  5. Certificate Matching:

    • Ensure the server name matches the values in its SSL certificate. Sometimes mismatches arise from redirects or incorrect configuration, which can result in an SSL handshake failure [1][5].

If these steps do not resolve the issue, further analysis of the environment and possibly server-side requirements may be needed. It's also advisable to consider upgrading Caché or alternative methods to establish newer protocol support. [1][5][3][4]

Sources:

0 0
Vic Sun · Jun 18

First thing that comes to mind is disabling TLS 1.1 as that is deprecated. For TLS 1.3 (if that's required) you'll need to migrate to IRIS ( being on Cache 2017 probably has other security implications that would be remedied by upgrading at least to Cache latest.)

You might be able to find out more about this issue using ^REDEBUG as discussed in another post on the community, else support can probably help look into what the issue is. It's been a bit since I've worked on something like this myself.

0 0