You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use-case
We're using Cert-Manager Helm-Charts https://github.com/cert-manager/cert-manager/releases/ in Version 1.13.2 on an Azure Kubernetes Service (AKS). The cert-manager PKI consists of a 2-tier PKI, meaning we have a self-issued CA cluster-issuer on AKS and the corresponding leaf-certificates. Those leaf-certificates are issued with NGINX-Ingress-Controllers, using the built-in cert-manager annotations.
Additionally, an Azure Application Gateway is used to distributed incoming Load to corresponding ingress' on AKS.
The Azure Application Gateway enforces the backends (thus our AKS-Ingress) to present the full-chain (including root-certificates), in order to establish a trust relationship. Please note, that additionally for not-well-known CAs (as in our cert-manager self-issued/-signed CA), the root-certificate must be imported into the Application Gateway's truststore.
Thus, while the setup does provide an independent distribution of the root-certificate, the AppGW still requires the full-chain beeing presented, which contradicts the way cert-manager (incl. self-issued) generates ca.crt and tls.crt.
Further Information
We're also investigating with MSFT about the Application Gateway requiring the full chain, but I figured maybe there's some additional feature-flags in cert-manager I haven't found yet in the docs, as I suspect we might not be the only ones, having trouble with a client requiring a full-chain from cert-manager backed service.
Specific to our use-case, I also haven't been able to find a configuration-flag for Ingress-NGINX-Controller to present a combination of ca.crt and tls.crt, as per-default tls.crt is presented.
Question
Is there any currently existing solution for my use-case in terms of configuration of cert-manager? Maybe I've missed it in the docs or some workarounds have emerged in the community
Would it be possible / acceptable to implement such a feature in terms of cert-manager (similiar to Add a way to get the full cert chain for issued ACME certificates #1524, but obviously in latest versions), with the additional note in the docs, that root-certificates should be distributed independently to establish a true trust relationship.
Looking forward to hearing from you.
The text was updated successfully, but these errors were encountered:
I think the additional output formats feature in cert-manager could be used to produce "special" output formats like the full chain. This feature is graduated to beta in cert-manager 1.15 - which means it's enabled by default.
Dear all
First of all, thank you all the maintainers, commiters and community! Personally, I'm a huge fan of cert-manager :).
My question
Given
is there a possibility to configure cert-manager to provide the full-chain in tls.crt?
While I understood the main concerns being:
we do have exactly such a use-case.
Use-case
We're using Cert-Manager Helm-Charts https://github.com/cert-manager/cert-manager/releases/ in Version 1.13.2 on an Azure Kubernetes Service (AKS). The cert-manager PKI consists of a 2-tier PKI, meaning we have a self-issued CA cluster-issuer on AKS and the corresponding leaf-certificates. Those leaf-certificates are issued with NGINX-Ingress-Controllers, using the built-in cert-manager annotations.
Additionally, an Azure Application Gateway is used to distributed incoming Load to corresponding ingress' on AKS.
The Azure Application Gateway enforces the backends (thus our AKS-Ingress) to present the full-chain (including root-certificates), in order to establish a trust relationship. Please note, that additionally for not-well-known CAs (as in our cert-manager self-issued/-signed CA), the root-certificate must be imported into the Application Gateway's truststore.
Thus, while the setup does provide an independent distribution of the root-certificate, the AppGW still requires the full-chain beeing presented, which contradicts the way cert-manager (incl. self-issued) generates ca.crt and tls.crt.
Further Information
Question
Looking forward to hearing from you.
The text was updated successfully, but these errors were encountered: