Support for mTLS for Secure

Mutual Transport Layer Security (mTLS), also known as Mutual Authentication, is an authentication method that validates the digital certificate on both sides of a request: on the client side and on the Edge.

With mTLS activated, Azion checks the user’s browser certificate and validates it with the Trusted Certificate (Trusted CA), of your Application.

mTLS is optional for applications using TLS protocols. However, it does promise a more secure TLS handshake and is an Open Banking requirement.

Prerequisites

It’s necessary that your Application is operating with the Hypertext Transfer Protocol Secure (HTTPS) protocol. Azion Console allows you to configure mTLS in applications running with HTTP only (without the TLS encryption layer). However, mTLS requires an HTTPS connection to work.

Protocol options are available on your Application configuration page in Azion Console.

Digital Certificate with support for mTLS (Trusted CA)

To configure mTLS in your Application, you need a Digital Certificate that supports mTLS, generated by a Third-Party Certificate Authority. At Azion, we call this certificate Trusted CA.

Select or add a new Domain and make sure the mTLS option is enabled. Then select the previously added Trusted CA.

Free certificates, generated internally by Azion (Azion [SAN]), don’t support mTLS.

To use mTLS Enforce mode, you must use Server Name Indication (SNI) extension to the traditional TLS protocol.

Connections without SNI are connected to the default configuration, which, at the time of the TLS handshake, delivers the Azion SAN certificate.

When we have requests without SNI for a Domain with mTLS in Enforce mode, the connection will be interrupted before the route of your Application is resolved.

Make sure your Applications always use SNI on requests.

How mTLS works at Azion

The default configuration of mTLS blocks accesses whose user identity can’t be verified.

If your application needs special access, it is necessary to configure a permissive check (Permissive mTLS). Permissive checking can be configured on the Domains page.

In Permissive mode, you can use the Client Certificate Validation variable in the Rules Engine for Firewall to restrict access based on client certificate identity. This variable evaluates whether the client certificate presented in the request is valid against the configured Trusted CA. A common pattern is to deny requests where Client Certificate Validation is not equal to true, returning a 403 Forbidden response.

You can also change and specify the header variables of your mTLS to meet Open Banking requirements. This can be done in the Application configuration page, within Azion Console.

The list of accepted variables is available on the Rules Engine for Application page.

Client Certificate Validation in Firewall

After enabling mTLS at the domain level, you can use Firewall to enforce granular access control based on client certificate attributes. This allows you to restrict access to specific resources based on certificate fields such as the Common Name (CN), issuer, or fingerprint forwarded via mTLS header variables.

To configure client certificate validation in Firewall:

1. Access Azion Console and open your Firewall configuration.
2. In the Rules Engine tab, create a new rule.
3. In the Criteria section, use the mTLS header variables (such as ${ssl_client_s_dn} or ${ssl_client_fingerprint}) as match conditions.
4. In the Behavior section, set the action to Deny (403 Forbidden) or Drop (Close Without Response) for requests that don’t match the expected certificate attributes.

Limits

Certificates

These are the default limits for each Support service: