I'm using gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.3 on a two kubernetes 1.3 clusters. On one cluster, the TLS routing works as expected, but on the other it doesn't.
On the first cluster, I see the following in the nginx.conf inside the controller container:
server {
server_name jenkins.192.168.13.183.nip.io;
listen [::]:80;
listen 442 ssl http2;
# PEM sha: 77762636e812fc44f1c9b193a846f049512a5816
ssl_certificate /ingress-controller/ssl/default-jenkins-secret.pem;
ssl_certificate_key /ingress-controller/ssl/default-jenkins-secret.pem;
more_set_headers "Strict-Transport-Security: max-age=15724800; includeSubDomains; preload";
location / {
set $proxy_upstream_name "default-jenkins-service-8080";
Using only slightly modified yaml files (and a different namespace) on the second cluster, the nginx.conf shows this:
server {
server_name jenkins.brdos1.k8s-dev.company.com;
listen [::]:80;
location / {
set $proxy_upstream_name "shared-tools-jenkins-service-8080";
For some reason, the same controller on the second cluster isn't recognizing the TLS route or secrets. I have quadruple checked the secrets, namespaces and the deployment is running and does route over HTTP (non-TLS).
The Ingress is defined as
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: jenkins-ingress
namespace: shared-tools
spec:
tls:
- hosts:
- jenkins.brdos1.k8s-dev.company.com
secretName: jenkins-secret
rules:
- host: jenkins.brdos1.k8s-dev.company.com
http:
paths:
- backend:
serviceName: jenkins-service
servicePort: 8080
I would be happy to further debug, but I'm not sure where to start in the code.
@dwatrous please check if the image quay.io/aledbf/nginx-ingress-controller:0.89 solves the issue.
(this image contains current master - the next beta)
There's no change. I also tried 0.90 tag that I noticed was more recent than the one you sent. If you can point me in the right direction, I'm happy to look into the code a little more. Let me know if you need anymore details.
The latest version container included a log message that gave me a little more detail.
W0417 15:39:33.606233 1 controller.go:1009] ssl certificate shared-tools/jenkins-secret does not contain a common name for host jenkins.brdos1.k8s-dev.company.com
I was reusing a certificate from a previous deployment. Apparently there is a check to see if the certificate matches the common name provided with the ingress. I created a new key and certificate with the common name matching my ingress. It now works.
This doesn't seem to be a bug and the logging now points to the misconfiguration. I'll close this now.
Sorry for posting to the closed issue.
Is there a way to disable such behavior?
@dbogatov I'm not sure what you mean by disable. The behavior correctly requires a matching certificate and it will accept a self-signed certificate.
@dwatrous Is there any option (config, cli, annotation) that lets NGINX not require valid certificate. Let it use what is provided.
@dbogatov not that I'm aware of. I'm not sure I would advocate that either. I suggest you get a valid certificate. It's super easy to do: http://software.danielwatrous.com/generate-tls-secret-for-kubernetes/
Most helpful comment
The latest version container included a log message that gave me a little more detail.
W0417 15:39:33.606233 1 controller.go:1009] ssl certificate shared-tools/jenkins-secret does not contain a common name for host jenkins.brdos1.k8s-dev.company.comI was reusing a certificate from a previous deployment. Apparently there is a check to see if the certificate matches the common name provided with the ingress. I created a new key and certificate with the common name matching my ingress. It now works.
This doesn't seem to be a bug and the logging now points to the misconfiguration. I'll close this now.