Class HaProxySslClientCertificateLookup

java.lang.Object
org.keycloak.services.x509.AbstractClientCertificateFromHttpHeadersLookup
org.keycloak.services.x509.HaProxySslClientCertificateLookup
All Implemented Interfaces:
Provider, X509ClientCertificateLookup

public class HaProxySslClientCertificateLookup extends AbstractClientCertificateFromHttpHeadersLookup
Extracts X.509 client certificates forwarded by an HAProxy reverse proxy.

HAProxy is not RFC 9440 compliant as it is currently only possible to Base64 encode the entire chain, whereas RFC 9440 expects each certificate to be Base64 encoded individually, surrounded by `:` and provided as a CSV when multiple values exist. If HAProxy adds support generating headers in this format, then it will be possible to deprecate and remove this provider in favor of Rfc9440ClientCertificateLookup haproxy/#2235.

Header values must be base64-encoded DER certificates, matching the output of HAProxy's ssl_c_der,base64 and ssl_c_chain_der,base64 sample fetches.

Two modes are provided for reading the certificate chain:

  • Single header (via sslCertChain): the entire chain is in one header as concatenated DER certificates, base64-encoded. Only the first certificateChainLength certificates are loaded. Example HAProxy config:
     http-request set-header Client-Cert %[ssl_c_der,base64]
     http-request set-header Client-Cert-Chain %[ssl_c_chain_der,base64]
           
  • Indexed headers (deprecated, based upon sslCertChainPrefix): each chain certificate is in a separate header named {prefix}_{index}, e.g. Client-Cert-Chain_0, Client-Cert-Chain_1. This is problematic when more than one intermediate cert exists as HAProxy does not provide a built-in mechanism to define a header per intermediate cert in the chain, so this will only work as expected if a single intermediate certificate exists in the chain. Example HAProxy config:
     http-request set-header Client-Cert %[ssl_c_der,base64]
     http-request set-header Client-Cert-Chain_0 %[ssl_c_chain_der,base64]
           
Since:
3/27/2017
Version:
$Revision: 1 $
Author:
Peter Nalyvayko