Forum Discussion
TMH
Nimbostratus
NimbostratusSSL offloading with port 8443
Hallo,
I need help to configure SSL offloading with port 8443 , i have configured a VS https with port 8443 and pool members that listen to port 8443 , i want to configure SSL certificate but no luck. Sholud i configure irule to redirect from port 443 to 8443 or its configured directly ?
mihaicMVP
If your VS is listening on 8443 you don't need to redirect.
You need to create a SSL client profile that has your SSL certificate, and chain.
https://my.f5.com/manage/s/article/K14783#2
As you do SSL offloading, your pool members don't have to do SSL anymore. Unless you want traffic between the F5 and the pool members to be encrypted also.
TMHI have already created ssl certificate and signed with CA lets say for example ABCD CA server, and then created a ssl client profile and still not working , i used to go over the previous steps with SSL offloading for virtual server 443 and its working , is there a specific options for SSL client profile for 8443 ? because when i check the certificate in the URL https://abcd:8443 the certificate shows (Local Host ) same as before a assigne the SSL Client Profile !! its like the SSL profile not really effect the virtual server certificate .
- Paulius
TMH In order to provide additional detail on why this isn't working it would be helpful to see the configuration of the virtual server and SSL client profile that is assigned to the virtual server. Purely based on the screenshot it seems like the SSL client profile being used doesn't have the trusted CA certificate in it.
wlopezCirrocumulus
Based on the configuration on your last post, you have:
A virtual server receving traffic on port 8443
A client ssl profile to encrypt traffic towards the clients
No server ssl profile to consume encryption from the backend platform on the pool
Is the platform on backend pool members encypted? If so, you'll need to add a server ssl profile to the virtual server.
In terms of the client ssl profile, you need to configure the specific ssl certificate with it's private key and Chain certificate (Issuer intermediate certificate with which the primary certificate was signed with).
Hope that helps.
- TMH
The backend pool member also using port 8443, so when i tried to add server ssl profile the url shows "can't reach this page ", now with backend servers work with port 8443 should i have server ssl profile or I shouldn't ?
- Paulius
TMH If your pool members are expecting to receive HTTPS traffic on 8443 then you would absolutely need a SSL Profile (Server) configure on the virtual server. It is possible to have the server configured to received decrypted traffic on 8443 but you would have to verify. An easy way to validate if the server is expecting HTTPS traffic is to perform a curl from the F5 directed at the server's IP on 8443. The command should very similar to the following with the appropriate informaiton filled in.
curl -Ivk "https://<server_IP>:8443/"If you know the host field that the server is listening for you can do the following instead.
curl -IvkH 'Host: <website_host>' "https://<server_IP>:8443/"After running either of the se commands you should see the SSL certificate in the output if the server is expecting HTTPS communication on this port.
- TMH
Hi, this the output of the curl command
run /util bash -c 'curl -Ivk https://xx.xx.xx.xx:8443/'
* Trying xx.xx.xx.xx...
* Connected to xx.xx.xx.xx (xx.xx.xx.xx) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=Unknown; ST=Unknown; L=Unknown; O=Unknown; OU=Unknown; CN=localhost
* start date: May 31 08:59:32 2017 GMT
* expire date: Aug 29 08:59:32 2017 GMT
* issuer: C=Unknown; ST=Unknown; L=Unknown; O=Unknown; OU=Unknown; CN=localhost
* SSL certificate verify result: self signed certificate (18), continuing anyway.
> HEAD / HTTP/1.1
> Host: xx.xx.xx.xx:8443
> User-Agent: curl/7.47.1
> Accept: */*
>
< HTTP/1.1 404
HTTP/1.1 404
< vary: accept-encoding
vary: accept-encoding
< Content-Type: text/html;charset=utf-8
Content-Type: text/html;charset=utf-8
< Content-Language: en
Content-Language: en
< Transfer-Encoding: chunked
Transfer-Encoding: chunked
< Date: Sun, 12 Mar 2023 03:44:34 GMT
Date: Sun, 12 Mar 2023 03:44:34 GMT
< Server: XXX
Server: XXX
<
*
- Paulius
TMH Based on that server response your server is expecting the connection from the F5 to the server to be HTTPS so you will need to configure an SSL server profile on the virtual server (VS) as well. You should be able to use the default SSL server profile called "serverssl" and that should do what you want it to. If you wanted to perform additional restrictions you could create a custom SSL profile (Server) and adjust the settings but the default should get you to a good spot.
- wlopez
Agree with Paulius.
With that curl output you will definitely need to add a server ssl profile to your virtual server.
Since the pool member negotiated a secure TLS 1.2 cipher suite, you should be good to go with the default profile calles 'serverssl'.
Once you do add the server ssl profile, you should be able to monitor your pool;s statistics for traffic in and out, and the http request count (if you have an htp profile on the virtual server).
In case your pool members don't have a route back trough the BigIP for client addresses, you might need to activate SNAT Automap to your virtual server.
- Paulius
TMH as wlopez you might have to enable SNAT. Now I don't agree to utilize SNAT automap and instead create a snatpool and in that snatpool add in the IP of the virtual server you are configuring and then use that snatpool for SNAT. The reason for this is sometimes if your virtual server has a significant amount of client connections you could exhaust the ports used for automap which would then cause issues with health checks and a few other things, but if you instead use a snatpool with the virtual server IP you could only cause issues with this single virtual server if the connections were high enough. If you connections are high enough you could add in multiple IPs to the snatpool to help with the port exhaustion issue.
