Forum Discussion

Devlin_T_149357's avatar
Devlin_T_149357
Aug 21, 2016

Server-side SSL Failing

Hello everyone

 

We have a project where we need to provide TLS offload (client-side) and server-side encryption to the back-end web servers. I thought I'd test this out in my lab but seem to be struggling.

 

I have an Apache2 web server configured to serve HTTPS web pages. The certificate presented by the web server is from my lab PKI. Browsing to the server directly from my PC, bypassing the LTM appears all good. The handshake is successfull. Things appear to work. When I introduce the LTM things fail.

 

So far I have created a client-side cert and attached this to a client SSL profile then virtual server. I know this works because if I change the backend web server to a plain HTTP, the offload works just fine.

 

I have imported my two PKI certificates (root/sub) and concatinated them as per sol13302, then installed them. I then attach this chain certificate to the server SSL profile under Configuration > Chain. Then attach the SSL profile to the VS.

 

Even after all this, I get the following error: 'Secure Connection Failed'. If I use OpenSSL to test I get the following:

 

[root@:Active:Standalone] tmp  openssl s_client -connect red-https-server.lab.com:443
CONNECTED(00000003)
depth=0 C = UK, ST = London, L = London, O = Lab Inc., OU = IT Dept., CN = blue-https-server.lab.com
verify error:num=20:unable to get local issuer certificate
verify return:1  

depth=0 C = UK, ST = London, L = London, O = Lab Inc., OU = IT Dept., CN = blue-https-server.lab.com
verify error:num=27:certificate not trusted
verify return:1  

depth=0 C = UK, ST = London, L = London, O = Lab Inc., OU = IT Dept., CN = blue-https-server.lab.com
verify error:num=21:unable to verify the first certificate
verify return:1

I understand the error messages, the LTM clearly cannot verify the identity certificate the web server is presenting. If I change the OpenSSL command to use the chain cert, it works:

 

    [root@:Active:Standalone] tmp  openssl s_client -connect red-https-server.lab.com:443 -CAfile /config/filestore/files_d/Common_d/certificate_d/:Common:LAB-CHAIN-CERT.crt_71998_1
CONNECTED(00000003)
depth=2 CN = LAB-ROOT-CA
verify return:1  

depth=1 DC = com, DC = lab, CN = LAB-SUB-CA
verify return:1  

depth=0 C = UK, ST = London, L = London, O = Lab Inc., OU = IT Dept., CN = blue-https-server.lab.com
verify return:1  
Verify return code: 0 (ok)

This is really frustrating me as it seems as if regardless of how I configure the SSL profile the handshake keeps failing.

 

Anyone have an idea on where I am going wrong?

 

Thank you

 

certificate
LTM
security
ssl profile
tls
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Aug 21, 2016

    By default the BIG-IP doesn't care about the server side trust. Only if you've configured the server authentication section in the server SSL profile, and told it to require a cert and how to validate that cert, does it care. In other words, if you left that section alone, it would generally ignore (not try to validate like the ignore validation switch in OpenSSL) the server certificate.

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Aug 22, 2016

    The server's certificate is sent as part of a larger message, so the problem could be anything before it as well, including cipher mismatch.

    1. Are you using a (subordinate) CA certificate and private key as the web server's cert/key? What are the keyUsage and extendedKeyUsage values in that certificate's X509 properties? You can see this from a Windows machine by double-clicking the certificate file of from OpenSSL on the command line:

      openssl x509 -in [cert] -noout -text

    2. Can you also provide an SSLDUMP of that server side handshake?

      ssldump -AdNn -i [server side VLAN] port 443 [and any additional filters]

    3. Can you also provide an SSLDUMP of the OpenSSL command line test?

    Just spitballing here, but the error message seems to indicate there's something wrong with the server's public key. Even in lieu of validation, the server's public key can be used for encryption as part of the key exchange, so it might be worth a look at the handshake itself.