-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSL errors with from-to-www-redirect (ERR_CERT_AUTHORITY_INVALID/MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT) #7103
Comments
@VengefulAncient Would you like to output the result of |
Sure, here it is (of course,
|
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
Can you update to a supported version? Wanted to look into this, but it seems you are using a really old one. |
Thanks for looking into this! I will update to the latest version and report back ASAP. |
Sorry this took quite a while. Upgraded to latest controller (
So my question is, was there actually anything changed/fixed that addressed this issue? I've been following the updates closely but have not seen any such commits, to my best knowledge. I'm wary of marking this as resolved due to the above points. It sounds more like it got fixed accidentally and might regress at any point. |
Never mind, the error is still happening. However, it is only happening with one of our subdomains (we have two in our staging cluster, one for each development branch, e.g. Any ideas on what I should be looking at to find out why this works correctly for one of them but not the other? |
Please try the latest release v1.2.0 and update status. |
/remove-kind bug |
Please don't pollute the thread with bureaucracy if you are not even going to read the messages or contribute to investigation. I have clearly indicated that I have already done this. |
/kind bug |
Try to provided related info using the the recommended https://kubernetes.github.io/ingress-nginx/deploy/#gce-gke and maybe avoid the personal comments. Seems like a complicated issue and you have used helm chart. Not sure if yo have tried the recommended manifest. So the data provided may not have clarity. The cert you showed has definitely expired in 2021 for example. Provide data that has relevance like ;
No data here is clearly indicating a bug |
I reiterate, please stop polluting the thread with unhelpful comments. You are wasting everyone's time. This thread has been opened months ago and the certificate has obviously been renewed since. I'd like to hear from @rikatz who indicated he was interested in investigating this bug, and not read through obvious FAQ. I have already posted plenty of relevant information, and the fact that you cannot see that this is a bug only indicates that you have not taken the time to read through and understand the issue. |
/help |
@iamNoah1: GuidelinesPlease ensure that the issue body includes answers to the following questions:
For more details on the requirements of such an issue, please see here and ensure that they are met. If this request no longer meets these requirements, the label can be removed In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close not-planned |
@k8s-triage-robot: Closing this issue, marking it as "Not Planned". In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
NGINX Ingress controller version: v.0.44.0
Kubernetes version (use
kubectl version
): v1.19.9-gke-1400Environment:
cert-manager
What happened:
Essentially the same issue as in #5675 except we're trying to redirect from
www.
to naked domain and not the other way around. Trying to loadhttps://www.example.com
in Chrome producesNET::ERR_CERT_AUTHORITY_INVALID
error.In Firefox, it's
MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT
and clickingAccept the Risk and Continue
proceeds to correctly follow redirects and load the site. Subsequent requests then also work fine.What you expected to happen:
Redirect from
www.
to naked domain works without errors.How to reproduce it:
Ingress is configured in line with what was suggested by aledbf: no backend for
www.
butwww.
domain is included in TLS hosts. According to several threads on the topic I've perused, that approach should work.Anything else we need to know:
Ingress controller logs mention:
the server www.example.com has SSL configured but the SSL certificate does not contains a CN for example.com. Redirects will not work for HTTPS to HTTPS
. This is false, I've checked and the certificate does contain CN forexample.com
.The logs have the same warning for
https://www.example.co.uk
(we own a.co.uk
version of our domain just to rewrite it to.com
) but navigating tohttps://www.example.co.uk
works exactly as expected: there is a308
redirecting tohttps://example.co.uk
and then a301
tohttps://example.com
. Why is this not happening forhttps://www.example.com
? (Note that adding the same301
redirectif
block fromwww.example.com
toexample.com
does not fix the issue, nor should it be the solution.)On the first request after opening private browsing, requesting
www.example.com
orhttp://www.example.com
in Chrome or Firefox will proceed as follows:308
fromwww.
to naked domain308
fromhttp
tohttps
Immediately after though, requesting either of these in a new tab results in the same error again. Firefox network console shows nothing, but Chrome logs a
307
fromhttp
tohttps
and then fails on the next request which asks forhttps://www.example.com
. (Manually prefixing the URL withhttps://
always results in the error, even on the first request.) Notice how on the first attempt,www.
to naked domain happened first, and the issue did not occur. This mirrors the behaviour described in 2043, which is apparently not fixed to this date.The issue can be bypassed by adding
www.example.com
as ahost
tospec.rules
. I don't consider this a valid configuration or a solution to this issue for several reasons:Documentation states:
This directive is fulfilled by my configuration. There is nothing about having to add the
www.
domain as a backend.It defeats the point of
from-to-www-redirect
annotationIt complicates ingress Helm templates and bloats the resulting manifest
It does not actually result in a redirect (it merely handles requests on
www.
as another backend), as evidenced by the following warnings in the logs:Already exists an Ingress with "www.example.com" hostname. Skipping creation of redirection from "www.example.com" to "example.com".
Already exists an Ingress with "example.com" hostname. Skipping creation of redirection from "example.com" to "www.example.com".
Based on these findings, it appears that there is a long-existing bug with this annotation. People are using workarounds such as a conditional
rewrite
block and they really shouldn't need to. It would be really amazing to have this actually fixed and put all the relevant discussions to rest once and for all.I've also noticed that the annotation documentation claims:
How exactly will it be "omitted"? My cluster does have other Ingress objects with
example.com
as a host (withoutwww.
orfrom-to-www-redirect
on them) but the generatednginx.conf
still has redirect blocks forexample.com
location so it does not look like anything was "omitted":The text was updated successfully, but these errors were encountered: