Kubernetes Ingress TLS is set but a wrong certificate is served at the end

Question

I am currently trying to use Collabora Online (a tool to edit documents in collaboration) with Kubernetes. I managed to setup ssl but I would like to have my own certificate.

I followed haproxy documentation to setup a certificate per ingress. But if in my minikube dashboard I'm able to see that my certificate is well configured, at the end for the user, an other certificate is served (the default certificate of haproxy).

I have generated a certificate via: kubectl create secret tls wopi --key="wopi.public.fr.key" --cert="wopi.public.fr.crt"

In my configuration for helm I have a values.yaml to set properties. I have defined:

ingress:
    enabled: true
    className: "haproxy"
    annotations:
        # HAProxy
        haproxy.org/timeout-tunnel: "3600s"
        haproxy.org/backend-config-snippet: |
          mode http
          balance leastconn
          stick-table type string len 2048 size 1k store conn_cur
          http-request set-var(txn.wopisrcconns) url_param(WOPISrc),table_conn_cur()
          http-request track-sc1 url_param(WOPISrc)
          stick match url_param(WOPISrc) if { var(txn.wopisrcconns) -m int gt 0 }
          stick store-request url_param(WOPISrc)
    hosts:
        - host: wopi.public.fr
          paths:
            - path: /
              pathType: ImplementationSpecific
    tls:
        - secretName: wopi
          hosts:
            - wopi.public.fr

We can see on the screen below that my Ingress has the right TLS secret set and mapped to the host "wopi.public.fr"

But when I curl https://wopi.public.fr:31569 -vk

I got the wrong certificate (CN=kubernetes-ingress.haproxy-controller):

*   Trying 192.168.49.2:31569...
* Connected to wopi.public.fr (192.168.49.2) port 31569 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=kubernetes-ingress.haproxy-controller
*  start date: Dec  9 14:16:43 2022 GMT
*  expire date: Dec  9 14:16:43 2023 GMT
*  issuer: CN=kubernetes-ingress-ca
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* Using Stream ID: 1 (easy handle 0x564be2599910)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET / HTTP/2
> Host: wopi.public.fr:31569
> user-agent: curl/7.81.0
> accept: */*
> 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 200 
< date: Mon, 12 Dec 2022 15:59:47
< server: COOLWSD HTTP Server 22.05.6.3
< content-length: 2
< content-type: 10
< last-modified: Mon, 12 Dec 2022 15:59:47
< 
* Connection #0 to host wopi.public.fr left intact

Do you have any idea ? I can give much more information if needed.

This could be a silly question but are those resources (`Ingress` and `Secret`) in the same namespace? I had similar situation like that but with `nginx-ingress` some time ago. — Dawid Kruk, Dec 12 '22 at 16:26

score 0 · Answer 1 · answered Dec 13 '22 at 10:17

Try the below work around may help to resolve your issue :

Create your secret in the desired namespace
Create dummy ingress in the same namespace, reference the created secret normally

It seems nginx loads the ingress and associated secrets, and if there any other ingress in different namespace referenced the same shared secret by name it will be already loaded by the dummy ingress so nginx will use it.

To know how to reference the same shared secret by name from a different namespace,please find the below example configs :

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: dummy-load-certificates
  namespace: ingress-nginx
spec:
  tls:
  - hosts:
    - “*.example.com"
    secretName: cert-example.com
  rules:
  - host: “*.example.com"
 
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: example-app
  namespace: example-app
spec:
  tls:
  - hosts:
    - app.example.com
  rules:
    - host: app.example.com
      http:
        paths:
        - path: /
          backend:
            serviceName: example-app
            servicePort: 80

Please refer to TLS secrets from other namespaces (i.e. not the namespace in which ingress is created for more information.

Also refer to the short documentation on how to Enable TLS with Let’s Encrypt and the HAProxy Kubernetes Ingress Controller for more details.

Kubernetes Ingress TLS is set but a wrong certificate is served at the end

1 Answers1