KNOX-3359 - Support Single-Purpose EKU Certificates

[moresandeep]

(It is very important that you created an Apache Knox JIRA for this change and that the PR title/commit message includes the Apache Knox JIRA ID!)

KNOX-3359 - Support Single-Purpose EKU Certificates

Public CAs are retiring dual purpose certificates that carry both serverAuth and clientAuth Extended Key Usages. This change allows Knox to use two separate keystores, one for its inbound TLS server identity (serverAuth only) and one for its outbound mTLS client identity (clientAuth only).

What changes were proposed in this pull request?

• gateway.tls.single.eku.enabled — new toggle that activates single-EKU mode. Off by default all existing behavior is unchanged when it is off.
• GatewayConfigImpl / GatewayConfig — new config accessors for the HTTP client keystore path, type, alias, and truststore, startup validation (validateSingleEkuConfig) that fails fast if any prerequisite is missing or misconfigured (wrong alias type, wrong EKU, missing truststore). Knox refuses to start rather than silently falling back to the server identity.
• DefaultKeystoreService.getKeystoreForHttpClient() / DefaultAliasService.getHttpClientKeyPassphrase() — load the dedicated client-identity keystore using the configured path, type, and alias.
• DefaultHttpClientFactory.createSSLContext() — when single-EKU is on and two-way SSL is active, loads the client keystore instead of the gateway server keystore.
• JettySSLService - enforce that the server keystore alias carries only serverAuth in single-EKU mode.
• gateway.httpclient.twoWaySsl.enabled — new global flag to activate outbound mTLS across all dispatches without requiring use-two-way-ssl="true" on every service definition. Automatically defaults to true when gateway.tls.single.eku.enabled=true, so enabling single-EKU mode is a single config change with sane defaults.

How was this patch tested?

Unit Tests

• Unit tests added for GatewayConfigImpl, DefaultKeystoreService, DefaultAliasService, JettySSLService, and DefaultHttpClientFactory covering the single-EKU happy path, wrong-passphrase fail-closed, one-way SSL guard (no client cert presented), and the global flag OR-ing with the per-dispatch parameter.

Manual Tests

Tested the following scenarios

Happy path: clientAuth cert + basic auth → 200, backend sees knox-client

curl -sk --cert /Users/smore/projects/Cloudera/CDPD-103449-Knox-Single-EKU/testing/certs/curl-client.crt --key /Users/smore/projects/Cloudera/CDPD-103449-Knox-Single-EKU/testing/certs/curl-client.key -u guest:guest-password https://localhost:8443/gateway/sandbox/testmtls/hello

{"service":"test-https-backend","path":"/hello?user.name=guest","authenticated_client_cn":"knox-client","message":"mTLS OK -- backend saw your client certificate"}

No client cert → inbound TLS handshake rejected (client.auth.needed=true)

curl -iku guest:guest-password https://localhost:8443/gateway/sandbox/testmtls/hello-

curl: (56) LibreSSL SSL_read: LibreSSL/3.3.6: error:1404C412:SSL 
routines:ST_OK:sslv3 alert bad certificate, errno 0

serverAuth-ONLY cert presented as inbound client cert → rejected (EKU check)

curl -ik --cert /Users/smore/projects/Cloudera/CDPD-103449-Knox-Single-EKU/testing/certs/knox-server.crt --key /Users/smore/projects/Cloudera/CDPD-103449-Knox-Single-EKU/testing/certs/knox-server.key -u guest:guest-password https://localhost:8443/gateway/sandbox/testmtls/hello

curl: (55) Send failure: Broken pipe

Valid client cert but NO credentials → TLS ok, HTTP 401 from Knox'

curl -ik --cert /Users/smore/projects/Cloudera/CDPD-103449-Knox-Single-EKU/testing/certs/curl-client.crt --key /Users/smore/projects/Cloudera/CDPD-103449-Knox-Single-EKU/testing/certs/curl-client.key https://localhost:8443/gateway/sandbox/testmtls/hello

HTTP/1.1 401 Unauthorized
Date: Wed, 01 Jul 2026 18:56:23 GMT
WWW-Authenticate: BASIC realm="application"
Content-Length: 0

Integration Tests

Added new integration tests

UI changes

NA