SSL handshake errors

Yes, but is "thawte SHA256 SSL CA" an actual CA certificate? Is that the server cert and key you have defined in the client SSL profile? Is it failing with all browsers? Have you tried the cURL client? Did you enable HSTS in v12?

Yes it is an actual certificate that I have defined in SSL profile. Not sure what you mean by failing with all browsers. The web sites are mostly working but for these frequent SSL handshake errors from some clients. Curl shows the html from web site - as expected. No new information there.

* STATE: INIT => CONNECT handle 0x6000572f0; line 1090 (connection -5000)
* Rebuilt URL to: https://abc.net
* Added connection 0. The cache now contains 1 members
*   Trying 63.128.130.61...
* STATE: CONNECT => WAITCONNECT handle 0x6000572f0; line 1143 (connection 0)
* Connected to abc.net (63.128.130.61) port 443 (0)
* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x6000572f0; line 1240 (connection 0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* STATE: SENDPROTOCONNECT => PROTOCONNECT handle 0x6000572f0; line 1254 (connection 0)
* 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-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*        subject: C=US; ST=California; L=Mountain View; O=ABC, Inc.; OU=Network Operations; CN=*.abc.net
*        start date: Apr  9 00:00:00 2015 GMT
*        expire date: Apr  3 23:59:59 2016 GMT
*        issuer: C=US; O=thawte, Inc.; CN=thawte SHA256 SSL CA
*        SSL certificate verify ok.
* STATE: PROTOCONNECT => DO handle 0x6000572f0; line 1275 (connection 0)
> GET / HTTP/1.1
> Host: abc.net
> User-Agent: curl/7.45.0
> Accept: */*
>
* STATE: DO => DO_DONE handle 0x6000572f0; line 1337 (connection 0)
* STATE: DO_DONE => WAITPERFORM handle 0x6000572f0; line 1464 (connection 0)
* STATE: WAITPERFORM => PERFORM handle 0x6000572f0; line 1474 (connection 0)
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 403 Forbidden
< Date: Tue, 17 Nov 2015 15:41:39 GMT
* Server Apache is not blacklisted
< Server: Apache
< Last-Modified: Wed, 23 Apr 2014 23:57:35 GMT
< Accept-Ranges: bytes
< Content-Length: 1212
< Strict-Transport-Security: max-age=500
< X-XSS-Protection: 1
< Cache-Control: max-age=0, no-store
< Content-Type: text/html
<

I wasn't aware of HSTS but headers show:
Strict-Transport-Security: max-age=500


Does it mean its enabled and causing the issue? What does it do and can I disable it if this is the root cause?
Thanks
Naresh

Yes, this header indicates that you're using HSTS. Basically, that header tells the browser a few things:

1. For all subsequent requests to this URL, always connect via HTTPS (regardless of the URLs presented to the browser)

    

2. If for any reason the server's certificate cannot be validated, fail completely. In other words you don't get the option to bypass/ignore the error. It just fails.

    

It's very likely working in cURL because cURL doesn't understand HSTS. The max-age directive is in seconds, and that's how long the browser caches this information. Thankfully you didn't specify the usual 1 week, because it's very difficult to clear that cache. So at the very least you need to uncheck this value in the HTTP profile and wait 500 seconds to allow the browser to forget the setting. You may notice afterwards that the browser will prompt you to ignore the untrusted cert.

Kevin,

I should see this in my bigip.conf profile:

    hsts {
        mode enabled
    }
    

but I am not seeing it there. Search for hsts in bigip.conf didn't find anything. Not sure what this means.

Naresh

If this is v12 you should definitely see an hsts setting in HTTP profile. In either case, in the HTTP profile assigned to this VIP, do you see the HTTP Strict Transport Security option (at the botton of the profile)? And if so is it enabled? If it's not enabled, is it possible that the application itself is sending the HSTS header?

I don't see it

[root@xxx:Active:In Sync] config grep hsts bigip.conf [root@xxx:Active:In Sync] config

Not sure about clients being able to do that and cause handshake errors?

Look at the HTTP profile in the GUI. This is v12?

Not sure about clients being able to do that and cause handshake errors?

The point is that a modern browser will fail on trust issues if this header is present.

Hit send too soon. This isn't enabled by default in a v12 HTTP profile, so do you have an iRule sending it? Can you tell if the application server is configured to send it?

No its not configured in an iRule and No clients are not configured to send it.

Not clients. Servers. If you're seeing this header at the client, then someone is sending it.