-
Feature Request
-
Resolution: Won't Do
-
Normal
-
None
-
None
-
None
-
Product / Portfolio Work
-
None
-
False
-
None
-
None
-
None
-
None
-
-
None
-
-
None
-
None
-
None
1. Proposed title of this feature request
Openshift Cert-Manager 1.4 TLS Secret Support
2. What is the nature and description of the request? ( List the functional requirements )
The functional requirement is for OpenShift to recognize when a root CA has been included under ca.crt on a TLS object, and append it to the beginning components of the certificate chain stored in tls.crt. The observed behavior currently is that is only installs the contents of tls.crt and the root chain is not included.
https://cert-manager.io/docs/concepts/certificate/
"When a certificate is issued by intermediates of the CA and the Issuer knows the intermediates, the content of tls.crt will be a resulting certificate followed by a certificate chain. The certificate chain doesn’t include a root CA certificate, as it is stored in ca.crt."
3. Why does the customer need this? (List the business requirements here)
It appears that cert-manager 1.1 currently provides tls secrets that are compatible with the OpenShift Container Platform.
With that said it's not urgent or a critical requirement to have this implemented. It would be a 'nice to have' in the sense that it would allow users to continue to use the latest version of cert-manager and benefit from the latest updates to cert-manager.
Ideally this is implemented as an upstream fix for a future OCP version.
4. Do you have any specific timeline dependencies and which release would they like to target?
None specifically due to answer to #3. This could be added in a future OCP version.
5. Would you be able to assist in testing this functionality if implemented?
Due to some HW limitations in our lab it would be difficult to dedicate a cluster and pull down a RC or hotfix patch. It is shared and we might not be able to dedicate time to testing this.
6. How would you like to achieve this? (List the functional requirements here)?
When ca.crt key is populated in a tls secret, it should be included after the beginning portion of the chain stored in tls.crt in accordance with the cert-manager 1.4 convention.
7. For each functional requirement listed in question 2, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
- Install cert-manager 1.4 using the helm chart:
chart_ref: cert-manager
chart_version: 1.4.0
chart_repo_url: https://charts.jetstack.io
(I believe this will require the creation of a namespace, and it is important to set 'install crds' true)
- Create a cluster issuer and request and retrieve a signed certificate with a root and end entity. Validate its contents to contain a crt.crt and tls.crt key with the root and end entities, respectively.
- Install this new tls secret cert on the ingress operator and kubeapi. Confirm that both are presenting the full chain using an external openssl query.