SSL handshake failure using serverssl (F5 and Citrix Netscaler)

Can you provide the VIP Configuration?

Are you using the default serverssl profile, do you have a monitor to the pool member and is it working? Have you seen https://support.f5.com/csp/article/K15292 and have you checked the logs for more detailed information?

N

SSL profile config may also help. Wildcard should be fine. If you're on a version prior to 11.4, the length of the wildcard cert chain could present a problem if it exceeds 32k.

 

https://support.f5.com/csp/article/K17050

 

There could be another requirement on either side that is not being met. HSTS or master secret extensions could also play factors.

 

https://support.f5.com/csp/article/K34019109

 

The cert should be negotiated at the time of failure as seen in: https://devcentral.f5.com/s/feed/0D51T00006i7gXVSAY

 

The cert exchange should happen next and contain it's own cert and possibly an intermediary CA. They should be using a standard trusted root CA but if they're not, you'll want to have their cert chain in our system to validate.

 

https://devcentral.f5.com/s/feed/0D51T00006i7WonSAE

 

But if you can, provide your SSL profile config and the Netscalars and as Anesh stated, your VIP config. That will help determine where the handshake failure may reside.

 

If you can provide the contents of their cert (cert NOT key) and chain, that would be easy to identify if it's a one-off or weird multi-chain cert.

 

Is this for monitor traffic or real traffic on a pool that is up?

Hello All,

@Anesh - I will provide the configuration by tomorrow however I would like to tell you that there is nothing extraordinary in the configuration. Client & server ssl profiles have been applied to the VIP.

@Nathan - Nope, I have not applied the default ssl profile. Monitor has been applied & it is working correctly. I have reviewed the logs at warning level & hence it does not show me anything specific to the failure reason.

@Abbott - I will provide the SSL config tomorrow. The F5 is running on 11.6.2 so the first link is not releavent for my scenario.

Second link again not for my case reason being proxy SSL is disabled & my version of code is lower.

Third link has some useful information but my serverssl profile is configured correctly with the cert,key & chain parameters. However in the wireshark capture or SSL dump above I receive the fatal error right after the Server Hello & the destination server presents its certificate post the fatal error. The certificate is from a trusted root CA(Comodo).

I really appreciate the inputs provided by you all. Please continue to provide your thoughts. I will also continue to deep dive into this issue.

Regards,

Ajit

Hello Anesh / Chase,

Below is the serverssl profile config:

ltm profile server-ssl abc_443_NP_SLG_https_profile_server-ssl {
    alert-timeout 10
    app-service none
    authenticate once
    authenticate-depth 9
    authenticate-name none
    ca-file Comodo_xyz.crt
    cache-size 262144
    cache-timeout 3600
    cert abc.crt
    chain Entrust-EV-256-Bundle-AVX.crt
    ciphers !SSLv2:!SSLv3:!DTLSv1:!EXP:!MD5:!ADH:!NULL:!LOW:!RC4:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-CBC-SHA:ECDHE-RSA-AES256-CBC-SHA:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA:+TLSv1_1:+TLSv1
    crl-file none
    defaults-from serverssl
    description none
    expire-cert-response-control drop
    generic-alert enabled
    handshake-timeout 10
    key abc.key
    mod-ssl-methods disabled
    mode enabled
    options { dont-insert-empty-fragments }
    partition Common
    passphrase "****"
    peer-cert-mode require
    proxy-ssl disabled
    proxy-ssl-passthrough disabled
    renegotiate-period indefinite
    renegotiate-size indefinite
    renegotiation enabled
    retain-certificate true
    secure-renegotiation require![Image Text](/Portals/0/Users/164/20/128420/SSLFailure.PNG?ver=2018-06-25-001012-333)-strict
    server-name none
    session-mirroring disabled
    session-ticket disabled
    sni-default false
    sni-require false
    ssl-forward-proxy disabled
    ssl-forward-proxy-bypass disabled
    ssl-sign-hash any
    strict-resume disabled
    unclean-shutdown enabled
    untrusted-cert-response-control drop
}

Also, I am attaching a wireshark screenshot of the capture where the SSL handshake fails.

I see you have a Comodo certificate in the serverssl, does that mean the netscaler is expected the bigip to send a certificate? This is similar to client authentication and you would only have a cert/key here if the other end needed the bigip to send a certificate to authenticate itself against the backend. Normally this is not required.

For a test have you tried the default serverssl profile?

@Anesh - I will surely test the connectivity with secure negotiation set to request tomorrow.

@Nathan - I have enabled server auth in my serverssl which means that the netscaler will present a cert to me & I will validate that cert with the comodo intermediate & root bundle.

Also, client auth is enabled at the netscaler end & hence i am present the abc certs to the netscaler.

Regards,

Ajit

Did you test the change?