Adobe Connect Support Blog

November 1, 2019 /ACTS /Clustering /Content /General /Meeting /Security /SSL /

End to End SSL Adobe Connect On-premise Cluster

In some cases it may be necessary to add SSL behind a Hardware-based Load Balancing Device and SSL Accelerator (HLD) handling Adobe Connect traffic. This article describes a model for implementation. This article is intended as a supplement to published Adobe Connect installation documentation:

The conventional cluster:

The conventional model for SSL is explained and depicted here: https://blogs.connectusers.com/connectsupport/adobe-connect-clusters/

The conventional cluster architecture secures SSL on 443 at the HLD VIP and points back to a server pool in the clear on ports 8443 for HTTP and 1935 for RTMP. The assumption is that the traffic behind the HLD is segregated and impenetrable, also many enterprises want this in the clear for monitoring purposes. The conventional architecture detailed in the tech-note referenced above is summarized and depicted here below in the following diagram:

  • Adobe Connect Application HTTPS VIP: connect.adobe.com: 10.10.10.1:443 points to Adobe Connect server pools: 192.168.0.1: 8443 and 192.168.0.2: 8443 using the Round Robin algorithm without session-awareness and without the Nagle’s algorithm (non-sticky or non-session-aware)
  • Adobe Connect Meeting RTMPS VIP: meeting1.adobe.com: 10.10.10.2:443 points to the first Meeting server, meeting1: 192.168.0.1: 1935
  • Adobe Connect Meeting RTMPS VIP: meeting2.adobe.com: 10.10.10.3:443 points to the second Meeting server, meeting2: 192.168.0.2: 1935
  • ACTS HTTPS VIP: acts.adobe.com: 10.10.10.4:443 points to the ACTS server for HTML5 rendering, 192.168.0.3:9002

See how SSL is implemented at the HLD VIP and traffic between the HLD and the pools is in the clear.

The end to end SSL cluster:

In order to secure the pools behind the HLD, you must install stunnel on the servers and follow the instructions in this technote to set up the servers to secure traffic locally: https://blogs.connectusers.com/connectsupport/adobe-connect-ssl-guide/

The result of adding stunnel VIPs to the server behind the HLD will look like this:

  • Adobe Connect Application HTTPS VIP on the HLD: connect.adobe.com: 10.10.10.1:443 points to stunnel VIPs on Adobe Connect server: 192.168.0.1: 443 and 192.168.0.3: 443 using the Round Robin algorithm without session-awareness and without the Nagle’s algorithm (non-sticky or non-session-aware)
    • Stunnel VIP on server: 192.168.0.1:443 to pool localhost 8443
    • Stunnel VIP on server: 192.168.0.3:443 to pool localhost 8443
  • Adobe Connect Meeting RTMPS VIP on the HLD: meeting1.adobe.com: 10.10.10.2:443 points to the stunnel VIP meeting1: 192.168.0.2: 443
    • Stunnel VIP on server: 192.168.0.2:443 to pool localhost 1935
  • Adobe Connect Meeting RTMPS VIP on the HLD: meeting2.adobe.com: 10.10.10.3:443 points to the stunnel VIP meeting2: 192.168.0.4: 443
    • Stunnel VIP on server: 192.168.0.4:443 to pool localhost 1935
  • ACTS HTTPS VIP on the HLD: acts.adobe.com: 10.10.10.4:443 points to the stunnel VIP on the ACTS server, 192.168.0.5:443
    • Stunnel VIP: 192.168.0.5:443 to pool localhost 9002

Notice with the above end to end SSL model, the HLD points to stunnel VIPs on the servers on 443 as though they were pools. In fact they are treated as pools from the perspective of the HLD.  The stunnel VIPs point to localhost pools; they are simply using localhost on the correct port: 8443, 1935 or 9002 depending on the protocol and server.  Since stunnel requires FQDNs, I have added an additional IP to each ACS server to facilitate stunnel VIPs for both HTTPS and RTMPS.

Withing each stunnel.conf file the VIPs will look like this:

; application server1 SSL / HTTPS
[https-vip]
accept = 192.168.0.1:443
connect = 127.0.0.1:8443
<snip>
; meeting1 SSL / RTMPS
[rtmps-vip]
accept = 192.168.0.2:443
connect = 127.0.0.1:1935

; application server2 SSL / HTTPS
[https-vip]
accept = 192.168.0.3:443
connect = 127.0.0.1:8443
<snip>
; meeting2 SSL / RTMPS
[rtmps-vip]
accept = 192.168.0.4:443
connect = 127.0.0.1:1935

; acts SSL / HTTPS
[https-vip]
accept = 192.168.0.5:443
connect = 127.0.0.1:9002

Conclusion:

This configuration is not considered a best practice architecture for performance. It is outlined here in case it is required for compliance. The best practice is the conventional cluster model with the zone behind the HLD segregated to avoid compromise. Nevertheless, this model has been employed successfully by customers in the Adobe Connect enterprise.

ACTS, Clustering, Content, General, Meeting, Security, SSL

Frank DeRienzo, MBA

PRINCIPAL TECHNICAL ACCOUNT MANAGER

Join the discussion