from-to-www-redirect is applied after SSL instead of before, causing security warning in browser

[artemzakharov]

Is this a request for help?: No, bug

What keywords did you search in NGINX Ingress controller issues before filing this one?: force-www, ssl, https, kubernetes ingress controller fake certificate

---

Is this a BUG REPORT or FEATURE REQUEST?: bug

NGINX Ingress controller version: 0.9.1

Kubernetes version: 1.8.5

Environment: GKE

• Cloud provider or hardware configuration: Google Cloud
• OS (e.g. from /etc/os-release): Container OS
• Kernel (e.g. uname -a):
• Install tools: Helm
• Others: n/a

What happened: I have an app I would like to host on www.foo.com. My nginx ingress has the from-to-www-redirect flag enabled to redirect requests from the base domain url, and has a TLS secret to provide for secure connections. This combination of redirect and SSL works for most url inputs, but not one in particular - https://foo.com. In this case, browsers present a security warning like this:

Attackers might be trying to steal your information from foo.com (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_AUTHORITY_INVALID
Subject: Kubernetes Ingress Controller Fake Certificate
Issuer: Kubernetes Ingress Controller Fake Certificate
Expires on: Feb 1, 2019
Current date: Feb 7, 2018
PEM encoded chain:
...

Forcing the browser to proceed to the "unsafe" site redirects to the correct destination of https://www.foo.com and enables SSL like nothing ever happened. For reference, the following urls all redirect to https://www.foo.com with no warnings:

foo.com
http://foo.com
www.foo.com
http://www.foo.com

What you expected to happen: I expect https://foo.com to redirect to https://www.foo.com without browsers displaying a false alarm.

How to reproduce it (as minimally and precisely as possible):

1. Set up an application on GKE
2. Place it behind an nginx ingress configured to enable from-to-www-redirect and SSL via a certificate, with a subdomain host like www.foo.com pointing to the application service
3. Attempt to reach the application with https://<base-domain>.

Anything else we need to know:

Here's my nginx ingress config file:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: foo-https-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/from-to-www-redirect: "true"
spec:
  rules:
    - host: www.foo.com
      http:
        paths:
          - backend:
              serviceName: foo-prod-front
              servicePort: 80
            path: /
  tls:
      - hosts:
          - www.foo.com
        secretName: tls-secret

[JordanP]

Is your certificate valid for both foo.com and www.foo.com ?

[artemzakharov]

No, it's for www.foo.com only. Does that actually matter though? It seems like it's not bringing up my certificate at all when I hit https://foo.com, hence why the browser sees a 'kubernetes ingress controller fake certificate'. Or does a mismatch cause the ingress to throw out a fake cert? Seems confusing if that's the case.

[aledbf]

Closing. This works as expected. As @JordanP said, if you have an SSL certificate, you need one that contains all the hosts you need (CN in the certificate). This is a restriction in NGINX that we cannot change.

[artemzakharov]

@aledbf So the Ingress Controller throws a 'fake' certificate when the provided certificate doesn't cover the requested host?

[aledbf]

@artemzakharov NGINX, not the controller.

[artemzakharov]

@aledbf Got it, thank you for the clarification. Hadn't used NGINX before using this library so wasn't sure who was responsible for which behavior.

I have same issue, my certificate is valid for both www.foo.com and foo.com but when using from-to-www-redirect and

  tls:
  - hosts:
    - www.foo.com
    - foo.com
    secretName: foo-com-ssl

ssl_certificate and ssl_certificate_key directives don't get generated for foo.com server block. I've checked this with nginx template and these directives don't exists in them either

ingress-nginx/rootfs/etc/nginx/template/nginx.tmpl

Lines 377 to 405 in 36cce00

	{{/* Build server redirects (from/to www) */}}
	{{ range $hostname, $to := .RedirectServers }}
	server {
	{{ range $address := $all.Cfg.BindAddressIpv4 }}
	listen {{ $address }}:{{ $all.ListenPorts.HTTP }}{{ if $all.Cfg.UseProxyProtocol }} proxy_protocol{{ end }};
	listen {{ $address }}:{{ if $all.IsSSLPassthroughEnabled }}{{ $all.ListenPorts.SSLProxy }} proxy_protocol{{ else }}{{ $all.ListenPorts.HTTPS }}{{ if $all.Cfg.UseProxyProtocol }} proxy_protocol{{ end }}{{ end }} ssl;
	{{ else }}
	listen {{ $all.ListenPorts.HTTP }}{{ if $all.Cfg.UseProxyProtocol }} proxy_protocol{{ end }};
	listen {{ if $all.IsSSLPassthroughEnabled }}{{ $all.ListenPorts.SSLProxy }} proxy_protocol{{ else }}{{ $all.ListenPorts.HTTPS }}{{ if $all.Cfg.UseProxyProtocol }} proxy_protocol{{ end }}{{ end }} ssl;
	{{ end }}
	{{ if $IsIPV6Enabled }}
	{{ range $address := $all.Cfg.BindAddressIpv6 }}
	listen {{ $address }}:{{ $all.ListenPorts.HTTP }}{{ if $all.Cfg.UseProxyProtocol }} proxy_protocol{{ end }};
	listen {{ $address }}:{{ if $all.IsSSLPassthroughEnabled }}{{ $all.ListenPorts.SSLProxy }} proxy_protocol{{ else }}{{ $all.ListenPorts.HTTPS }}{{ if $all.Cfg.UseProxyProtocol }} proxy_protocol{{ end }}{{ end }};
	{{ else }}
	listen [::]:{{ $all.ListenPorts.HTTP }}{{ if $all.Cfg.UseProxyProtocol }} proxy_protocol{{ end }};
	listen [::]:{{ if $all.IsSSLPassthroughEnabled }}{{ $all.ListenPorts.SSLProxy }} proxy_protocol{{ else }}{{ $all.ListenPorts.HTTPS }}{{ if $all.Cfg.UseProxyProtocol }} proxy_protocol{{ end }}{{ end }};
	{{ end }}
	{{ end }}
	server_name {{ $hostname }};
	{{ if ne $all.ListenPorts.HTTPS 443 }}
	{{ $redirect_port := (printf ":%v" $all.ListenPorts.HTTPS) }}
	return {{ $all.Cfg.HTTPRedirectCode }} $scheme://{{ $to }}{{ $redirect_port }}$request_uri;
	{{ else }}
	return {{ $all.Cfg.HTTPRedirectCode }} $scheme://{{ $to }}$request_uri;
	{{ end }}
	}
	{{ end }}

[kwojtaszek]

I can confirm that issue exists in 0.14.0, generic block with no ssl included is generated for this specific scenario:

	server {

		listen 80;
		listen 443 ssl;

		listen [::]:80;
		listen [::]:443;

		server_name www.foo.com;

		return 308 $scheme://foo.com$request_uri;

	}

[johnmshields]

@aledbf Can this be re-opened? The comments above show the issue. It works fine if you come in on http but if the client comes in on https then the connection cannot be made so the redirect cannot occur.

[renaudguerin]

Experiencing this as well, with certs generated by cert-manager (ex kube-lego)

Pretty serious issue IMHO, this makes from-to-www-redirect unusable with TLS.

The spec.tls.hosts entry in my ingress has both www.foo.com, foo.com, and a 3rd domain, and the resulting cert does have all 3 domains.

So, the problem definitely seems to be in the generated nginx config.

[thomascooper]

I am having the same issue using nginx-ingress-controller:0.14.0. If I visit the root domain i receive a cert error (its serving the Kubernetes Ingress Controller Fake Certificate).

I use https://github.com/jetstack/cert-manager (very similar and based on kube-lego, same as the commenter above).

Here is my ingress config:

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: group-1
  annotations:
    kubernetes.io/ingress.class: "group1-ingress"
    kubernetes.io/tls-acme: "true"
    [ cert-manager annotations ]
    nginx.ingress.kubernetes.io/ssl-redirect: "True"
    nginx.ingress.kubernetes.io/from-to-www-redirect: "True"
spec:
  tls:
  - hosts:
    - www.foo.com
    - foo.com
    secretName: prd-live-group-1
  rules:
  - host: www.foo.com
    http:
      paths:
      - backend:
          serviceName: foo-service
          servicePort: 80

[thomascooper]

For those interested in a short term work around, I add the following annotation to get it to work as I need for now:

nginx.ingress.kubernetes.io/configuration-snippet: |
  if ($host = 'foo.com' ) {
    rewrite ^ https://www.foo.com$request_uri permanent;
  }

Then I add the root foo.com to the rules:

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: group-1
  annotations:
    kubernetes.io/ingress.class: "group1-ingress"
    kubernetes.io/tls-acme: "true"
    [ cert-manager annotations ]
    nginx.ingress.kubernetes.io/configuration-snippet: |
      if ($host = 'foo.com' ) {
        rewrite ^ https://www.foo.com$request_uri permanent;
      }
    nginx.ingress.kubernetes.io/ssl-redirect: "True"
    nginx.ingress.kubernetes.io/from-to-www-redirect: "True"
spec:
  tls:
  - hosts:
    - www.foo.com
    - foo.com
    secretName: prd-live-group-1
  rules:
  - host: www.foo.com
    http:
      paths:
      - backend:
          serviceName: foo-service
          servicePort: 80
  - host: foo.com
    http:
      paths:
      - backend:
          serviceName: foo-service
          servicePort: 80