[bitnami/keycloak] Ingress with TLS doesn't handshake

[Pyrrha]

Name and Version

bitnami/keycloak 24.3.2

What architecture are you using?

amd64

What steps will reproduce the bug?

1. Deploy ingress-nginx with cert-manager and a let's encrypt issuer
2. Deploy the bitnami/keycloak chart with following values
3. Ensure that the certificate has been correctly created
4. 502 error occurs

Are you using any custom parameters or values?

keycloak: # using umbrella chart
  [... externalDatabase, replicaCount, auth...]

  ingress:
    enabled: true
    ingressClassName: nginx
    hostname: auth.domain.org
    annotations:
      cert-manager.io/cluster-issuer: letsencrypt
      nginx.ingress.kubernetes.io/backend-protocol: HTTPS
    extraTls:
      - hosts:
          - auth.domain.org
        secretName: keycloak-cert


  adminIngress:
    enabled: true
    tls: true
    ingressClassName: nginx
    hostname: auth-admin.domain.org
    annotations:
      cert-manager.io/cluster-issuer: letsencrypt
      nginx.ingress.kubernetes.io/backend-protocol: HTTPS
    extraTls:
      - hosts:
          - auth-admin.domain.org
        secretName: keycloak-admin-cert

What is the expected behavior?

The Keycloak GUI to be accessible through HTTPS.

What do you see instead?

502 Bad Gateway

nginx

I tested from the pod itself:

• curl -v localhost:8080 -> 302 Found
• curl -v keycloak.keycloak.svc.cluster.local:80 -> 302 Found
• curl -v keycloak.keycloak.svc.cluster.local:443 -> Trying x.x.x.x:443... (timeout)

From a web browser, the logs of the ingress-controller pod:

192.168.1.51 - - [13/Jan/2025:22:56:45 +0000] "GET / HTTP/2.0" 502 150 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.2 Safari/605.1.15" 252 0.008 [keycloak-keycloak-http] [] 10.108.173.235:8080, 10.108.173.235:8080, 10.108.173.235:8080 0, 0, 0 0.004, 0.002, 0.002 502, 502, 502 61584084e954318c1045b0f72839204d
2025/01/13 22:57:45 [crit] 4782#4782: *14971082 SSL_do_handshake() failed (SSL: error:0A0000C6:SSL routines::packet length too long error:0A000139:SSL routines::record layer failure) while SSL handshaking to upstream, client: 192.168.1.51, server: auth-admin.domain.org, request: "GET / HTTP/1.1", upstream: "https://10.108.173.235:8080/", host: "auth-admin.domain.org"
2025/01/13 22:57:45 [crit] 4782#4782: *14971082 SSL_do_handshake() failed (SSL: error:0A0000C6:SSL routines::packet length too long error:0A000139:SSL routines::record layer failure) while SSL handshaking to upstream, client: 192.168.1.51, server: auth-admin.domain.org, request: "GET / HTTP/1.1", upstream: "https://10.108.173.235:8080/", host: "auth-admin.domain.org"
2025/01/13 22:57:45 [crit] 4782#4782: *14971082 SSL_do_handshake() failed (SSL: error:0A0000C6:SSL routines::packet length too long error:0A000139:SSL routines::record layer failure) while SSL handshaking to upstream, client: 192.168.1.51, server: auth-admin.domain.org, request: "GET / HTTP/1.1", upstream: "https://10.108.173.235:8080/", host: "auth-admin.domain.org"
192.168.1.51 - - [13/Jan/2025:22:57:45 +0000] "GET / HTTP/1.1" 502 150 "-" "Mozilla/5.0 (X11; Linux i686; rv:109.0) Gecko/20100101 Firefox/120.0" 357 0.003 [keycloak-keycloak-http] [] 10.108.173.235:8080, 10.108.173.235:8080, 10.108.173.235:8080 0, 0, 0 0.002, 0.000, 0.001 502, 502, 502 fbbc0c6a260db2b217b8c0b1e4612e9f

Additional information

I've looked at #8198, as the problem looked similar. But I didn't make it through.

I'm not sure of my values configuration, maybe I forgot something.

[carrodher]

Hi, the issue may not be directly related to the Bitnami container image/Helm chart, but rather to how the application is being utilized, configured in your specific environment, or tied to a particular scenario that is not easy to reproduce on our side.

If you think that's not the case and want to contribute a solution, we'd like to invite you to create a pull request. The Bitnami team is excited to review your submission and offer feedback. You can find the contributing guidelines here.

Your contribution will greatly benefit the community. Please feel free to contact us if you have any questions or need assistance.

If you have any questions about the application, customizing its content, or using technology and infrastructure, we highly recommend that you refer to the forums and user guides provided by the project responsible for the application or technology.

With that said, we'll keep this ticket open until the stale bot automatically closes it, in case someone from the community contributes valuable insights.

[Pyrrha]

Hi, it was environment-related, indeed.

Activating proxy: edge fix the connection issue. I'll look further for replacing this deprecated option with proxyHeaders, as I've to dig in my reverse proxy.

Thanks.