Mutual TLS Architecture¶

Azure App Service supports mutual TLS in multiple places, but the trust boundary is different in each one. For production design, separate inbound client certificate authentication, outbound client certificate presentation, and App Service Environment (ASE) ingress topology instead of treating all three as the same feature.

Main Content¶

The three mTLS planes in App Service¶

flowchart TD
    Client[External client with certificate] --> FE[App Service front end]
    FE --> Header[X-ARR-ClientCert header]
    Header --> App[Web app code]
    App --> Store[Loaded private certificate]
    Store --> Remote[Remote API requiring mTLS]
    Corp[Corporate or private network] --> ASE[ASE or ILB ASE ingress]
    ASE --> FE

App Service mTLS has three distinct planes:

The important architecture rule is that inbound mTLS and outbound mTLS are independent. Enabling client certificates for inbound requests does not automatically give your app a client certificate for outbound calls, and uploading a private certificate for outbound calls does not authenticate inbound callers.

Incoming client certificate authentication¶

For inbound mutual TLS, App Service terminates TLS at the front end and forwards the presented client certificate to your application in the X-ARR-ClientCert request header.

Portal view: Custom domains and TLS bindings¶

The Custom domains blade is where the inbound TLS surface becomes concrete for client-certificate designs. The hostname rows and their SNI SSL binding type define which front-end endpoints can participate in the TLS handshake, while the Certificate used column ties each hostname to the server certificate that the front end will present. The contrast between the two App Service domain rows (both bound to an SNI SSL certificate) and the default *.azurewebsites.net row (whose Solution, Binding type, and Certificate used columns are all -) shows that mTLS configuration applies on top of explicitly bound custom hostnames — clientCertEnabled and clientCertMode decide whether App Service then asks the client to present a certificate and forward X-ARR-ClientCert to your app.

Key platform behavior:

• clientCertEnabled turns the feature on.
• clientCertMode controls whether certificates are required or optional.
• clientCertExclusionPaths bypasses certificate enforcement for selected paths.
• The forwarded header value is base64-encoded certificate content without PEM markers.
• Your application must validate issuer, subject, thumbprint, validity window, and chain policy as needed.

Site properties for inbound mTLS¶

Supported clientCertMode values documented by Microsoft Learn:

• Required
• Optional
• OptionalInteractiveUser

Design guidance:

1. Use Required for API endpoints where every caller must present a client certificate.
2. Use Optional only when the application enforces certificate presence for selected routes or callers.
3. Use clientCertExclusionPaths sparingly for liveness probes, platform callbacks, or third-party webhook endpoints that cannot present a certificate.

Outbound mTLS from the app to remote services¶

Outbound mTLS means your App Service app acts as the TLS client and presents its own certificate to a downstream dependency such as a partner API, API gateway, or internal service.

The platform pattern is different from inbound mTLS:

1. Upload a private certificate to the App Service app.
2. Make it available to application code with WEBSITE_LOAD_CERTIFICATES.
3. Load the certificate from the platform-exposed store or filesystem location.
4. Attach it to your HTTP client or TLS context.

ASE and end-to-end private ingress considerations¶

App Service Environment changes where the App Service front ends and workers live on your network, but your application should still treat inbound client certificates as platform-forwarded artifacts unless your ingress chain adds another gateway or proxy behavior.

Conservative ASE design assumptions:

• Use ASE to control where ingress is exposed and how private routing works.
• Assume the standard X-ARR-ClientCert application contract only when no upstream gateway or proxy changes that behavior.
• Document ILB ASE as an ingress-topology choice, not as proof of a different in-app certificate format.

Comparison summary¶

See Also¶

• Security Architecture
• Networking
• Incoming Client Certificates
• Outbound Client Certificates
• mTLS Best Practices

Sources¶

• Set up TLS mutual authentication for Azure App Service (Microsoft Learn)
• Use TLS/SSL certificates in your application code in Azure App Service (Microsoft Learn)
• App Service Environment overview (Microsoft Learn)