cert-manager: generated kubernetes.io/tls secret do not respect standard

@SgtCoDFish yep, linked procedure is a liitle bit another case. OpenShift mounts secret, generated by Cert-Manager without custom-ca bundle. Its affects isolated installations of Openshift without white domains/certs

Hi!

There is no way to tell openshift ingress operator where to find custom root CA

If true, I suspect this would be a reasonably strong case for us adding an option to add the root to tls.crt; we want to support openshift.

That said, it looks to me that step 1 under procedure on this page you linked is doing exactly that?

I’m not very experienced with openshift, so I could be misunderstanding.

set 1 only adds custom CA to coreos/rhcos trusted ca bundle using machine config. But /var/run/secrets/kubernetes.io/serviceaccount/ca.crt isn’t affected.

In addition, this ticket https://access.redhat.com/solutions/6013471t describes the way to add custom CA via cert chain.

I can try to add this option and send a pull request, if you confirm this functionality.

Hi!

There is no way to tell openshift ingress operator where to find custom root CA

If true, I suspect this would be a reasonably strong case for us adding an option to add the root to tls.crt; we want to support openshift.

That said, it looks to me that step 1 under procedure on this page you linked is doing exactly that?

I’m not very experienced with openshift, so I could be misunderstanding.

Hi! I have the same issue with ca.crt parameter I`v tried to use cert-manager for issuing custom certificate for openshift ingress operator. According to the openshift documentation: https://docs.openshift.com/container-platform/4.7/security/certificates/replacing-default-ingress-certificate.html

The certificate file can contain one or more certificates in a chain. The wildcard certificate must be the first certificate in the file. It can then be followed with any intermediate certificates, and the file should end with the root CA certificate.

Openshift ingress operator, takes all chain from tls.crt and adds to /var/run/secrets/kubernetes.io/serviceaccount/ca.crt Without root CA, apps which uses /var/run/secrets/kubernetes.io/serviceaccount/ca.crt as trusted ca bundle, can’t work properly

There is no way to tell openshift ingress operator where to find custom root CA

This ticket describes the only way to add custom CA to /var/run/secrets/kubernetes.io/serviceaccount/ca.crt, via ingress operator https://access.redhat.com/solutions/6013471

But most of the time automation implies the fact you are acting both as the server and the client, and prior to the automation, there is no trust established between them.

If anything requires the root to be in the chain that’s presented, it’s likely to be fundamentally breaking a key assumption of TLS. It changes the entire trust model into “trust on first use” (TOFU), and introduces a huge risk of man-in-the-middle attacks. If the “automation” adds the root to a trust store, that’s a gigantic security risk.

If I were a CISO or a member of a security team at a company, seeing a requirement for a root in a chain would ring serious alarm bells for me.