nginx-ingress controller not using the correct TLS cert #4674
Comments
|
Furthermore, when I shell into the pod itself, I can only see the default fake certificate: Even grep-ing the conf doesn't reveal the correct certificate is stored anywhere: |
|
@erfang-bondhouse how are you testing this? |
This is expected. The SSL certificates are handled by lua. Only the fake certificate is generated and stored in a file. |
Using any client, in my case mobile Safari and Chrome, it's clear that the fake certificate was being served up EDIT: a bit of background is that, I first uninstalled nginx ingress controller via |
|
fyi the work around is: I am confused as this seems to be a regression from before I I see a lot of release notes related to dynamic TLS improvements between 0.24 and 0.26, is it possible that this is a known bug already? |
|
So do I. the solution is -- default SSL certificate. |
|
proposed work around "--default-ssl-certificate=default/ingress-tls" doesn't work for me. |
|
Quick confirmation, I am running into the same problem, but in my case, I am trying to use ACM (Amazon certificates) and using the annotation However, when I see the logs, I see default certificate created - |
|
Seems like this is a huge regression that many people are experiencing |
|
It seems I am missing something. I just put a random app with the config which I mentioned in the above post. Again, the log on the backend (ingress nginx pod) shows the Default certificate created. But when I check the ingress certificates of the app (browser), it does show me Amazon ACM ones. The app opens normally as well and http --> https redirect happens (expected behavior). The question is, the default certificates, is that the expected behavior of Lua in the new nginx image? |
|
I was having the issue op had on this version: I just realized that I was missing the host in the rule per se (not sure if this is required, but it fixed the issues and now the cert. being used is the one I'm providing and not the Fake Kubernetes one). Example of my ingress: spec:
tls:
- hosts:
- domain.com
secretName: letsencrypt-staging
rules:
- **host: domain.com**
http:
paths:
- path: /
backend:
serviceName: "name"
servicePort: ### |
|
Closing. NGINX utilizes SNI to determine which SSL Certificate should be used http://nginx.org/en/docs/http/configuring_https_servers.html#name_based_https_servers Also, if an ingress without a host is defined, the SSL certificate defined in the tls secretName section cannot be used (nginx doesn't know how to use that because of the lack of hostname) |
your comment saved my life. Working on this for 17 hours straight and finally a single line solved it. Thank you so much. |
|
Not sure if this issue is a right place but wish to comment it instead of creating new one, somehow ingress controller does not use provided wildcard tls and uses "Kubernetes Ingress Controller Fake Certificate" instead for requests without SNI e.g.: ---
apiVersion: v1
kind: Pod
metadata:
namespace: default
name: demo
labels:
app: demo
spec:
containers:
- name: demo
image: nginx:alpine
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
namespace: default
name: demo
spec:
type: NodePort
ports:
- name: demo
port: 80
protocol: TCP
selector:
app: demo
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: default
name: demo
spec:
tls:
- hosts:
- "demo.dev.contoso.com"
secretName: dev.contoso.com
rules:
- host: "demo.dev.contoso.com"
http:
paths:
- path: /
backend:
serviceName: demo
servicePort: demowhen using but trying to use just for reference calling somehow ingress does not use given wildcard certificate and at the same time, the same config works ok in GKE |
Check my comment. This is related to SNI #4674 (comment) |
|
@aledbf sorry I did not mention this, default certificate on ingress will not solve this - in my case there is multiple domains, e.g.: *.dev.contoso.com, *.test.contoso.com, *.staging.contoso.com, etc Indeed we can put default cert but it will work only if we are talking about single domain per cluster in my case error will be the same with only difference that instead of fake certificate error will be on wrong CN |
|
@mac2000 when a client without SNI support sends a request it will be redirected to a default nginx server block. In there you can have one SSL certificate. This acts as a fallback. |
|
@aledbf yep it sounds reasonable but then "default backend" in ingress config is useless in this case, wondering how it does work in GKE (probably it is because of uniq ip addresses per ingress) at the very end there is still an issue, seems like there is no easy way to have multiple wildcard certificates attached to kubernetes (an easy way will be to have multiple clusters 🤔) |
|
@mac2000 the GKE controller create separated instances per ingress definition. Is not comparable with ingress-nginx where we share the definitions by default. You can have one deployment per wildcard domain, using the ingress.class annotation, sharing N definitions for a subdomain like |
|
@mac2000 default backend != default SSL certificate. What I've been mentioning is a flag in the deployment, not related to the default backend. |
|
Thank you for clarification, I went here from microk8s which just gives us just |
@mac2000 only if you have clients without SNI support. |
|
I'd also like to add that for HTTP requests, you can set the SNI by adding the header |
|
I'm having the same problem with my NGINX ingress controller. It's serving up the default FAKE certificate instead of the one that was issued by Why is this issue closed? How are people handling this years later? |
|
I have used the TLS secret which is not present in the ArgoCD namespace. Ingress used the default fake kubernetes certificate(was expecting an error stating "secret not found"). |
|
Is this issue fixed? I am still facing the same issue in ingress-nginx v1.2.0. After adding spec.tls.Hosts, spec.tls.secretName (CA Cert) and spec.rule.Host, it is still using default fake kubernetes certificate. |
|
Encountering this as well. Everything is defined, yet the certificate served for a wildcarded host is the default fake certificate. How did you manage to solve this issue? |
|
I encountered this - it turns out that wildcard host names are supported in the rules section but not by SNI, so it serves the fake ingress cert instead of mine. I had to write out 8 rule blocks instead of the wildcard. |
could you please elobertae more? I am also facing same issue! |
|
After countless hours of head scratching and puzzling, I came across something that appears to have worked for me. In my ingress, under spec change the entry under hosts eg from - example.domain.com to - "*.domain.com". |
You need to uninstall and install the ingress controller again with the ACM. |
Is this a BUG REPORT or FEATURE REQUEST? (choose one):
NGINX Ingress controller version:
Kubernetes version (use
kubectl version):Environment:
uname -a): default AMIWhat happened:
Despite having a secret matching the spec.tls.host[].secretName property in my Ingress resource, I am still seeing the Fake Kubernetes Certificate being used when I visit my site
Ingress Resource Configuration:
I can validate that the secret exists:
Even the controller logs didn't complain (I restarted the pod several times to see that'd pick up the change)
NGINX Ingress Controller Logs:
What you expected to happen:
The correct TLS certificate to be used (referenced by the secret name)
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know:
Here is the Helm Installed nginx ingress deployment:
The text was updated successfully, but these errors were encountered: