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
Hello again, this is a related issue I have after setting up Vault as a CA #105. In the previous issue I was able to create a valid chain by specifying the CA in istio-csr using app.tls.rootCAFile.
Now I'm trying to setup the cluster from scratch and I've found an issue on the certificate chain used by istiod or istio-csr, not sure yet.
The problem I'm facing is that the istio ingress and egress gateway's pods don't get healthy and in the logs we can see an error saying that the certificate is signed with an untrusted authority. At this point I can't tell to which service is trying to reach, I would assume it's istiod or istio-csr.
I've validated that the istio-ca-root-cert is correctly propagated to all the namespaces with the same CA I loaded in istio-csr using app.tls.rootCAFile.
What I've also noticed is that at this point we have two CertificateRequests generated, istio-csr-g84kt and istiod-ww4vx, both of them have the Intermediate in the Ca field instead of the CA I loaded in istio-csr.
My assumption here is that istio-ingressgateway correctly trust the CA loaded in istio-ca-root-cert, but the TLS handshake with istiod or istio-csr is failing because they are returning the Intermediated as the CA.
Additionally, to validate the previous assumption, any deployment fails to create pods with a handshake error as well.
I've also tried to load the CA chain in istio-csr, by loading a file containing the Intermediate and the CA using app.tls.rootCAFile. With this the ingress and egress gateway pods were able to successfully run and normal deployments were able to schedule their pods, but the certificate chain in the istio-proxy of the application now is invalid, as it has the intermediate duplicated.
I think the problem here is that the CA loaded from istio-csr is not correctly propagated to these firsts CertificateRequests.
Hi @SantiMunoz, can you verify that the CA being propagated is in-fact the CA that you are intending to propagate, and that the resulting certificates contain a full valid chain.
RootCert.pem should contain the CA that is being propergated. Intermediate.pem should be the intermediates as they appear in the CertificateRequest, not including the leaf certificate IstioCert.pem the leaf certificate
I think the problem here is that the CA loaded from istio-csr is not correctly propagated to these firsts CertificateRequests.
The CertificateRequests are signed and updated by the configured cert-manager Issuer. istio-csr is only responsible and capable of creating the resource and reading back what it is updated with.
Hello again, this is a related issue I have after setting up Vault as a CA #105. In the previous issue I was able to create a valid chain by specifying the CA in
istio-csr
usingapp.tls.rootCAFile
.Now I'm trying to setup the cluster from scratch and I've found an issue on the certificate chain used by istiod or istio-csr, not sure yet.
The problem I'm facing is that the istio ingress and egress gateway's pods don't get healthy and in the logs we can see an error saying that the certificate is signed with an untrusted authority. At this point I can't tell to which service is trying to reach, I would assume it's istiod or istio-csr.
I've validated that the
istio-ca-root-cert
is correctly propagated to all the namespaces with the same CA I loaded in istio-csr usingapp.tls.rootCAFile
.What I've also noticed is that at this point we have two
CertificateRequests
generated,istio-csr-g84kt
andistiod-ww4vx
, both of them have the Intermediate in theCa
field instead of the CA I loaded inistio-csr
.My assumption here is that istio-ingressgateway correctly trust the CA loaded in
istio-ca-root-cert
, but the TLS handshake with istiod or istio-csr is failing because they are returning the Intermediated as the CA.Additionally, to validate the previous assumption, any deployment fails to create pods with a handshake error as well.
I've also tried to load the CA chain in istio-csr, by loading a file containing the Intermediate and the CA using
app.tls.rootCAFile
. With this the ingress and egress gateway pods were able to successfully run and normal deployments were able to schedule their pods, but the certificate chain in the istio-proxy of the application now is invalid, as it has the intermediate duplicated.I think the problem here is that the CA loaded from istio-csr is not correctly propagated to these firsts
CertificateRequests
.istio-csr config used:
Istio Operator config used
The text was updated successfully, but these errors were encountered: