[ 
https://issues.apache.org/jira/browse/KNOX-3359?focusedWorklogId=1028985&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1028985
 ]

ASF GitHub Bot logged work on KNOX-3359:
----------------------------------------

                Author: ASF GitHub Bot
            Created on: 09/Jul/26 18:54
            Start Date: 09/Jul/26 18:54
    Worklog Time Spent: 10m 
      Work Description: moresandeep merged PR #1291:
URL: https://github.com/apache/knox/pull/1291




Issue Time Tracking
-------------------

    Worklog Id:     (was: 1028985)
    Time Spent: 3h  (was: 2h 50m)

> 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: 3h
>  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)

Reply via email to