https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# general
a
This message was deleted.
r
Not in GKE specifically, no. Do you think the problem is unique to GKE?
h
I don't know if it's only on GKE. Problem: Nginx-ingress always forwards to port 80, it works. 443 returns 404 NOT Found. All the necessary configs that work on another AWS cluster are there
r
Oh, interesting. So what's the value of 
spec.tls.*.hosts
on the Ingress resource? There's an opportunity for a mismatch there if it's not the same value of 
host
on the HTTP counterpart in 
spec.rules.*.host
.
The load balancer will only route the request properly if the DNS name matches 
host
.
h
The DNS routes correctly on port 80. tls is a wildcard that seems to be pe applied successfully. Browser shows valid certificate
r
Your server certificate has a wildcard DNS SAN, right?
h
Yes. The Certificate is correctly validates as wildcard. I tested it on a different cluster and it works
r
Here is a functioning Ingress example.
Copy code
apiVersion: <http://networking.k8s.io/v1|networking.k8s.io/v1>
kind: Ingress
metadata:
  annotations:
    <http://cert-manager.io/issuer|cert-manager.io/issuer>: rancher
    <http://cert-manager.io/issuer-kind|cert-manager.io/issuer-kind>: Issuer
    <http://field.cattle.io/publicEndpoints|field.cattle.io/publicEndpoints>: '[{"addresses":["192.168.5.15"],"port":443,"protocol":"HTTPS","serviceName":"cattle-system:rancher","ingressName":"cattle-system:rancher","hostname":"<http://rancher.example.com|rancher.example.com>","allNodes":false}]'
    <http://meta.helm.sh/release-name|meta.helm.sh/release-name>: rancher
    <http://meta.helm.sh/release-namespace|meta.helm.sh/release-namespace>: cattle-system
    <http://nginx.ingress.kubernetes.io/proxy-connect-timeout|nginx.ingress.kubernetes.io/proxy-connect-timeout>: "30"
    <http://nginx.ingress.kubernetes.io/proxy-read-timeout|nginx.ingress.kubernetes.io/proxy-read-timeout>: "1800"
    <http://nginx.ingress.kubernetes.io/proxy-send-timeout|nginx.ingress.kubernetes.io/proxy-send-timeout>: "1800"
  creationTimestamp: "2023-03-23T00:13:53Z"
  generation: 1
  labels:
    app: rancher
    <http://app.kubernetes.io/managed-by|app.kubernetes.io/managed-by>: Helm
    chart: rancher-2.7.1
    heritage: Helm
    release: rancher
  name: rancher
  namespace: cattle-system
  resourceVersion: "2223"
  uid: 1f78f424-c9a3-4bae-9379-75d193409d35
spec:
  ingressClassName: traefik
  rules:
  - host: <http://rancher.example.com|rancher.example.com>
    http:
      paths:
      - backend:
          service:
            name: rancher
            port:
              number: 80
        pathType: ImplementationSpecific
  tls:
  - hosts:
    - <http://rancher.example.com|rancher.example.com>
    secretName: tls-rancher-ingress
status:
  loadBalancer:
    ingress:
    - ip: 192.168.5.15
I was pointing out the necessary symmetry between the two occurrences of 
<http://rancher.example.com|rancher.example.com>
in 
spec.rules
and 
spec.tls
.
h
Yes, this is identical to my config
Copy code
tls:
  - hosts:
    - '*.<http://example.com|example.com>'
This is the only difference
r
That is the problem. It should not be a wildcard in this spot, but the expected DNS name instead.
The web client/user agent is the audience for the wildcard DNS SAN, not this load balancer.
h
ok, updating now ...
wow. worked. Testing some more
so even if the certificate is a wildcard, the host must be the full path, correct?
r
Yes, you must program Nginx to match some DNS name with a cluster service. I believe Nginx can handle a wildcard scenario, but I'm not certain how to express that in an Ingress resource.
There's certainly support for wildcard hosts in K8s Ingress, but they don't give an example of a wildcard TLS host pattern. https://kubernetes.io/docs/concepts/services-networking/ingress/#hostname-wildcards
h
great. seems to be working now. Thanks!
r
You're welcome! This post does give an example of wildcard TLS host. Maybe it was a stray keystroke error preventing the match? https://docs.digitalocean.com/tutorials/set-up-nginx-ingress-controller-to-use-wildcard-certificates/#step-5-set-up-nginx-t[…]-wildcard-certificates
h
No, so what happens is the moment I add * to the host in TLS it automatically reverts back to HTTP. If add the host as exact match, then it works with SSL
6 Views
Open in Slack
PreviousNext
Powered by