Introduction

To use a custom client certificate for an external service in Istio, you normally combine three ideas: declare the external host, route traffic to it, and configure TLS origination with the client certificate material that the sidecar or gateway should present.

In current Istio, the key resources are usually ServiceEntry and DestinationRule. The certificate can be referenced through file paths or, more commonly, through a credential secret with credentialName when the workload setup supports it.

Declare The External Service

If the host is outside the mesh, declare it first with a ServiceEntry:

1apiVersion: networking.istio.io/v1
2kind: ServiceEntry
3metadata:
4  name: external-api
5spec:
6  hosts:
7  - api.external-service.com
8  ports:
9  - number: 443
10    name: tls
11    protocol: TLS
12  resolution: DNS
13  location: MESH_EXTERNAL

This tells Istio that traffic to api.external-service.com is an allowed external destination.

Configure TLS Origination With Client Credentials

Then attach TLS settings in a DestinationRule:

1apiVersion: networking.istio.io/v1
2kind: DestinationRule
3metadata:
4  name: external-api-tls
5spec:
6  host: api.external-service.com
7  trafficPolicy:
8    tls:
9      mode: MUTUAL
10      credentialName: external-api-client-cert
11      sni: api.external-service.com

The intent here is clear:

• 'mode: MUTUAL means Istio should perform mutual TLS when connecting outbound'
• 'credentialName points to the Kubernetes secret holding the client cert, key, and usually the CA material'
• 'sni ensures the TLS handshake uses the correct server name'

Understand Where The Secret Is Used

This part trips people up. Certificate handling depends on how the traffic leaves the mesh. For some patterns, especially when you are using an egress gateway or workload-selected configuration, credentialName is the cleanest setup. In other patterns, file-based references such as clientCertificate, privateKey, and caCertificates may still be used.

The practical takeaway is: do not just create a secret and assume every sidecar will automatically pick it up. Confirm how that secret is delivered to the proxy path you are configuring.

Secret Shape Matters

The referenced secret has to contain the expected TLS material. A common layout is certificate, private key, and CA certificate under the names Istio expects for SDS-driven TLS credentials. If the handshake fails, validate the secret contents before debugging routing rules.

Gateway Versus Sidecar Egress Matters

The exact certificate hookup can differ depending on whether traffic leaves through each workload sidecar or through a dedicated egress gateway. That is why the same host can work with one TLS configuration pattern in one mesh and need a slightly different credential-delivery path in another. Always match the certificate design to the actual egress path.

Test With The Real Handshake Path

A YAML configuration that looks correct is not enough. Confirm the real outbound handshake with logs or a controlled test call so you know the certificate is actually being presented by the expected proxy.

Common Pitfalls

• Creating a DestinationRule without first declaring the external host with ServiceEntry.
• Using SIMPLE TLS mode when the external service actually requires mutual TLS.
• Referencing a secret but not confirming that the proxy path you configured can use it.
• Forgetting sni for hosts whose certificate validation depends on the server name.
• Debugging routing first when the real failure is certificate format, trust chain, or secret placement.

Summary

• Use ServiceEntry to declare the external host.
• Use DestinationRule with mode: MUTUAL to enable client-certificate TLS origination.
• Reference client credentials through the supported secret or file-based mechanism for your workload path.
• Set sni to the external host when appropriate.
• When debugging, verify the secret contents and TLS mode before assuming the route is wrong.