[
https://issues.apache.org/jira/browse/KNOX-3359?focusedWorklogId=1027866&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1027866
]
ASF GitHub Bot logged work on KNOX-3359:
----------------------------------------
Author: ASF GitHub Bot
Created on: 01/Jul/26 19:27
Start Date: 01/Jul/26 19:27
Worklog Time Spent: 10m
Work Description: moresandeep opened a new pull request, #1291:
URL: https://github.com/apache/knox/pull/1291
(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](https://issues.apache.org/jira/browse/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
Issue Time Tracking
-------------------
Worklog Id: (was: 1027866)
Remaining Estimate: 0h
Time Spent: 10m
> Support Single-Purpose EKU Certificates
> ---------------------------------------
>
> Key: KNOX-3359
> URL: https://issues.apache.org/jira/browse/KNOX-3359
> Project: Apache Knox
> Issue Type: New Feature
> Components: Server
> Reporter: Sandeep More
> Assignee: Sandeep More
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h1. Background
> Knox currently supports a single certificate per host. This certificate
> carries both the serverAuth and clientAuth Extended Key Usages (EKUs),
> meaning the same key and certificate is used whether the service running on
> the host is acting as a TLS server or as a client in a mutual-TLS (mTLS)
> handshake.
>
> Industry standards and public CAs (like DigiCert) are sunsetting multi-use
> certificates, making Knox's current requirement for dual serverAuth and
> clientAuth EKUs difficult to manage.
> h1. Overview:
> Knox will need separate keystores and truststores for client authentication
> and server authentication.
> # Keystores:
> *
> -- Knox to assert its identity as a server
> -- Knox to assert its identity as a client (to downstream services)
> 2.Truststores:
> *
> -- Clients asserting identity to Knox
> -- Servers asserting identity to Knox
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
