Troubleshooting stunnel on Adobe Connect
The preferred means of SSL for on-premise Adobe Connect deployments is to offload it to an appliance; all high-end hardware-based load balancing devises are also SSL accelerators. In certain circumstances, such as in labs and for small deployments, and for use of static IPs on AMS Meeting VIPs on AWS, stunnel can be used directly on the server. Should stunnel fail to install properly and function, audit your stunnel configuration according to this guide: https://blogs.connectusers.com/connectsupport/adobe-connect-ssl-guide/
Here are some additional troubleshooting tips:
The certificate must be in .pem format. if it is .pfx, then see this technote for information about converting the certificate: https://blogs.connectusers.com/connectsupport/connect-on-premise-ssl-convert-pfx-to-pem-format/
The most common issues with stunnel deployments with Adobe Connect tend to be in the format of the .pem file. To test the pem, simply rename it to .cer and double-click on it to see if it works and to inspect the certificate chain.
Check that the .pem is saved in UTF-8 encoding.
The .pem may have the intermediate and root CA cert in the same file, but they need to be in the right order: Public cert, Intermediate, Root CA
Look for stray characters or carriage returns particularly at the beginning and end of the pem file. It should look similar to this:
Note that for the ACTS server, the stunnel; pool should be 9002:; acts server SSL / HTTPS
accept = 10.1.1.1:443
connect = 127.0.0.1:9002
cert = C:\Connect\stunnel\certs\public_certificate_acts-server.pem
key = C:\Connect\stunnel\certs\private_key_acts-server.key
;configure ciphers as per your requirement and client support.
;this should work for most:
ciphers = TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!3DES
If the path to the certificate does not resolve in stunnel, try a relative path without quotes in the stunnel.conf. Some builds of stunnel will use a relative path.
And if you are setting up is a test lab installation wherein you are using hosts files for name resolution make certain the FQDNs are correct including case. BSD-based OS’s are case sensitive, while Windows is not. That one discrepancy has been tripping up administrators since the 90’s.