search

keycloak / keycloak

Open Source Identity and Access Management For Modern Applications and Services
https://www.keycloak.org
Apache License 2.0
22.09k stars 6.59k forks source link

Support Caddy as a Reverse Proxy Provider for Client Certificate Authentication #20761

Open henryreed opened 1 year ago

henryreed commented 1 year ago

Description

Caddy is a relatively new web server. To support Caddy as a reverse proxy provider for client certificate authentication, the Keycloak team will need to add support for Base64-encoded DER certificates. As of right now, Keycloak only supports PEM files.

Discussion

No response

Motivation

While Caddy is a new web server, it is not uncommon. Caddy has been used by Cloudflare in their implementation of their MITM protection service; separately, Let's Encrypt considers Caddy's "implementation of ACME to be the gold standard of ACME clients," per Wikipedia. Supporting Caddy would be a great addition to Keycloak as more enterprises consider Caddy for their web server needs.

Details

Per the lead developer, Caddy will not support passing PEM-formatted certificates in HTTP headers, and instead only supports B64-encoded DERs; therefore, the standard Apache, Nginx and HAProxy provider options do not work with Caddy. Caddy also does not automatically construct a certificate chain when passing a client certificate, similar to how Nginx currently works (Keycloak documentation mentions this here under "Configuring the NGINX provider").

My ask is to add Caddy as a reverse proxy provider. This would be nearly identical to the Nginx provider, except Keycloak must accept B64'ed DER certificates. As of right now, if a DER certificate is passed to Keycloak via Caddy, the following error occurs, as the format lacks the expected new line characters:

ERROR [org.keycloak.services] (executor-thread-50) org.keycloak.common.util.PemException: org.bouncycastle.jcajce.provider.asymmetric.x509.CertificateFactory$ExCertificateException: parsing issue: 
long form definite-length more than 31 bits: java.security.GeneralSecurityException: org.keycloak.common.util.PemException: org.bouncycastle.jcajce.provider.asymmetric.x509.CertificateFactory$ExCertificateException: parsing issue: long fo
rm definite-length more than 31 bits
hslatman commented 1 year ago

Implementing support for the HTTP Client-Cert header might be the way to go.

henryreed commented 1 year ago

Per the issue the linked issue in Caddy, yes, I believe that is the way to go.