feat: Add OCSP support to federated environment #67
Conversation
Adds Online Certificate Status Protocol (OCSP) support to the federated Openfire setup: - Add certificate generation script with full PKI hierarchy - Add certificate import script for Openfire keystores - Implement OCSP responder service via Docker compose - Update documentation with OCSP usage instructions The -o flag can now be used with start.sh to enable OCSP support.
viv
force-pushed
the
feature/conditional-ocsp-deployment
branch
from
4a9ef73 to
6656c6c
Compare
- Update OCSP URL in certificate generation from IP to domain name - Add OCSP hostname to docker-compose network configuration - Document useful hosts file entries in README.md The changes make it easier to test OCSP locally with clients by using domain names that can be mapped in host files.
There was a problem hiding this comment.
It's an impressive amount of work, thanks! I've left a bunch of nit-picky comments.
If this is all ironed out, are you planning to add OCSP support like this to all environments (like cluster_with_federation and maybe the ones that don't do federation if we want to be able to test simple client support)?
Prior to this the OCSP responder used 172.50.0.30. This conflicts with an example given in the readme, which uses the same IP address describing how to add a third node to the setup. This change avoids confusion, and keeps things consistent if we ever decide to copy this to the other configurations (eg clustering_with_federation).
Cert generation and import scripts now support any number of XMPP servers and use more intuitive naming for the certificates. This will make it easier to move cert generation to other configurations. Maybe promoting this to a top-level script to generate certs in all scenarios.
I considered adding IPv6 support to the OCSP responder but it would add more files and complexity for (I think) little gain. Instead this change keeps the OCSP responder on IPv4 only, but makes sure it's properly configured in the hosts file even when using the -6 flag. The OCSP responder will always use IPv4, other services will be able to reach it via IPv4 regardless of whether they're using IPv6 for their own communication.
|
I think I've addressed all of the comments. I'm wondering about "promoting" some of this up to be useful in other the scenarios/configurations, but I think that might too much at the moment. I'd also like a better approach for the truststore, I thought about pulling them on-demand (maybe in |
This possibly should go in a different PR (to not be a blocker for this one). What problem do you want to fix with another approach? |
This file is being added to Openfire so I'm porting it into this project as we use a copy of the security directory and overwrite the original.
To pick up the setting in this new file, and the new system property (jdk.tls.server.enableStatusRequestExtension=true), we must also use the updated openfire.sh start script which includes the new file and sets the mentioned system property. This will happen naturally when those changes make it into the Openfire Docker image. Until then you can recreate this behaviour by adding the following to xmpp1 and xmpp2:
```
environment:
JAVA_TOOL_OPTIONS: >
-Djava.security.properties=/var/lib/openfire/conf/security/java.security
-Djdk.tls.server.enableStatusRequestExtension=true
```
I think this is a reasonable default given the purpose of this project.
The truststore will become out of date, I manually copied the updated stores from Openfire with this PR so it will be good for a while but it feels a bit clunky. |
The OCSP responder in OpenSSL (in Alpine) only supports IPv4 so I've used socat as a proxy to listen in IPv4 and IPv6 then forward to the OCSP responder on localhost using IPv4.
viv
force-pushed
the
feature/conditional-ocsp-deployment
branch
from
c50f24c to
c2b1dd6
Compare
Added the openssl ocsp flag to ignore malformed requests. The OCSP responder now continues running instead of terminating upon receiving a malformed request. When testing connectivity it is useful to be able to curl http://ocsp-responder:8888. Previous to this commit the responder would send 200 OK then exit. With this change we still get the 200 response but the responder remains active.
Apply the change from fccc330 to all other environments.
Agree, but plugins etc also outdate all the time. Lets keep it as-is for now. If we find a good way to improve on this, let's do that in a new PR. |
Adds Online Certificate Status Protocol (OCSP) support to the federated Openfire setup:
The -o flag can now be used with start.sh to enable OCSP support.