SSL offloading with port 8443

[TMH]

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 ? 

[mihaic]

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.

[TMH]

I 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.

[TMH]

 

@Paulius 

What i had configured with virtual server :

Name:xxxx

Type:Standard

Source:0.0.0.0.

Destination:x.x.x.x

Port:Other 8443

Protocol:TCP

Protocol Profile(client):Tcp

Protocol Profile (Server):use client profile

SSL profile client: (name of profile ssl 8443)

SSL profile server:None

All the other options is none.

Default Persistence Profile:source_add

Fallback Persistence Profile:none

And for SSL client Profile:

Certificate key chain: i added the certificate and key and chain that I already imported in certificate list.

correct me if there's something wrong or missing .

[Paulius]

@TMH Based on the description and without being able to see which cert and key pair are being used I would say this is configured correctly and should work. If you are still having issues you might take a QKVIEW and upload it to iHealth to see if anything pops up on that.

[wlopez]

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.

[wlopez]

As Paulius commented, you need to figure out if your pool members are expecting encrypted traffic.

You can validate it via ssh with some curl commands from the F5 (curl -Ivvvk https://<PoolMember_IP>:8443), or by adding tcp, http and https health monitors to the pool and then view which ones pass or fail.

If the servers on the pool are setup to encrypt traffic on port 8443, you definitely need to add a server ssl profile to the virtual server.

If application traffic is http based at the application layer, you can also add an http profile to the virtual server and monitor the http request statistics for the pool. If the ssl handshake between the F5 (acting as client towards the pool members ssl encryption) and the pool members are working correctly, you should see the http requests stats on the pool increment with every hit to the virtual server.

[TMH]

@wlopez @Paulius 

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.