Problem configuring ingress gateway with TLS and wildcard hosts

Networking
1

Hi,

I want to run the following setup:

  • a single ingress gateway that handles all the incoming traffic; example: *.dev000.k8s.dev
  • a single ingress gateway for each subdomain; example: *.dev000.k8s.dev, *.dev001.k8s.dev, etc.
  • a virtual service for each separate URL; example: app1.dev000.k8s.dev, app2.dev001.k8s.dev, etc.; the virtual services are mapped to respective gateway based on the subdomain;
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: app1
spec:
  hosts:
  - "app1.dev003.k8s.dev"
  gateways:
  - dev003
  http:
  - match:
    - uri:
        exact: /
    route:
    - destination:
        host: app1
        port:
          number: 8080
  • the ingress gateways configured with simple TLS;

Unfortunately, I have problems configuring ingress gateway with TLS and wildcard host.

When I configure the ingress gateway with host “*****” everything works fine.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: dev003
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 443
      name: http-443
      protocol: HTTPS
    tls:
      mode: SIMPLE
      serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
      privateKey: /etc/istio/ingressgateway-certs/tls.key
    hosts:
    - '*'

When I configure the ingress gateway with host “*.dev003.k8s.dev” load balancing stops working.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: dev003
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 443
      name: http-443
      protocol: HTTPS
    tls:
      mode: SIMPLE
      serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
      privateKey: /etc/istio/ingressgateway-certs/tls.key
    hosts:
    - '*.dev003.k8s.dev'

The error when I try to access my application using cURL is the following one:

curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to <someid>.eu-central-1.elb.amazonaws.com:443

Moreover, when the ingress gateway is not configured to work with TLS, this wildcard hostname configuration works.

This is with Istio version 1.5.1. I also tried version 1.4.7, but the behavior is the same.

Is this expected behavior or I am not configuring something properly?

Since this is the first time that I am posting here, I apologize if I am not posting all the needed information in order to properly describe the issue.

Regards,
Rashid

2

Hi,

Can you please double check the SSL cert to ensure the CN is fine (and the alternate name too) for using a star ?
Instead of curl, can you check connecting with openssl and double check the certs too ?
Can you also provide your curl command ?

As a side note, you should also use gateway SDS to provide the certificate, but this has nothing to do with your issue.

4

I’ve hit this exact issue on 1.5.2.
Do you solve the problem?

5

Hello,

First of all, I would like to deeply apologize for delaying my answer for so long. I am really sorry.

The good news is that the issue is solved. So Deasun could address it issue as well.

So, what was the issue and the solution: the K8S cluster where I was playing with Istio was deployed on AWS. It was not deployed using EKS. AWS was just used just as a compute resource provider. Anyway, the key moment was the way the LoadBalancer K8S services were implemented. It was implemented using AWS ELB service. This is why the ingress service had an external IP that looked something like *****.eu-west-1.elb.amazonaws.com. This was also the hostname that I used in order to access the ingress service and therefore the Istio gateway. Here is the key point. What Istio was trying to do is to match the provided hostname, *****.eu-west-1.elb.amazonaws.com, with the hostname defined in the certificate configured in the gateway, *.dev003.k8s.dev. As you can imagine, they do not match. This is why Istio was returning the mentioned above SSL error.

What was the fix. In mu case, it was to use the --resolve parameter of cURL command that I used in order to test Istio. Basically I provided a resolve parameter to match the requested host to the IP address that the ELB hostname is eventually resolved. When I did that, it worked.

In production environment you will have a DNS configuration so this kind of hack will not be needed and everything will work without any issues.

So, this was the problem I faced and the solution that worked for me. Let me know if it worked for you.

Regards,
Rashid