TLS Error

[sanketshirode]

I'm facing issue when configuring certificate in httpproxy. Below are the details of the error
Errors:
Message: Spec.VirtualHost.TLS Secret "vc-staging-cert" is invalid: Secret not found
Reason: SecretNotValid
Status: True
Type: TLSError

But the secret exists in the same namespace as proxy , also I tried tls delegation but same error. Please check below screenshots for reference:

[stevesloka]

Hey @sanketshirode, it's possible that there is a validation error happening and the "secret not found" is misleading.

Would you be able to tail your Contour logs to see if there's something that pops up? Contour looks for the following in a secret:

• TLSCertKey: tls.crt
• TLSPrivateKeyKey: tls.key
• CommonName
• SubjectAltNames

If any of those are invalid the secret doesn't get added to Contour's cache, so later on when your HTTPProxy references the secert, it's "not found" since it's not in the cache.

[sanketshirode]

Hey @stevesloka thanks a lot for responding. Please take a look at my secret given here

Nothing I could find in the contour logs, which can relate to this error. Please let me know anything else I could check ?

[stevesloka]

Hey @sanketshirode, could you restart an instance of Contour then look at the logs? If that secret doesn't change I bet that the logs would get lost. Can you verify your certs have a commonname and subject alt name? Also how did you provision the cert?

[sanketshirode]

Hey @stevesloka you were right, now I can see the logs complaining about missing CN or Sub Alt Name but when I checked both are present in cert. Please check the attached screen shot

And this is the log complaining about cert

[sanketshirode]

only thing is this is a wild card certificate and I think it shouldn't be an issue

[youngnick]

Hi @sanketshirode, yes, I think you're right, I think that this is a bug in our cert-validation code, based on those screenshots, the cert should validate.

I think it could be one of two things:

• the Subject contains an O = before the CN = , or
• the wildcard DNS name is first.

I'll drop this in our 'Needs investigation' column on our Project Board, and we'll get someone to take a look.

[youngnick]

@sanketshirode, sorry about the delay on this one, any chance you could give some more information about how you got that cert? I need to try and reproduce the issue, so I'll need to make a similar one somehow.

[zlubsen]

I seem to have the same issue.
I have certificate from a company internal CA, and the httpproxy object reports to be invalid due to not finding the referenced secret. The secret is definitely there, in the same namespace.
Using the same procedure for obtaining a certificate I created another httpproxy before, which after some tries works perfectly. I did experience the same error, but somehow it worked after some time. (let's call this one url A)
With my new httpproxy/service/certificate combo, the httpproxy remains invalid with the mentioned error (url B).

The only practical difference in the certificates is:

• url A: both CN and SAN list the same url - e.g., DNS service-a.company.com.
• url B: CN and SAN are different - CN= service-b.company.com, SAN= DNS alias-john.company.nl, DNS alias-joe.company.nl. (I intend to use the same cert for two different, related services).

Using a self-signed CA I created a certificate that does list the same url as CN and SAN, but no luck either. It produces a log message like this (but the mentioned secret definitely exists):
time="2021-11-04T13:08:04Z" level=error msg="invalid TLS certificate: failed to locate certificate" context=KubernetesCache kind=Secret name=servicename-tls-secret-selfca namespace=mynamespace version=v1

My contour version is 1.19.1.

Is there some progress in the triage?
Is there a way to trigger a reset of the contour cache?

[youngnick]

Thanks for that additional report @zlubsen. I should be able to use this to replicate the problem.

I'll start checking this one out today and see what I can see, along with some other issues we've found with the TLS certificate validation.

In terms of your last question, to reset the Contour cache, the easiest way is to restart the Contour pod (or pods).

[youngnick]

This sounds similar to #2372 and #3889, so I'll take a look at all of them at once.

[youngnick]

@sanketshirode, I believe that the fix I merged in #4165 should fix this, but I'm not one hundred percent sure. Is there any way you could test with main?

[skriss]

Per #3496 (comment) we believe this has been fixed. Closing out the issue, but feel free to reach out again if you do further testing against main or the upcoming 1.20 release and find this is still an issue.