Ingress-nginx: nginx ingress controller not recognizing TLS ingress

Created on 17 Apr 2017  路  7Comments  路  Source: kubernetes/ingress-nginx

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.

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.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.

All 7 comments

@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/

Was this page helpful?
0 / 5 - 0 ratings