I looked into this, and I think the error you're getting is actually due to a cipher suite mismatch.
I was able to confirm using just "openssl s_client -tlsextdebug -connect 220.127.116.11:443" that your server is not (apparently) _requiring_ SNI, so that's not the issue.
Using "nmap -sV --script ssl-enum-ciphers -p 443 18.104.22.168" I listed the ciphers supported by your server, and these are what I got:
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
Comparing that to our documentation (https://www.digi.com/resources/documentation/Digidocs/90002258/Reference/r_tls_cipher.htm) as well as the u-blox manual, none of those cipher suites are supported. (It does support TLS_RSA_WITH_AES_256_CBC_SHA and _SHA256, but the _DHE does make it different.)
This means that the 0x85 error that you are getting is because the TLS stack in the u-blox modem is not able to negotiate a secure connection with the server. If you reconfigure the server to accept one of the supported cipher suites, it should work fine.