SSL handshake errors

A couple of things to note:

1. You still have a few different client connections going on here. You can tell by the first number on each line (ex. 30, 31, 13, 254). I'll focus on 31 and 254 as they're the most complete captures.

    

2. The "Critical" you're seeing is an X.509 extension property. In most cases a client or server in receipt of a peer's certificate can ignore X.509 extensions that it doesn't understand, except in the case of critical extensions. It's quite common for the Key Usage and Basic Constraints extensions to be marked Critical.

    

3. Tcpdump and ssldump can sometimes display packets out of order. In this case though, the very next message should be a ClientKeyExchange from the client, so we can be pretty sure here that the client is the one with the issue.

    

4. I'm not definitively saying that HSTS is the issue here, but in a real-world scenario HSTS will prevent access if the browser can't trust the presented certificate. Because we know the HSTS header is/was present, it's a "low hanging fruit" so to speak. Have you tried this with a few different browsers (ie. Internet Explorer, Chrome, FireFox, etc.)? If it doesn't work in Chrome or Opera, go to chrome://net-internals/hsts and query for the domain there to see if it's in the list. If it isn't, then HSTS isn't the problem.

    

5. In any case, it appears from everything I've observed so far that the client is indeed the problem. If a cURL client (ignoring certificate trust) can access the site, but a browser can't, it almost certainly has something to do with certificate trust. Can you test with a new client SSL profile? Or better, the default clientssl profile (assuming HSTS isn't involved).