[
https://issues.apache.org/jira/browse/KNOX-3085?focusedWorklogId=953907&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-953907
]
ASF GitHub Bot logged work on KNOX-3085:
----------------------------------------
Author: ASF GitHub Bot
Created on: 23/Jan/25 15:53
Start Date: 23/Jan/25 15:53
Worklog Time Spent: 10m
Work Description: pzampino merged PR #988:
URL: https://github.com/apache/knox/pull/988
Issue Time Tracking
-------------------
Worklog Id: (was: 953907)
Time Spent: 1h 20m (was: 1h 10m)
> Metadata API should return the certificate chain (if any) instead of only the
> configured Knox instance certificate
> ------------------------------------------------------------------------------------------------------------------
>
> Key: KNOX-3085
> URL: https://issues.apache.org/jira/browse/KNOX-3085
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server
> Affects Versions: 2.1.0
> Reporter: Philip Zampino
> Assignee: Philip Zampino
> Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Currently if you hit the Knox metadata API, it will return the
> locally-configured Knox certificate. This works great if there is nothing
> between the client and Knox. When a LB is in the middle, the returned
> certificate is incorrect. The certificate that should be returned is one for
> the endpoint that is accessed. This means we should try to return the LB
> certificate if there is a LB.
> Since we know what URL was accessed to hit the metadata API, Knox itself
> should be able to grab the certificate chain for that host:port and return
> the PEM and JKS version of it. This will require basically doing an `openssl
> s_client -connect host:port` from Java and converting into the correct
> format. Conveniently, the Knox CLI has something like this today that
> downloads the Knox certificate. We should be able to reuse the same logic in
> the metadata API and return the correct certificate information.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
