Egress traffic to external service with self-signed certificate

Networking
1

Hello, I am having difficulty getting workloads running in an istio mesh to trust the certificate provided by an external service running on an ec2 instance. At the moment, I am running the external service behind an nginx reverse proxy configured to use a self-signed certificate. In the future, there will be a certificate signed by a private CA, but I assume as far as Istio is concerned the process will be the same. Based on my limited knowledge of TLS, I think getting the mesh to trust the root.crt of the self-signed certificate should be sufficient to enabling communication. So, I am trying to use ClientTLSSettings.TLSmode of SIMPLE and pass in the root.crt via the credentialName field. I have no idea if this can work or not.

To keep things simple, I have istio 1.14.4 deployed into an EKS cluster with the istio-egressgateway enabled. I have a namespace with istio injection enabled that is running a single nginx pod. Before any Istio configuration, a curl request to https://my-service.my-domain.com returns the expected error:
curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: https://curl.se/docs/sslcerts.html

If I explicitly provide the cert using the --cacert flag I am able to successfully hit the URL over HTTPS from outside the mesh (I get the same error if I manually provide the cert while inside the mesh).

So I created a secret in my nginx namespace and set the cacert key to the root.crt:
kubectl create secret generic client-credential --from-file=cacert=my-domain.com.crt -n nginx

I then applied a DestinationRule that referenced the secret:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: simple-tls
  namespace: nginx
spec:
  workloadSelector:
    matchLabels:
      app: nginx
  host: my-service.my-domain.com
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
    portLevelSettings:
    - port:
        number: 443
      tls:
        mode: SIMPLE
        credentialName: client-credential

Curl command returned the same message. I looked into the MUTUAL and ISTIO_MUTUAL modes, but I feel like they’re overkill for this use case. I do not need two way encryption, only for the mesh to trust the root.crt. I am not even sure how to validate that the DestinationRule is even being used. Maybe I need to have it deployed with a gateway and a virtual service? Not sure.

I could be way off here. Any advice would be appreciated.

Thank you

2

Since you’re calling an external service (i.e., not in the mesh), you’ll have to create a ServiceEntry.