Forum Discussion
NimbostratusSSL Offload for Adobe Connect
I tried to post this on the Advanced Design forum, but I was getting errors. I apologize if this is the wrong place.
I have the need to configure SSL Offload for Adobe Connect v9. I have followed the F5 design guide for Adobe Connect, but things are not working exactly as they should. Adobe support seems to think it's an SSL issue. The last thing left for me to do is tweak my clientssl profile. I dug up the Adobe guide for configuring stunnel on actual servers should traffic be hitting them ENCRYPTED. My guess is I need to translate these configuration options as closely as possible in my clientssl profile. Here are the configuration parameters from the documentation:
; Protocol version (all, SSLv2, SSLv3, TLSv1)
sslVersion = all
fips = no
; Some performance tunings
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
TIMEOUTclose=0
options = DONT_INSERT_EMPTY_FRAGMENTS
[https‐vip]
; incoming vip for https (This is to secure Web)
; ip address that resolves to the ConnectProHost (Web App FQDN).
; listens on port 443
accept = 123.123.123.1:443
; When stunnel is on the same box, leave the below IP address as 127.0.0.1
; send the unencrypted request to port 8443
connect = 127.0.0.1:8443
; Certificate information for Connect.
; This assumes you put the cert and key in the root folder of stunnel
cert = AppServer CertificateNameHere.pem
key = AppServer CerificateKeyNameHere.pem
ciphers = ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH
My guess is I need to implement the Protocol Version, Performance Tunings, and ciphers section in my profile. Any SSL gurus out there know the best way to do this?
Many thanks in advance...
2 Replies
- Kevin_Stewart
Employee
In the absence of stunnel does the app listen on an SSL (encrypted) port? If so you need a server SSL profile applied to the BIG-IP virtual server. Otherwise, take a look at the connection between the client and BIG-IP and the BIG-IP and server. Does anything ever reach the server? If not your problem is likely on the client side (LTM and/or client SSL configuration). If you see packets to the server but it's failing then the problem is likely on the server side (pool, SNAT, server SSL profile, etc.). If you still suspect it's an SSL issue, you can watch the SSL negotiation from the shell using SSLDUMP. Here's a pretty common command line for this:
ssldump -k -AnNd -i 0.0 port 443
Where:
-k is the physical path to the private key used in the client SSL profile
-AnNd is a bunch of options that tell SSLDUMP to decrypt the data and not try to resolve ports to names
-i 0.0 is the listening interface. 0.0 is ALL interfaces
port 443 is the filter. SSLDUMP requires a filter.
If you can run that on whichever side of the connection you've determined is the problem and report back the results we may be able to help interpret. 
jlarosa_44289At this point I'm actually working with support. I've uploaded various pcap and ssldump outputs for analysis. I'll keep you posted.
