Ingress returns wrong certificate for specific http clients

[Captain-P-Goldfish]

Hi I got a strange phenomena and I am not able to get to the root of the source.

I am using docker-desktop: v1.22.4 and the ingress-nginx-controller with the following config:

containers:
        - name: controller
          image: >-
            k8s.gcr.io/ingress-nginx/controller:v0.41.2@sha256:1f4f402b9c14f3ae92b11ada1dfe9893a88f0faeb0b2f4b903e2c67a0c3bf0de
          args:
            - /nginx-ingress-controller
            - '--publish-service=$(POD_NAMESPACE)/ingress-nginx-controller'
            - '--election-id=ingress-controller-leader'
            - '--ingress-class=nginx'
            - '--configmap=$(POD_NAMESPACE)/ingress-nginx-controller'
            - '--validating-webhook=:8443'
            - '--validating-webhook-certificate=/usr/local/certificates/cert'
            - '--validating-webhook-key=/usr/local/certificates/key'

Under specific circumstances the ingress-controller returns the fake-certificate instead of the configured one. I created the following ingress config:

kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
  name: my-keycloak
spec:
  tls:
    - hosts:
        - my-keycloak
      secretName: my-keycloak-tls-secret
  rules:
    - host: my-keycloak
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-keycloak
                port:
                  number: 80

When accessing the url "https://my-keycloak" in the browser the correct certificate is returned:

same result when using openssl:

echo | openssl s_client -showcerts -servername my-keycloak -connect my-keycloak:443 2>/dev/null | openssl x509 -inform pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1639646163 (0x61bb03d3)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = my-keycloak
        Validity
            Not Before: Dec 16 09:16:03 2021 GMT
            Not After : Dec 16 09:16:03 2121 GMT
        Subject: CN = my-keycloak
        Subject Public Key Info:

BUT if I use the java apache http-client to access the page I suddenly get the fake-certificate:

I am struggling with this for a whole day now and cannot figure out what is causing this problem...

[k8s-ci-robot]

@Captain-P-Goldfish: This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[longwuyuan]

/remove-kind bug /kind support Please install the most recent release of the ingress-nginx controller and update status https://kubernetes.github.io/ingress-nginx/deploy/

[Captain-P-Goldfish]

I created a sample that is reproducing the problem

1. uninstalled old ingress-nginx setup
2. installed new ingress-nginx setup with

   helm upgrade --install ingress-nginx ingress-nginx --repo https://kubernetes.github.io/ingress-nginx --namespace ingress-nginx --create-namespace

   resulted in

   image: >-
           k8s.gcr.io/ingress-nginx/controller:v1.1.0@sha256:f766669fdcf3dc26347ed273a55e754b427eb4411ee075a53f30718b4499076a

3. installed the attached helm-chart that installs a keycloak without database but with tls on ingress side my-keycloak-sample.zip

helm install my-keycloak-sample my-keycloak-sample --namespace keycloak-test --create-namespace

4. created an entry in my hosts file

   127.0.0.1 my-keycloak-sample

5. download the following file and rename the zipto jar (github does not support uploading jar-files so I just renamed it to zip). It is a jar file that contains the following code: get-server-cert-1.0.zip

and execute it with java -cp .\get-server-cert-1.0.jar GetServerCert "https://my-keycloak-sample/"

import java.io.FileOutputStream;
import java.io.IOException;
import java.net.URL;
import java.security.KeyManagementException;
import java.security.NoSuchAlgorithmException;
import java.security.SecureRandom;
import java.security.cert.Certificate;
import java.security.cert.CertificateEncodingException;
import java.security.cert.CertificateException;
import java.security.cert.CertificateExpiredException;
import java.security.cert.CertificateNotYetValidException;
import java.security.cert.X509Certificate;

import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLContext;
import javax.net.ssl.X509TrustManager;

/**
 * @author Pascal Knueppel
 * @since 22.12.2021
 */
public class GetServerCert
{

  public static void main(String[] args) throws CertificateNotYetValidException, CertificateEncodingException,
    IOException, NoSuchAlgorithmException, KeyManagementException
  {
    getTlsCertificate(args[0]);
  }

  public static void getTlsCertificate(String url) throws IOException, CertificateEncodingException,
    CertificateNotYetValidException, KeyManagementException, NoSuchAlgorithmException
  {
    SSLContext context = SSLContext.getInstance("TLS");
    context.init(null, new X509TrustManager[]{new X509TrustManager()
    {

      public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException
      {}

      public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException
      {}

      public X509Certificate[] getAcceptedIssuers()
      {
        return new X509Certificate[0];
      }
    }}, new SecureRandom());

    URL destinationURL = new URL(url);
    HttpsURLConnection conn = (HttpsURLConnection)destinationURL.openConnection();
    conn.setHostnameVerifier((s, sslSession) -> true);
    conn.setSSLSocketFactory(context.getSocketFactory());
    conn.connect();
    Certificate[] certs = conn.getServerCertificates();
    System.out.println("nb = " + certs.length);
    int i = 1;
    for ( Certificate cert : certs )
    {
      System.out.println("");
      System.out.println("");
      System.out.println("");
      System.out.println("################################################################");
      System.out.println("");
      System.out.println("");
      System.out.println("");
      System.out.println("Certificate is: " + cert);
      if (cert instanceof X509Certificate)
      {
        try
        {
          ((X509Certificate)cert).checkValidity();
          System.out.println("Certificate is active for current date");
          FileOutputStream os = new FileOutputStream("./cert-" + i + ".cer");
          i++;
          os.write(cert.getEncoded());
        }
        catch (CertificateExpiredException cee)
        {
          System.out.println("Certificate is expired");
        }
      }
      else
      {
        System.err.println("Unknown certificate type: " + cert);
      }
    }
  }
}

6. verify that the ingress-fake-certificate is returned by this code
7. verify that the browser shows the correct certificate with "my-keycloak-sample"

[longwuyuan]

Ingress rule is configured with host value different from http request header hostname.

Thanks, ; Long

On Thu, 23 Dec, 2021, 1:03 AM Pascal Knüppel, @.***> wrote:

I created a sample that is reproducing the problem

1. uninstalled old ingress-nginx setup
2. installed new ingress-nginx setup with

helm upgrade --install ingress-nginx ingress-nginx --repo https://kubernetes.github.io/ingress-nginx --namespace ingress-nginx --create-namespace

resulted in

image: >- @.***:f766669fdcf3dc26347ed273a55e754b427eb4411ee075a53f30718b4499076a

1. installed the attached helm-chart that installs a keycloak without database but with tls on ingress side

helm install my-keycloak-sample my-keycloak-sample --namespace keycloak-test --create-namespace

1. created an entry in my hosts file

127.0.0.1 my-keycloak-sample

1. download the following file and rename the zipto jar (github does not support uploading jar-files so I just renamed it to zip). It is a jar file that contains the following code: get-server-cert-1.0.zip https://github.com/kubernetes/ingress-nginx/files/7764788/get-server-cert-1.0.zip

and execute it with java -cp .\get-server-cert-1.0.jar GetServerCert " https://my-keycloak-sample/"

import java.io.FileOutputStream;import java.io.IOException;import java.net.URL;import java.security.KeyManagementException;import java.security.NoSuchAlgorithmException;import java.security.SecureRandom;import java.security.cert.Certificate;import java.security.cert.CertificateEncodingException;import java.security.cert.CertificateException;import java.security.cert.CertificateExpiredException;import java.security.cert.CertificateNotYetValidException;import java.security.cert.X509Certificate; import javax.net.ssl.HttpsURLConnection;import javax.net.ssl.SSLContext;import javax.net.ssl.X509TrustManager;

/* @author Pascal Knueppel @since 22.12.2021 /public class GetServerCert {

public static void main(String[] args) throws CertificateNotYetValidException, CertificateEncodingException, IOException, NoSuchAlgorithmException, KeyManagementException { getTlsCertificate(args[0]); }

public static void getTlsCertificate(String url) throws IOException, CertificateEncodingException, CertificateNotYetValidException, KeyManagementException, NoSuchAlgorithmException { SSLContext context = SSLContext.getInstance("TLS"); context.init(null, new X509TrustManager[]{new X509TrustManager() {

  public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException
  {}

  public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException
  {}

  public X509Certificate[] getAcceptedIssuers()
  {
    return new X509Certificate[0];
  }
}}, new SecureRandom());

URL destinationURL = new URL(url);
HttpsURLConnection conn = (HttpsURLConnection)destinationURL.openConnection();
conn.setHostnameVerifier((s, sslSession) -> true);
conn.setSSLSocketFactory(context.getSocketFactory());
conn.connect();
Certificate[] certs = conn.getServerCertificates();
System.out.println("nb = " + certs.length);
int i = 1;
for ( Certificate cert : certs )
{
  System.out.println("");
  System.out.println("");
  System.out.println("");
  System.out.println("################################################################");
  System.out.println("");
  System.out.println("");
  System.out.println("");
  System.out.println("Certificate is: " + cert);
  if (cert instanceof X509Certificate)
  {
    try
    {
      ((X509Certificate)cert).checkValidity();
      System.out.println("Certificate is active for current date");
      FileOutputStream os = new FileOutputStream("./cert-" + i + ".cer");
      i++;
      os.write(cert.getEncoded());
    }
    catch (CertificateExpiredException cee)
    {
      System.out.println("Certificate is expired");
    }
  }
  else
  {
    System.err.println("Unknown certificate type: " + cert);
  }
}

} }

1. verify that the ingress-fake-certificate is returned by this code
2. verify that the browser shows the correct certificate with "my-keycloak-sample"

— Reply to this email directly, view it on GitHub https://github.com/kubernetes/ingress-nginx/issues/8063#issuecomment-999815809, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGZVWSLUZE6PSCLA3RIXV3USIRX3ANCNFSM5KR7OZTA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[Captain-P-Goldfish]

I think I do not understand what you are trying to tell me... From my opinion ingress-rule and http-request are completely identical. Could you please clarify?

[longwuyuan]

Check the value of the host field in the ingress and the value of the hostname header in your https request. They seem to be different as per what is posted in this issue

[Captain-P-Goldfish]

yes that is true. The second post is a minimal example for recreating the problem. The first post was the setup where I noticed it and then I recreated a second example that runs into the same error.

[longwuyuan]

In this command

java -cp .\get-server-cert-1.0.jar GetServerCert "https://my-keycloak-sample/"

the hostname is my-keycloak-sample.

So show the ingress configuration which has a matching rule for that. And then show the logs of the controller pod for that request

[Captain-P-Goldfish]

I added a zip file above as attachement that contains the helm-chart. Everythings in there. But just in case here again:

my-keycloak-sample.zip

The nginx controller were not producing any output so I extended the java-program to read the body of the given url and thus the result from call: java -cp .\get-server-cert-1.0.jar GetServerCert "https://my-keycloak-sample/auth/realms/master/.well-known/openid-configuration"

is:

{"issuer":"https://my-keycloak-sample/auth/realms/master","authorization_endpoint":"https://my-keycloak-sample/auth/realms/master/protocol/openid-connect/auth","token_endpoint":"https://my-keycloak-sample/auth/realms/master/protocol/openid-connect/token","introspection_endpoint":"https://my-keycloak-sample/auth/realms/master/protocol/openid-connect/token/introspect","userinfo_endpoint":"https://my-keycloak-sample/auth/realms/master/protocol/openid-connect/userinfo","end_session_endpoint":"https://my-keycloak-sample/auth/realms/master/protocol/openid-connect/logout","frontchannel_logout_session_supported":true,"frontchannel_logout_supported":true,"jwks_uri":"https://my-keycloak-sample/auth/realms/master/protocol/openid-connect/certs","check_session_iframe":"https://my-keycloak-sample/auth/realms/master/protocol/openid-connect/login-status-iframe.html","grant_types_supported":["authorization_code","implicit","refresh_token","password","client_credentials","urn:ietf:params:oauth:grant-type:device_code","urn:openid:params:grant-type:ciba"],"response_types_supported":["code","none","id_token","token","id_token token","code id_token","code token","code id_token token"],"subject_types_supported":["public","pairwise"],"id_token_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512"],"id_token_encryption_alg_values_supported":["RSA-OAEP","RSA-OAEP-256","RSA1_5"],"id_token_encryption_enc_values_supported":["A256GCM","A192GCM","A128GCM","A128CBC-HS256","A192CBC-HS384","A256CBC-HS512"],"userinfo_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512","none"],"request_object_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512","none"],"request_object_encryption_alg_values_supported":["RSA-OAEP","RSA-OAEP-256","RSA1_5"],"request_object_encryption_enc_values_supported":["A256GCM","A192GCM","A128GCM","A128CBC-HS256","A192CBC-HS384","A256CBC-HS512"],"response_modes_supported":["query","fragment","form_post","query.jwt","fragment.jwt","form_post.jwt","jwt"],"registration_endpoint":"https://my-keycloak-sample/auth/realms/master/clients-registrations/openid-connect","token_endpoint_auth_methods_supported":["private_key_jwt","client_secret_basic","client_secret_post","tls_client_auth","client_secret_jwt"],"token_endpoint_auth_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512"],"introspection_endpoint_auth_methods_supported":["private_key_jwt","client_secret_basic","client_secret_post","tls_client_auth","client_secret_jwt"],"introspection_endpoint_auth_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512"],"authorization_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512"],"authorization_encryption_alg_values_supported":["RSA-OAEP","RSA-OAEP-256","RSA1_5"],"authorization_encryption_enc_values_supported":["A256GCM","A192GCM","A128GCM","A128CBC-HS256","A192CBC-HS384","A256CBC-HS512"],"claims_supported":["aud","sub","iss","auth_time","name","given_name","family_name","preferred_username","email","acr"],"claim_types_supported":["normal"],"claims_parameter_supported":true,"scopes_supported":["openid","microprofile-jwt","address","offline_access","phone","profile","web-origins","email","roles"],"request_parameter_supported":true,"request_uri_parameter_supported":true,"require_request_uri_registration":true,"code_challenge_methods_supported":["plain","S256"],"tls_client_certificate_bound_access_tokens":true,"revocation_endpoint":"https://my-keycloak-sample/auth/realms/master/protocol/openid-connect/revoke","revocation_endpoint_auth_methods_supported":["private_key_jwt","client_secret_basic","client_secret_post","tls_client_auth","client_secret_jwt"],"revocation_endpoint_auth_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512"],"backchannel_logout_supported":true,"backchannel_logout_session_supported":true,"device_authorization_endpoint":"https://my-keycloak-sample/auth/realms/master/protocol/openid-connect/auth/device","backchannel_token_delivery_modes_supported":["poll","ping"],"backchannel_authentication_endpoint":"https://my-keycloak-sample/auth/realms/master/protocol/openid-connect/ext/ciba/auth","backchannel_authentication_request_signing_alg_values_supported":["PS384","ES384","RS384","ES256","RS256","ES512","PS256","PS512","RS512"],"require_pushed_authorization_requests":false,"pushed_authorization_request_endpoint":"https://my-keycloak-sample/auth/realms/master/protocol/openid-connect/ext/par/request","mtls_endpoint_aliases":{"token_endpoint":"https://my-keycloak-sample/auth/realms/master/protocol/openid-connect/token","revocation_endpoint":"https://my-keycloak-sample/auth/realms/master/protocol/openid-connect/revoke","introspection_endpoint":"https://my-keycloak-sample/auth/realms/master/protocol/openid-connect/token/introspect","device_authorization_endpoint":"https://my-keycloak-sample/auth/realms/master/protocol/openid-connect/auth/device","registration_endpoint":"https://my-keycloak-sample/auth/realms/master/clients-registrations/openid-connect","userinfo_endpoint":"https://my-keycloak-sample/auth/realms/master/protocol/openid-connect/userinfo","pushed_authorization_request_endpoint":"https://my-keycloak-sample/auth/realms/master/protocol/openid-connect/ext/par/request","backchannel_authentication_endpoint":"https://my-keycloak-sample/auth/realms/master/protocol/openid-connect/ext/ciba/auth"}}
nb = 1

################################################################

Certificate is: [
[
  Version: V3
  Subject: CN=Kubernetes Ingress Controller Fake Certificate, O=Acme Co
  Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11

  Key:  Sun RSA public key, 2048 bits
  params: null
  modulus: 23453582780883203696031355904692320497037296244514676647043824274691071070133669360329158929218158964330289991467950072058293542886287619416267522994443445793780671522710780285229414536534222947409847920755446285487748656277647359861954947554860437925750528525059610140675037294297659358703624095387924727381099311659578506953112651786687476130411012079182621378487441656294411170136219159388101833802531242646257170950599730417499942698219191595275610174129373453159791984164377154322591170612974506524757996997472487370081992310612387965644224652700359501752053780487157433117339500632745303774263819451125491983413
  public exponent: 65537
  Validity: [From: Thu Dec 23 17:01:31 CET 2021,
               To: Fri Dec 23 17:01:31 CET 2022]
  Issuer: CN=Kubernetes Ingress Controller Fake Certificate, O=Acme Co
  SerialNumber: [    a73ce50b a590eb47 0189e503 97c7d65f]

Certificate Extensions: 4
[1]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:false
  PathLen: undefined
]

[2]: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
  serverAuth
]

[3]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  DigitalSignature
  Key_Encipherment
]

[4]: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
  DNSName: ingress.local
]

]
  Algorithm: [SHA256withRSA]
  Signature:
0000: 30 D6 70 57 54 76 0F 94   62 FC 83 ED 9E 53 37 D1  0.pWTv..b....S7.
0010: EB 78 FF DC 6B 6A 36 F3   77 D5 E6 1C 1F 7F 1E BD  .x..kj6.w.......
0020: 4F AB 7F 7F DC 95 FE F8   DD 80 79 F2 74 09 A4 47  O.........y.t..G
0030: 04 A8 A7 F4 D4 28 7E B3   D9 9F AA 39 ED EE C3 55  .....(.....9...U
0040: 55 2E 52 7D B3 85 2D 1F   61 D5 DA 36 C6 47 6B 84  U.R...-.a..6.Gk.
0050: 84 5C AB 64 C3 00 3B 52   C6 82 20 99 01 7B B5 3D  .\.d..;R.. ....=
0060: E6 91 C4 10 A0 25 B2 8C   64 0B EF 65 5D 91 50 5B  .....%..d..e].P[
0070: B1 55 AB 1E 4F D0 AF 9A   B8 02 3B 40 26 B9 6D B4  .U..O.....;@&.m.
0080: 08 9A 47 84 E0 BA 98 38   8C 85 0B 66 4D FD A6 F3  ..G....8...fM...
0090: 45 20 D6 75 48 2D 33 F4   64 3B 3C 8C 30 FD 42 B0  E .uH-3.d;<.0.B.
00A0: D4 E9 B6 13 BF 9D 16 C9   C5 40 23 05 2E A6 21 B2  .........@#...!.
00B0: 7E 33 52 81 53 21 50 92   57 A6 24 3D 6F 50 40 D9  .3R.S!P.W.$=oP@.
00C0: EC 6D C9 AE D0 6F 17 82   C7 21 1A 55 AB D4 21 65  .m...o...!.U..!e
00D0: 83 74 1D 9A 3A 67 7D FA   A8 E0 19 1D BF C2 FD BB  .t..:g..........
00E0: 0C 80 9D 34 74 70 63 C8   79 D9 7C 4D 18 A8 2D 92  ...4tpc.y..M..-.
00F0: 49 C5 0E 16 D2 6B 3B AF   2B 3D E6 E9 53 7D 86 1A  I....k;.+=..S...

]
Certificate is active for current date

and this produces the log output in ingress-nginx-controller:

192.168.65.3 - - [23/Dec/2021:17:08:28 +0000] "GET /auth/realms/master/.well-known/openid-configuration HTTP/1.1" 200 5791 "-" "Java/11.0.12" 207 0.005 [keycloak-test-my-keycloak-sample-80] [] 10.1.1.164:8080 5791 0.010 200 5b323139ca7144127001dda4343a630c

and as I said if I access the very same URL with firefox or chrome the correct certificate is presented.

EDIT: By the way I got several setups and I noticed that the only nodes producing this problem until now are the nodes with keycloak. Any suggestions on that?

[longwuyuan]

@manikanth04 , if you want I can pair with you on this one

[manikanth04]

Ok @longwuyuan , will contact you with my preparation

[nycza]

FYI, we noticed the same issue with openssl 1.0 (working fine with openssl 1.1)
It also makes ssl_verify_client optional_no_ca send a x-client-verify: NONE without the certificate in ssl-client-cert header (while it works fine with openssl 1.1)

[vinay01tech]

@manikanth04 Any update on this issue ?

[longwuyuan]

@vinay01tech what is the update you are looking for.

I made a comment on the hostname to @Captain-P-Goldfish and its likely I missed something. But it does not look like there is a response to my comment. The important aspect here is that if you configure a global cert then you get the that cert. And even with a global cert configured, you can override the cert being presented in the tls config of the ingress. The hostname of the request sent to the ingress-controller must match the tls config and the host fields.

@manikanth04 is working n this and can hopefully have an update when he is completed his process. But even then the critical info that needs clarification is this list below ;

• https request hostname header
• tls config of the ingress object
• hostname field of the ingress object
• existence of the named secret containing the cert with the hostname from request in the subject or alternatives
• log messages of the controller pod that are related to the https request being made

I already pointed out the hostname of the java app request seems suspect. So clarification on that will help make progress

[Captain-P-Goldfish]

@longwuyuan there is a response to your comment. I posted a zip file that contains the complete helm chart so that you are able to verify the behaviour. And as I said this happens only under specific circumstances that I were not able to identify.

EDIT: It works in browsers it works with openssl but not with JVM http clients for example

[longwuyuan]

I was hoping to get clarity on the hostname in the request sent by java app. It's different from the config in ingress.

Thanks, ; Long

On Wed, 19 Jan, 2022, 5:43 PM Pascal Knüppel, @.***> wrote:

@longwuyuan https://github.com/longwuyuan there is a response to your comment. I posted a zip file that contains the complete helm chart so that you are able to verify the behaviour. And as I said this happens only under specific circumstances that I were not able to identify.

— Reply to this email directly, view it on GitHub https://github.com/kubernetes/ingress-nginx/issues/8063#issuecomment-1016408790, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGZVWSQKF2ZRJSZV7KOIFLUW2THDANCNFSM5KR7OZTA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[Captain-P-Goldfish]

here are the http-headers:

GET https://my-keycloak-sample/auth/realms/master/.well-known/openid-configuration HTTP/1.1
User-Agent: Java/11.0.12
Host: my-keycloak-sample
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

[longwuyuan]

Here are 2 data points that need clarification ;

(1) Ingress object config relevant to hostname. The value is "my-keycloak". This implies that your https request must use "my-keycloak" as hostname to match this rule ;

spec:
  tls:
    - hosts:
        - my-keycloak
      secretName: my-keycloak-tls-secret
  rules:
    - host: my-keycloak

(2) This is the 3rd time I am indicating that the https request seen in the messages posted don't use the hostname "my-keycloak". I could be wrong, but you have repeatedly posted messages that the https requests, facing the cert problem, use the hostname "my-keycloak-sample". That is expected as these requests will not match the ingress rule tls configuration

I don't see any other relevant info. Wait for other comments/messages

[Captain-P-Goldfish]

You downloaded the first example. I provided a second example in the post later that uses the hostname my-keycloak-sample:

# Source: my-keycloak-sample/templates/keycloak-ingress.yml
kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
  name: my-keycloak-sample
  annotations:
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - my-keycloak-sample
      secretName: my-keycloak-tls-secret
  rules:
    - host: my-keycloak-sample
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-keycloak-sample
                port:
                  number: 80

[longwuyuan]

I think you can help if you provide all related info in a single post. It's the current state of controller, ingress, service, pod, logs, request, response that can throw some light.

Thanks, ; Long

On Thu, 20 Jan, 2022, 5:35 PM Pascal Knüppel, @.***> wrote:

You downloaded the first example. I provided a second example in the post later that uses the hostname my-keycloak-sample:

Source: my-keycloak-sample/templates/keycloak-ingress.ymlkind: IngressapiVersion: networking.k8s.io/v1metadata:

name: my-keycloak-sample annotations: nginx.ingress.kubernetes.io/force-ssl-redirect: "true"spec: ingressClassName: nginx tls:

• hosts:
  • my-keycloak-sample secretName: my-keycloak-tls-secret rules:
• host: my-keycloak-sample http: paths:
  • path: / pathType: Prefix backend: service: name: my-keycloak-sample port: number: 80

— Reply to this email directly, view it on GitHub https://github.com/kubernetes/ingress-nginx/issues/8063#issuecomment-1017430089, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGZVWRVXIZZ3O64SFXMBN3UW73B7ANCNFSM5KR7OZTA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[nycza]

FYI, in our case the issue was coming from the client not sending SNI info, only the host.

[longwuyuan]

@nycza thnx. Yes, that and any other kind of a mismatch, between the header in the request and the tls configuration in the ingress, is the only logical reason to present the wrong cert.

[Captain-P-Goldfish]

Could you explain this for dummies? What is the mechanism that causes this problem?

[longwuyuan]

Its documented

https://kubernetes.io/docs/concepts/services-networking/ingress/#tls

https://kubernetes.github.io/ingress-nginx/user-guide/tls/#tlshttps

% k explain ingress.spec.tls
KIND:     Ingress
VERSION:  networking.k8s.io/v1

RESOURCE: tls <[]Object>

DESCRIPTION:
     TLS configuration. Currently the Ingress only supports a single TLS port,
     443. If multiple members of this list specify different hosts, they will be
     multiplexed on the same port according to the hostname specified through
     the SNI TLS extension, if the ingress controller fulfilling the ingress
     supports SNI.

     IngressTLS describes the transport layer security associated with an
     Ingress.

FIELDS:
   hosts        <[]string>
     Hosts are a list of hosts included in the TLS certificate. The values in
     this list must match the name/s used in the tlsSecret. Defaults to the
     wildcard host setting for the loadbalancer controller fulfilling this
     Ingress, if left unspecified.

   secretName   <string>
     SecretName is the name of the secret used to terminate TLS traffic on port
     443. Field is left optional to allow TLS routing based on SNI hostname
     alone. If the SNI host in a listener conflicts with the "Host" header field
     used by an IngressRule, the SNI host is used for termination and value of
     the Host header is used for routing.

[Captain-P-Goldfish]

great, thx. I finally know what the problem exactly is and how to proceed. Thx for your support.

[longwuyuan]

Glad resolved