[
https://issues.apache.org/jira/browse/KNOX-3359?focusedWorklogId=1028977&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1028977
]
ASF GitHub Bot logged work on KNOX-3359:
----------------------------------------
Author: ASF GitHub Bot
Created on: 09/Jul/26 18:33
Start Date: 09/Jul/26 18:33
Worklog Time Spent: 10m
Work Description: moresandeep commented on code in PR #1291:
URL: https://github.com/apache/knox/pull/1291#discussion_r3553934172
##########
gateway-util-common/src/main/java/org/apache/knox/gateway/util/X509CertificateUtil.java:
##########
@@ -73,7 +76,7 @@ public class X509CertificateUtil {
* @param algorithm the signing algorithm, eg "SHA256withRSA"
* @return self-signed X.509 certificate
*/
- public static X509Certificate generateCertificate(String dn, KeyPair pair,
int days, String algorithm) {
+ public static X509Certificate generateCertificate(String dn, KeyPair pair,
int days, String algorithm, String... ekuOids) {
Review Comment:
Nope, this method does not always produce single EKU certs. In cases where
ekuOids is empty certs will be generated as they have before.
The signature does not change! it still works with 4 args (assumes ekuOids
is null) so existing calls still work. I did this to prevent yet another
duplicate overloaded method. Let me know if you think overload is better here
and I can switch it up.
Issue Time Tracking
-------------------
Worklog Id: (was: 1028977)
Time Spent: 2h 10m (was: 2h)
> 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: 2h 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)
