We are using self signed certificate behind a range of load balancers, the endpoints use Self Signed Certificates.

When testing the endpoints directly using CURL, we get intermittent SSL Connect errors (Code 35)

Here is an example output of a failed attempt:

curl --insecure example.com/index.html

  • Trying 9773...
  • Connected to example.com ( port 9773 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • successfully set certificate verify locations:
  • CAfile: /etc/ssl/cert.pem CApath: none
  • 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, Change cipher spec (1):
  • TLSv1.2 (OUT), TLS handshake, Finished (20):
  • LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to example.com
  • Closing connection 0 curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to example.com:9773

Is this due to a misconfiguration? Server performance issue? Network?

Server is Tomcat 8.

Command used to create the certificate:

openssl req -x509 -newkey rsa:4096 -nodes -keyout private.pem -out public.crt -days 365 -subj '/CN=example.com'

The associated Tomcat SSL configuration:

<Connector port="9773" protocol="org.apache.coyote.http11.Http11AprProtocol"
        <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
  • I suspect the server closed the socket unclean, do you see any exceptions on the server side? – eckes Jan 20 at 20:18
  • Only log file of interest is localhost, and that is only listing the successful (200) requests – comfytoday Jan 20 at 21:01
  • I think the errors are in the server Logfiles, but not sure which tomcat version writes them by default. If it does not write it you should probably configure a more verbose server logfile to see the cause for those aborts. Since it is after the server finished message was sent it must be related to the change cipher/end handshake from the client. You can also try to remove the actually used cipher to see if an other works better. – eckes Jan 20 at 21:05
  • 1
    ok, thanks. Gotta figure the logs out I guess... I tried using a specific cipher via CURL (ECDHE-RSA-AES256-GCM-SHA384) and it still only works sometimes. If I use a non supported cipher, it fails the same way (but everytime) The server doesn't have Cipher Order specified, which might be a problem. – comfytoday Jan 20 at 21:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.