Description

The use case is Let's Encrypt certificates for the HTTPS url in a non-Kubernetes deployment.

The canonical way of generating the Let's Encrypt certficates is to use "certbot" cli utility (official let's encrypt tool), to generate/renew the certificate and private key.

When using certbot, the https-certificate-file and https-certificate-key-file configuration parameters of Keycloak will be set to the paths to the certbot-generated files. Those files will be overwritten when the certificate is renewed during a certbot renew operation, but keycloak will NOT reload them.

Since keycloak does not hot-reload the TLS/SSL/HTTPS , then the current alternatives solution is to

• restart keycloak entirely after a certificate renewal. The certbot renew allows for deploy hooks. In the deploy hook you can restart keycloak but that introduces some downtime every 60 days (which is the Let's Encrypt default renewal rate).
• use a reverse proxy that does the Let's encrypt renewal (ACME) like Caddy which will handle the HTTP termination itself and it's capable of performing the Let's Encrypt HTTP-01 and DNS-01 challenges itself (without certbot). This introduces yet another component.

Discussion

https://cloud-native.slack.com/archives/C056HC17KK9/p1696504180004809
#10654

Motivation

• I would simplify HTTPS deployment of keycloak specially for "short lived certificates" like the ones issued by Let's encrypt (90 days expire time, certificates renewed usually every 60 days).
• Avoids downtime during the certification renewal process. As it is today, there is downtime every 60 days , since keycloak needs to be restarted not requiring to restart keycloak to load the new certificate/ private key).
• Avoids having to introduce a let's encrypt enabled reverse proxy like Caddy .

Details

Apparently is possible in quarkus to do hot reloading of TLS / SSL certificates with HttpServerOptionsCustomizer and some non trivial use of javax.net.ssl.TrustManager

https://github.com/Hakky54/java-tutorials/blob/9a7a5532610fc383a892e2eb6c6ed5a559aec451/instant-server-ssl-reloading-with-quarkus/src/main/java/nl/altindag/server/config/ServerConfig.java#L33-L75

My proposal is to look into the above example:

• Use Quarkus own HttpServerOptionsCustomizer and HttpServerOptions to set keycertoptions and trustoptions
• Get an implementation of javax.net.ssl.KeyManager and java.net.ssl.TrustManager that is updatables
• Start a periodic check for the files modification time, on change load appropriate data into the KeyManager and TrustManager instances that were passed to Quarkus's HttpServerOptions