Forum Discussion

jevinxu's avatar
jevinxu
Icon for Nimbostratus rankNimbostratus
Mar 30, 2021
Solved

https end to end

Hi,

 

We are looking at solution to use f5 as load balance with a few IIS webServer sitting behind as target pool. IIS webServers are in private network, while LB will be internet facing (therefore LB will have public IP). The public URL/FQDN to internet is https, and we want f5 could passthrough/proxy to our backend webServers via https as well. We have strong need to have our webServer application only serving https due to company policy. Could someone explain which solution/configuration we could use to meet this requirement.

 

Speically about the ssl/tls certificates, would be possible to use self-signed certificate between LB and backend webServer, while only buy certificate for LB for https between end user and LB?

 

I am quite new to f5, would be highly appreciated if someone could provide some reference design/configuration.

 

Regards!

  • If your company security policy does not allow F5 to decrypt and re-encrypt the traffic before sending it to the backend servers, then you will need to configure SSL and the certifications on the backend server itself as there will be no SSL sessions between F5 and the server (pass-through scenario, see here: https://support.f5.com/csp/article/K65271370), in other words F5 will not participate in the SSL process.

     

    However, the number of certificates you need is not relative to which scenario you are using, as it depends on the number of domains you are publishing not on the number of servers you are using, e.g if your domain is www.example.com and it's served by five servers then you only need to buy one cert and deploy it to the five servers if using the pass-through setup. But if SSL is terminated on F5 you'll only need to deploy the cert on F5 and use self-signed certs between F5 and the five servers.

     

    Hop that helps

     

     

3 Replies

  • If your company security policy does not allow F5 to decrypt and re-encrypt the traffic before sending it to the backend servers, then you will need to configure SSL and the certifications on the backend server itself as there will be no SSL sessions between F5 and the server (pass-through scenario, see here: https://support.f5.com/csp/article/K65271370), in other words F5 will not participate in the SSL process.

     

    However, the number of certificates you need is not relative to which scenario you are using, as it depends on the number of domains you are publishing not on the number of servers you are using, e.g if your domain is www.example.com and it's served by five servers then you only need to buy one cert and deploy it to the five servers if using the pass-through setup. But if SSL is terminated on F5 you'll only need to deploy the cert on F5 and use self-signed certs between F5 and the five servers.

     

    Hop that helps

     

     

    • jevinxu's avatar
      jevinxu
      Icon for Nimbostratus rankNimbostratus

      Thanks Amine, it definitely help us. Definitely I prefer passthrough solution.

       

      If we go with option let F5 decrypt and re-encrypt toward target IIS Servers, following 2 questions would need your help"

      1. Is there any special certification requirement F5 require with self-signed certificate (pls be aware we have Windows IIS Server, so .PFX i would guess)?
      2. What certificate would end user see from web brewer? I assume it should be the authorized certificate associated with the domain www.example.com we buy from provider, right? A.k.a those self-signed certificate should not vivisble to end user webbroswer, right?

       

      Thanks in advance!

       

      Regards!

      • By default, F5 does not care if the server ssl certificate is self signed or not. For your clients, you'll need to import your valid certificate into F5, many formats are supported including IIS pkcs12. This certificate along with its private key and any intermediate certificate your provider is using will be bound to the mentioned client Ssl profile. And this is the certificate that will be presented to the browser.