Broken WSS with LetsEncrypt certificates
Hello,
I've been trying to migrate our existing FOP2 installation from traditional SSL certificates to LetsEncrypt, but I am unable to get the WSS connection on port 4445 to work.
The cert/key works fine for the nginx installation and the same exact fullchain.pem/privkey.pem are referenced in fop2.cfg. I've performed an upgrade to the latest version of FOP2 but this made no apparent difference.
I noticed that in previously raised discussions on this matter there was a suggestion that SAN certificates might be a problem, so despite the previous working certificate being of this type I tried generating a dedicated LetsEncrypt certificate just for this server with only the single name attached, but the problem persists.
None of the previous topics on this matter have any resolution or fix mentioned, has anyone managed to get this working with LetsEncrypt?
This is the output of testssl when the letsencrypt certificate/key are configured (domain/IPs redacted), it doesn't seem to detect it as an SSL enabled service at all:
###########################################################
testssl 3.0.8 from https://testssl.sh/
This program is free software. Distribution and
modification under GPLv2 permitted.
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!
Please file bugs @ https://testssl.sh/bugs/
###########################################################
Using "OpenSSL 3.0.11 19 Sep 2023 (Library: OpenSSL 3.0.11 19 Sep 2023)" [~81 ciphers]
on mentok:/usr/bin/openssl
(built: "Oct 23 17:52:22 2023", platform: "debian-amd64")
Start 2024-04-28 12:16:36 -->> A.B.C.D:4445 (switchboard.EXAMPLE.co.uk) <<--
rDNS (A.B.C.D): A-B-C-D.EXAMPLE.co.uk.
A.B.C.D:4445 doesn't seem to be a TLS/SSL enabled server
The results might look ok but they could be nonsense. Really proceed ? ("yes" to continue) --> yes
Service detected: Couldn't determine what's running on port 4445, assuming no HTTP service => skipping all HTTP checks
Testing protocols via sockets except NPN+ALPN
SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 not offered
TLS 1.1 not offered
TLS 1.2 not offered
TLS 1.3 not offered
You should not proceed as no protocol was detected. If you still really really want to, say "YES" --> no
###########################################################
Answers
Well I've continued to work on this problem and managed to find a reasonable workaround/hack: turn off SSL for the websocket service and stick it behind an nginx reverse proxy to handle that part.
I removed reference to the certificate/key in fop2.cfg, and in my nginx config I added something along these lines:
Then added an iptables rule like so:
iptables -t nat -A PREROUTING -i <inbound interface> -p tcp --dport 4445 -j DNAT --to-destination :4444
The fop2 websocket service still listens on port 4445, but inbound connections for that port are caught by the iptables rule and forwarded to port 4444 instead where nginx handles them. nginx handles the SSL part and then proxys the connection to port 4445 on localhost, and since this traverses the loopback interface the iptables rule doesn't affect it so it hits the fop2 service as normal. This part might not be necessary, I did it because I assumed changing the bind port in fop2.cfg would probably also affect the port it pushes to your browser to make the websocket connection. Maybe someone else could iterate and improve on this.
I'd still be interested to know if there's a proper way to get this working without having to resort to such hacks though.
I believe was able to get able to get a LetsEncrypt cert working by changing the encryption method from the default eclipse to RSA. If you're still looking maybe give that a try?