Forum Discussion

Neil_Marks's avatar
Neil_Marks
Icon for Nimbostratus rankNimbostratus
Nov 26, 2019

Debugging ServerSSL Profile Setup

So I have a setup which basically is as follows:

F5 LTM (terminates external https traffic) this needs to re-encrypt to a NGINX server, which is setup to passthrough traffic to a HA Proxy service which also passes through to an Openshift setup, of which potentially multiple applications are accessible - inside the HA Proxy/Openshift these are all registered to a wildcard DNS - eg *.openshift.test, and all this resolves to the HA Proxy virtual IP.

 

So from the F5 cmd line, I can issue a simple curl cmd specifying the appropriate cert (as created within the Openshift env) which routes via the NGINX server and into HA Proxy and connects fine. Example curl --cacert ca-ocp.pem https://app1.openshift.test - where I have created a entry in the F5 host file for app1.openshift.test to map to the NGINX server IP address.

 

The NGINX config is a simple stearm defined one which listens on port 443 and routes to the HA Proxy IP address (as defined by *.openshift.test).

 

The above proves the routing/firewalls etc are all in place from the F5 downtream.

 

Now onto the issue I am encountering. I have a defined external URL which has a valid cert/etc - all verified by SSLshopper. The virtual server definition on the F5 has a clientssl profile (for the external cert) and a serverssl profile - this contains the cert used above (ca-ocp.pem). The pool which the VS uses has the IP address for the member which is the IP address of the NGINX server, now I am aware that this could be a potential problem as the IP address used here would not match the expected CN name of the application defined in Openshift. A health monitor on the pool (simple https one) works and the pool shows green. However, I can not get any connection working from the external URL through the F5 and onto the NGINX/HAproxy/Openshift.

I have created an iRule to log various events to see how far the F5 processes the request before it fails... and what I am seeing is the following:

  • FLOW_INIT
  • CLIENT_ACCEPTED
  • CLIENTSSL_CLIENTHELLO
  • HTTP_REQUEST
  • LB_SELECTED
  • LB_FAILED

I have SERVER_CONNECTED/SERVERSSL_CLIENTHELLO_SEND/SERVERSSL_SERVERHELLO/SERVERSSL_HANDSHAKE also defined in the iRule but these events are never triggered.

I have to admit using serverSSL profiles is completely new to me and so I am struggling to find out what is the root of the problem. The error logging for this type of issue seems to be non-existent, so I am in the dark as to where the problem lies, but I am sure (to the extent of my limited knowledge here) that is in the area of the serverSSL profile definition.

 

Any pointers as to how to troubleshoot this further would be useful! Many thanks!

 

application delivery
BIG-IP
LTM
ssl
  • nathe's avatar
    nathe
    Icon for Cirrocumulus rankCirrocumulus
    Nov 26, 2019

    Neil,

     

    Can you confirm your ServerSSL setup? See ServerSSL Overview page, To troubleshoot have you tried using the default ServerSSL profile? As mentioned in the link above, when a serverssl profile is added the bigip is acting as a client and uploading a cert means the bigip presents this as a client certificate to the pool member. From your description i'm not sure this is what you are after.

     

    If you want to validate the certificate from the pool member then in the Server Authentication settings part you can specific the domain name of the certificate expected.

     

    Hope this helps,

     

    N

  • Simon_Blakely's avatar
    Simon_Blakely
    Icon for Employee rankEmployee
    Nov 26, 2019

    So let's understand what is going on with the server-ssl profile and compare it to the curl command ...

    curl --cacert ca-ocp.pem https://app1.openshift.test

    Send a ClientHello to the SSL server app1.openshift.test.

    When the ServerHello returns the certificate, validate it against the Certificate Authority defined in ca-ocp.pem before connecting.

    With a server-ssl profile, we validate the returned certificate against the settings set in the Server Authentication section - the servers (pool members) are specifically defined, and may be configured with self-signed or non-public certificates, so we usually just trust them.

    This is the equivalent of 

    curl -k https://app1.openshift.test

    But the server-ssl profile also does not know the name of the target server - the pool member is specified by IP. 

    curl -k https://192.168.1.1

    Here is where you probably fail - the target server needs a Server Name Indication (SNI) to identify the correct service to respond with. This is specified in the Server Name field of the server-ssl profile.

    You also need to use an irule/Local Traffic Policy to select the correct server-ssl profile or pass-through the request SNI to the server-side ssl request:

    SNI Routing with BIG-IP

    Client side to server side SNI relay iRule