Nginx Ingress Controller with Istio MTLS

Hi there,

I have a cluster that use Nginx Ingress and , and enabled auto MTLS for all services.

The internal services are all communicated fine with MTLS enabled and proper Peer Authentication policy applied, but i got an issue specifically for this communication link.

–> AWS ALB ----> Nginx Ingress Controller ----> Service


  1. default (injected with envoy sidecar). Applied with Peer Authentication Policy
  2. nginx-ingress (injected with envoy sidecar). No Policy applied

Updated with nginx-ingress-controller logs

2020/06/12 07:25:27 [error] 38#38: *5190 SSL_do_handshake() failed (SSL: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:SSL alert number 40) while SSL handshaking to 
upstream, client:, server:, request: "GET /admin/console.html 
HTTP/1.1", upstream: "https://10.100.xx.xx:443/admin/console.html", host: ""

When i remove the peer authentication policy for default namespace, the route works.

I think i do need some extra set-up or configuratio for non-istio ingress controller right? Appreciate if anyone can point me to a guide or reference :slight_smile:

Hi @robincher

see this task may this will help you.

Hi Shubham,

Thanks, i am actually trying to implement Nginx ingress instead.

So the ingress object i be configured with this nginx

Is this possible ?


AFAIK this annotation is used to tell istio gateway controller that it should this ingress.(if you want to use k8s ingress with istio.)
means which controller handle this ingress. if you mention ingress then may be you can’t access the services in the sevices mesh. (from Kubernetes 1.18, we can use ingress class instead of this annotation.)

Yes correct, i am using Nginx as the ingress controller rather than Istio ingress controller.

My question is, how can i configure it such that Nginx controller such that,it can communicate with other pods using MTLS.

Don’t know exactly by writing Nginx it work with istio. for my understanding it should not work(not sure.).

see this for tls.

This might be what you have in mind. The same pattern will work for any service upstream from an NGINX Ingress Controller.