redhat-cop
Problem with certificate in route sinced a changed has been made in cert-manager
We opened an issue to jetstack guy, about a changed they've made recently in cert-manager. See our case : https://github.com/cert-manager/cert-manager/issues/4829.
Problem since we upgrade from cert-manager 1.2.0 to 1.6.1
To make a short story, root ca is not available anymore in tls.crt in the output secret generated by cert-manager, only sub ca. In our case, to make it work, we need root ca or full chain (root & sub).
When the route is call, the client (aws api gateway) ask that there is a root ca at then end and it's not the case. If we had the annotation inject-CA: 'True' in the route, we have root ca in caCertificate section and sub ca in certificate section (root and sub are split / not together full chain) and it does not work either.
Do you plan a change to adapt to this change made by cert-manager ?
If we had the annotation inject-CA: 'True' in the route, we have root ca in caCertificate section and sub ca in certificate section (root and sub are split / not together full chain) and it does not work either.
I don't understand the above statement. If you don't have the root CA in
the ca.crt field from cert-manager, setting inject-CA to true should
either fail or not do anything. but certainly you should not end up with a
double root ca (which you stated you don't have to begin with).
To my understanding cert-manage will put the root ca in the tls.crt file
for certain cert providers and not populate the ca.crt field. For those
situations you should set inject-CA to false.
On Wed, Feb 16, 2022 at 11:11 AM whitelion-github @.***> wrote:
We opened an issue to jetstack guy, about a changed they've made recently in cert-manager. See our case : cert-manager/cert-manager#4829 https://github.com/cert-manager/cert-manager/issues/4829.
Problem since we upgrade from cert-manager 1.2.0 to 1.6.1
To make a short story, root ca is not available anymore in tls.crt in the output secret generated by cert-manager, only sub ca. In our case, to make it work, we need root ca or full chain (root & sub).
When the route is call, the client (aws api gateway) ask that there is a root ca at then end and it's not the case. If we had the annotation inject-CA: 'True' in the route, we have root ca in caCertificate section and sub ca in certificate section (root and sub are split / not together full chain) and it does not work either.
Do you plan a change to adapt to this change made by cert-manager ?
— Reply to this email directly, view it on GitHub https://github.com/redhat-cop/cert-utils-operator/issues/119, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPERXCUMH5CS7PELXOAIW3U3PEDDANCNFSM5OSCFRUQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message ID: @.***>
-- ciao/bye Raffaele
I will go, with a concrete example of my config and my route with cert-manager 1.6.1
kind: route annotations: cert-utils-operator.hydroquebec.com/certs-from-secret: cert-secret cert-utils-operator.hydroquebec.com/destinationCA-from-secret: cert-secret
kind: secret cert-secret (secret created by cert-manager) [ca.crt] root ca [tls.crt] signed certificate sub ca
final route populate by cert-util-operator
tls: certificate: public cert sub cert (in earlier version 1.22, root was also here = full chain) key: private key destinationCACertificate: sub cert
Before change, tls.crt had ful chain (cert + root + sub) and populate certifiacte of my route. Now, it's not the case. Whatever I do, I will never be able to have full chain.
If I had annotation inject-CA: 'True', it will had tls : ... caCertificate in my route with only the root ca. Since the root ca and the sub are separate, it does not work either.
I will go, with a concrete example of my config and my route with cert-manager 1.6.1
kind: route annotations: cert-utils-operator.hydroquebec.com/certs-from-secret: cert-secret cert-utils-operator.hydroquebec.com/destinationCA-from-secret: cert-secret
kind: secret cert-secret (secret created by cert-manager) [ca.crt] root ca [tls.crt] signed certificate sub ca
final route populate by cert-util-operator
tls: certificate: public cert sub cert (in earlier version 1.22, root was also here = full chain) key: private key destinationCACertificate: sub cert
Before change, tls.crt had ful chain (cert + root + sub) and populate certifiacte of my route. Now, it's not the case. Whatever I do, I will never be able to have full chain.
If I had annotation inject-CA: 'True', it will had tls : ... caCertificate in my route with only the root ca. Since the root ca and the sub are separate, it does not work either.
I will go, with a concrete example of my config and my route with cert-manager 1.6.1
kind: route annotations: cert-utils-operator.hydroquebec.com/certs-from-secret: cert-secret cert-utils-operator.hydroquebec.com/destinationCA-from-secret: cert-secret
kind: secret cert-secret (secret created by cert-manager) [ca.crt] root ca [tls.crt] signed certificate sub ca
final route populate by cert-util-operator
tls: certificate: public cert sub cert (in earlier version 1.22, root was also here = full chain) key: private key destinationCACertificate: sub cert
Before change, tls.crt had ful chain (cert + root + sub) and populate certifiacte of my route. Now, it's not the case. Whatever I do, I will never be able to have full chain.
If I had annotation inject-CA: 'True', it will had tls : ... caCertificate in my route with only the root ca. Since the root ca and the sub are separate, it does not work either.
The point is how can you polulate the fullchain (root/sub) together by using cert-util-operator if cert-manager secret separate root and sub.
I understand the point, I don't understand the issue still.
Let's start from the beginning, do you get the ca.crt from cert-manager?
if so, do you set the inject-CA to true?
Yes we got the ca.crt (containing only public root cert)
With cert-manager 1.2.0 we were not using inject-CA annotation because full chain certificate were avalaible in tls.crt, so we were ok using only certs-from-secret annotation. In the route, we add the complete chain in certificate section.
It's not the case anymore.
Use annotation inject-CA to true does not solve the probleme because, the sub and the root are separated.
kind: route
certificate (populate using certs-from-secret annotation) signed certificate sub
caCertificate (populate using inject-CA annotation) root
Use annotation inject-CA to true does not solve the problem because, the sub and the root are separated.
This shouldn't be the case, my understanding is that the route should present a certificate that is the merge of the ca.crt and tls.crt. You are basically saying that the ca.crt is being ignored, correct?
Then what configuration would work for you? This sounds more like a OCP issue than cert-utils. What version of OCP do you have?
You're right, ca.crt et tls.crt is a merge of the signe certificate with it's CA. The CA chain must stay together.
I should have in ocp route, sub and root in the same definition block under tls. The merge of certificate block (signed certificate) and caCertificate block with root and sub is working if I manually provision the route.
But I can't explain why the merge of the certificate block with sub and caCertificate block with root don't gives a good configuration. I think sub and root must stay together, it's a chain, it makes sense to keep it together.
As I say, we need to find a way to get sub&root as a chain in the same route definition block.
If I go further, why ca.crt does not contain both ca & sub certificate and tls.crt only signed certificate ? It would solve the problem. A question I should asked to jetstack team.
OCP : 4.8
How we succeeded to solve this issue. We fork the cert-util-operator code to manipulate certificate in the route. We now always use inject-CA : true in our route. The new code remove intermediate (sub) ca from "certificate" section. After, it copy this certificate in "caCertificate" where we already have root certificate, so we can have the two certificates (ca and sub) together. Works this way.