Forum Discussion

Cirrus

Jun 29, 2017

Need help with SSL handshake failure and client certificates

Hi,

we are using a clientSSL-profile with client certificate set to require and also configured the trusted/allowed CA. When connecting to this VS with a valid client certificate we are ending up with a SSL handshake failure. When we remove this option and using just "normal" SSL handshake, everything is working fine, means there is at least no issues with the ciphers and SSL protocol. We are also using the same setup in a different region and there everything is working fine. I'm not 100% sure, which might be different in the two regions, but at least clients and F5s are using the same software/version.

We also performed a tcpdump and a ssldump and saw the following strange thing (Not enough data.😞

1 1  0.0756 (0.0756)  C>S  Handshake
  ClientHello
    Version 3.3 
    cipher suites
    Unknown value 0xc02f
    Unknown value 0xc02b
    Unknown value 0xc030
    Unknown value 0xc02c
    Unknown value 0xc027
    Unknown value 0xc023
    Unknown value 0xc028
    Unknown value 0xc024
    Unknown value 0xc013
    Unknown value 0xc009
    Unknown value 0xc014
    Unknown value 0xc00a
    Unknown value 0x9e
    Unknown value 0xa2
    Unknown value 0x9f
   Unknown value 0xa3
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
    TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
    TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
    TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA
    TLS_DHE_DSS_WITH_AES_128_CBC_SHA
    TLS_DHE_RSA_WITH_AES_256_CBC_SHA
    TLS_DHE_DSS_WITH_AES_256_CBC_SHA
    Unknown value 0x9c
    Unknown value 0x9d
    TLS_RSA_WITH_AES_128_CBC_SHA256
    TLS_RSA_WITH_AES_256_CBC_SHA256
    TLS_RSA_WITH_AES_128_CBC_SHA
    TLS_RSA_WITH_AES_256_CBC_SHA
    Unknown value 0xc012
    Unknown value 0xc008
    TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
    TLS_RSA_WITH_3DES_EDE_CBC_SHA
    Unknown value 0xff
    compression methods
              NULL
1 2  0.0756 (0.0000)  S>C  Handshake
  ServerHello
    Version 3.3 
    session_id[32]=
      0e c8 c2 ce da 55 22 f3 cd 5d ab 0d 32 31 bb 29 
      9b 0a 63 97 2e 9a 71 6b 2c 9a 52 e7 1f ec 5b c7 
    cipherSuite         TLS_RSA_WITH_AES_256_CBC_SHA256
    compressionMethod                   NULL
1 3  0.0756 (0.0000)  S>C  Handshake
  Certificate
1 4  0.0756 (0.0000)  S>C  Handshake
  CertificateRequest
    certificate_types                   rsa_sign
    certificate_types                   dss_sign
    certificate_types                 unknown value
Not enough data. Found 221 bytes (expecting 32767)
1 5  0.0756 (0.0000)  S>C  Handshake
  ServerHelloDone
1 6  0.2462 (0.1705)  S>C  Alert
level           fatal
value           handshake_failure
1    0.2462 (0.0000)  S>C  TCP FIN

Is this maybe indicating the issue and if yes, what does it mean or where does it come from?

If not, how can we further troubleshot this? As I personally don't have direct access to the affected F5, I also don't know the latest status, but we at least agreed to set the SSL log-level to debug. Are there any further tips you can provide? Maybe also something, which can/should be checked on the client?

Maybe a stupid question, but can this also be related to some issues on network level between client and F5 or are such handshake failures definitely only related to correct client and F5 settings?

Thank you!

Ciao Stefan 🙂

Stefan_Klotz_85
Jun 30, 2017
Hi Ashwin,

thanks for your help, but we could solve the issue. It starts working after we configured the whole chain for the "Trusted Certificate Authorities"-option in the "Client Authentication"-section of the clientSSL-profile, where we initialy only configured the single issuer certificate from the client-certificate.

But what is still strange for us, as I already mentioned, in the other region it's still working with just the single issuer certificate (which I also thought that this is sufficient). Might this be related to some settings on the clientside? Not sure if it's important or relevant, but the client in our case is a CA API Gateway.

Thank you for some final hints!

Ciao Stefan :)

Ashwin_Venkat
Employee
Jun 30, 2017
Hello Stefan,

Is it possible to let us know what signature algorithm was used to sign the certificate that is assigned to the SSL profile? If its something other than RSA, DSA or ECDSA algorithm, then its unsupported and that could be one of the potential reason why we immediately send the fatal alert after presenting the certificate and the certificate request messages. If its something that's been signed with a signature algorithm like RSASSA-PSS (default one for certain/newer Microsoft PKIs from my experience), then its unsupported and that could result in behavior that you're observing.

If/when you confirm that you're using a certificate with one of those 3 signature algorithms, I'd recommend either turning on SSL debug logging (make sure to turn it off soon after gathering the troubleshooting info) or else looking at the fatal alert packet in the packet to see exactly what the fatal alert code it is that you are receiving will go a long way in helping us in understanding why the fatal alert is being sent by the F5.

I look forward to your response!
Stefan_Klotz
Cumulonimbus
Jun 30, 2017
Hi Ashwin,

thank you for the quick answer. The signature algorithm shouldn't be an issue as this is SHA1 with RSA. But which certificate in the SSL profile do you mean? The server certificate, the client certificate or the issuer certificate (from the client certificate)?

What I can provide in the meanwhile from the SSL debugging is this message:

ssl_hs_rxhello:7103: unsupported version (40)

Does this help or indicating in the correct direction?

Thank you!

Ciao Stefan 🙂
Ashwin_Venkat
Employee
Jun 30, 2017
Hi Stefan,

That message is an indication that a protocol couldn't be negotiated for the handshake, which doesn't apply in this case as we're well past that stage. If you have a packet capture with you, you can take a look at the alert code specified in the fatal alert packet to see which one resulted in the termination of the connection.

I'd recommend opening up a Support ticket with us, so we can take a look at this a bit more closely.
Stefan_Klotz
Cumulonimbus
Jun 30, 2017
Hi Ashwin,

does this provide you more useful information? Thank you!

Ciao Stefan :)
Stefan_Klotz_85
Cirrus
Jun 30, 2017
Hi Ashwin,

thanks for your help, but we could solve the issue. It starts working after we configured the whole chain for the "Trusted Certificate Authorities"-option in the "Client Authentication"-section of the clientSSL-profile, where we initialy only configured the single issuer certificate from the client-certificate.

But what is still strange for us, as I already mentioned, in the other region it's still working with just the single issuer certificate (which I also thought that this is sufficient). Might this be related to some settings on the clientside? Not sure if it's important or relevant, but the client in our case is a CA API Gateway.

Thank you for some final hints!

Ciao Stefan :)