Bypass SSL Cert CAS Server

Are you talking about doing SSL (port 443) to the CAS servers? If so, in general you need to apply a server SSL profile so that the F5 can talk SSL to the servers. How you have the CAS server's SSL configured determines how you configure your server SSL profile. As long as you have a very simple SSL configuration, just listening on port 443 and NOT requiring client certificates, then a very generic server SSL profile will do.

Hi there guys,

 

Finally I've configured all making SSL passthru applying VS L4 without http profile, now it's works for me.

 

 

Best regards.

Hi,

 

Can anyone describe step how SSL server side profile (default one) works. Means what it does when applied on VS?

 

Pradeep

 

The server side SSL profile is used when you need to negotiate SSL with the back end servers. For example, if your servers are listening on port 443 (HTTPS), you have essentially two options:

 

 

1. Passthrough - this is what you're doing now. No client or server SSL profiles and no other layer 7 (ex. HTTP) profiles. The encrypted SSL passes right through a layer 4 VIP. The biggest benefit of this approach is that you can get the client's certificate (if doing client certificate authentication) directly to the server. The downside is that you lose ALL layer 7 functionality of the F5, including several of the persistence mechanisms.

 

 

2. Terminate and re-encrypt - this is where you apply client AND server SSL profiles. The client SSL profile negotiates SSL with the client to decrypt the client side SSL, and the server SSL profile negotiates SSL with the server to re-encrypt. In the middle is unencrypted layer 4-7 data that you can manipulate with iRules and use for robust persistence mechanisms.

 

 

3*. ProxySSL - I mention this because it's there, but I don't think you need to factor in this option. ProxySSL is an SSL "man-in-the-middle" option that allows the F5 to essentially decrypt and re-encrypt using the session encryption key established between the client and server. It allows for direct client certificate authentication while still being able to use *some* layer 7 iRule and persistence functions.

 

 

How you configure the server SSL profile is dependent on how you've configured the SSL on your servers. If you simply enable SSL in IIS, then the generic "serverssl" profile is generally enough. Consider that the server SSL profile is the client in this transaction, so the client says CLIENTHELLO (I'd like to start an SSL session with you and here is a list of ciphers I support), the server says SERVERHELLO (I've chosen *this* cipher from you list to use and here is my public certificate), and so on. The generic serverssl profile will not be able to validate the trust of the server's certificate, but is configured to ignore it and proceed anyway.

 

Hi guys reviving this one, this also my challenge right now!