on 16-Apr-2019 07:07
The idea behind this feature is to allow BIG-IP to sniff into SSL connections to any Internet destination that goes through it whilst preserving client's trust of the destination. When this feature is enabled, BIG-IP uses a pre-installed CA set under proxy-ca-cert (CA Certificate in the GUI) that is also trusted by client's browser and BIG-IP pretends to be the Internet destination by re-signing SSL certificates on the fly with the aforementioned CA and using public key from CA configured under cert on BIG-IP. The client trusts the connection and is unaware of BIG-IP's presence. The most common use case is Secure Web Gateway (SWG), although neither APM nor SWG are needed to deploy SSL Forward Proxy functionality. LTM is enough.
Actual capture used for below explanation is attached to this article below (and here ssl-forward-sample-3.pcap )
Upon Client Hello sent by Client BIG-IP rushes to open new connection and completes server-side SSL handshake:
Server-side handshake completes on frames 17-18 and and BIG-IP immediately resumes and completes Client-side handshake. Note: The reason why BIG-IP waits for server-side handshake to complete first is because BIG-IP uses server-side certificate information to generate a custom certificate that will be sent to Client on client-side.
The most interesting bit here is BIG-IP's Certificate message sent on frame 20 to Client as it contains the custom Certificate generated by BIG-IP:
We can see there are 2 Certificates:
CA Certificate (proxy-ca-cert) is the Certificate Authority (CA) that signs the newly created custom certificate and is supposed to be trusted by Client to confirm BIG-IP's custom (dynamically generated) certificate can be trusted too.
We can immediately work out that the 2nd certificate is default.crt just by matching its serial number which is unique for each issuer:
However, the first certificate looked a mystery to me until I found where all the pieces came from. The serial number looks randomly generated to me as it doesn't match (not even close to any of the certificates above):
The Issuer field, which shows information about who signed the certificate, shows that default.crt was the one who signed BIG-IP's custom certificate:
Certificate generation date (notBefore) is copied from server1.crt but expiry date (notAfter) is calculated based on cert-lifespan (Certificate Lifespan in the GUI) which by default is 30 days added to time custom certificate was generated:
Subject fields, which shows information about the current certificate, is copied and identical to information on server1.crt:
And finally, the public key is copied from cert field (ltm2CA.crt).
Notice they are the same:
That's enough information for now.
- I asked around and the only touch-point I was referred to was this F5 Support article - https://support.f5.com/csp/article/K81031320
I scanned it and don't see any proper 'tips' per your request.
I do see details around how long Support will continue in the "Technical Support" section there.
What sort of tips or advice are you interested in?