https and separate port VS
I have a request with https://test.com:1234 and pool members are test1:1234 and test2:1234. I can only create a Virtuall server with other port. How does F5 understand the request is for https as I have to choose standard Virtual Server and other port.
Does this VS require a http profile and Client and server SSL. What is the behaviour with and without http profile and SSL profiles
1)VS with http profile and no server/client SSL profiles. I see a error
2)VS with no http profile and no ssl profile. Works with TCP
3)VS with http profile and SSL server/client profiles, its not secure
InquisitiveMai The following are your questions and the associated answers.
1)VS with http profile and no server/client SSL profiles. I see a error.
1A) The reason you see an error is because without an SSL client profile the F5 cannot look at the encrypted HTTPS traffic which is where the HTTP profile is attempting to look.2)VS with no http profile and no ssl profile. Works with TCP.
2A) This works beacuse the F5 passes the traffic to the destination without doing anything with the connection except for adjusting the TCP session controls.3)VS with http profile and SSL server/client profiles, its not secure
3A) This is secure but most likely you are receiving a warning that either the SSL certificate that you are seeing isn't from a trusted certificate authority or that the name you entered in your browser doesn't match the CN of the SSL certificate that you are using. Hopefully the attached curl output shows you the difference.In the attached images you will see capture_1 which is me going to https://www.example.com/ with the back and forth for the SSL communication with zero issues. In capture_2 you see me going to https://93.184.216.34/ without the "-k" flag so I receive an error that Host: 93.184.216.34 doesn't match any of the names on the SSL certificate and doesn't proceed any further with the SSL connection because of that. And finally in capture_3 you see me make a request to https://93.184.216.34/ with the "-k", which ignores SSL name missmatches, and continues along with the SSL connection and it should look almost identical to capture_1 with really the only difference being the Host field that is sent and then ultimately a 404 because I didn't provide a Host that the destination server is configured to listen for. Just because you receive the SSL error/warning doesn't mean that the SSL connection isn't secure it just means you should remain alert because this could be an incorrect destination that someone has gained control of and is doing things they shouldn't but the connection is still secure using the provided SSL certificate.