Can I authenticate clients with client certificates (mTLS)?

Short answer

Yes. The CA that signs the client certificates is added to the Certificates & PKI → Certificate Authorities (CA) screen; in a TLS Security Profile, Client Certificate Authentication (mTLS) is turned on, and the Client Certificate Verification Type (Required or Optional) and CA Certificate Files are selected; the profile is selected in the SSL Security module in the Details panel of the vService. It works on HTTP and L7 TCP vServices. Client certificates can also be produced with TR7's internal CA on the Client Certificates screen. TR7 presenting its own certificate to the Backend Service, on the other hand, is a separate setting (Client Certificate Presented to Backend (mTLS)).

Background

mTLS (mutual TLS) is the client, as well as the server, proving its identity with a certificate in the TLS handshake. The server requests a certificate from the client; if the certificate the client presents does not chain to one of the CAs the server trusts, has expired or has an invalid signature, the connection is rejected at the handshake stage. It is applied before password-based authentication, before the application is even reached.

Problem: Only Recognized Devices and Users Should Be Able to Connect

It may be desired to open management interfaces, partner APIs or corporate applications only to the clients to which the organization has issued certificates. The connection needs to be validated with a client certificate already in the TLS handshake.

Solution: Three Methods

Methods 1 and 2 use the same mTLS profile; the difference is where the CA that signs the client certificates comes from. Method 3 is the command line equivalent of Method 1.

Your situation	Suitable method
The client certificates come from a corporate or commercial CA	Method 1: CA record + TLS Security Profile
TR7 should produce the client certificates too	Method 2: Client certificate with the TR7 internal CA
From the command line	Method 3: WEB-CLI

Method 1: CA Record + TLS Security Profile Recommended

• How it works TR7 validates the certificate the client presents against the CA records selected in the profile. If Required is selected, a client that has no certificate or cannot be validated is rejected in the handshake; if Optional is selected, a client without a certificate also connects, and if a certificate is presented, it is validated.
• Where it is openedCertificates & PKI → Certificate Authorities (CA) · TLS Security Profiles → Client Certificate Verification (mTLS) — Frontend
• Requirement The certificate of the CA that signs the client certificates; an encrypted frontend on the vService
• vService type HTTP, L7 TCP

Step-by-Step Configuration

1

Adım 1 Open the CA add form

The Configuration Menu is opened with the TR7 logo at the bottom left; on the Certificates & PKI → Certificate Authorities (CA) screen, Add is clicked (how to add).

2

Adım 2 Define the CA

The CA Name is entered; in the Operation field, the default Add a trusted CA certificate is left as is, and the certificate of the CA that signs the client certificates is pasted into the CA Certificate (PEM) field. If there is an intermediate CA, it can also be added as a separate record.

3

Adım 3 Save the CA record

Add is clicked.

4

Adım 4 Open the profile form

On the Certificates & PKI → TLS Security Profiles screen, Add is clicked (how to add), or the profile used on the vService is selected and Edit is clicked; in a new profile, the Security Profile Name is entered.

5

Adım 5 Turn on mTLS

In the Client Certificate Verification (mTLS) — Frontend section, the Client Certificate Authentication (mTLS) switch is turned on (off by default). Client Certificate Verification Type is Required by default; if clients without a certificate are also to be allowed, Optional is selected. In the CA Certificate Files field, the CA record from step 3 is selected (at least one record is required). CA Verification Error Strategy is left at the default Deny All Errors.

6

Adım 6 Save the profile

Add (or Edit) at the bottom of the form is clicked. When the CA list is changed, the vServices that use the profile are restarted.

7

Adım 7 Open the vService edit form

On the Load Balancer → Load Balancer vService List screen, the vService is selected and Edit is clicked.

8

Adım 8 Select the profile

While an encrypted protocol (Encrypted (HTTPS) on an HTTP vService, TCP + TLS on L7 TCP) and a Certificate are selected on at least one frontend row, the SSL Security box under Frontend Settings in the Details panel is checked and the profile is selected (profile selection in the vService).

9

Adım 9 Save

Save is clicked. In a cluster setup, with the default auto-sync, the change is also sent to the peer device; if Manual Sync Mode is on, it is sent to the peer device manually.

Verification

1Connection without a certificateClient side

A connection is made without presenting a certificate.

Command: curl -sk https://www.example.com/

ExpectedRequired: handshake error · Optional: a response is received

2Connection with a certificateClient side

A connection is made with a client certificate signed by the CA and its key.

Command: curl -sk --cert client.crt --key client.key https://www.example.com/

ExpectedThe application's response (e.g. 200)

Method 2: Client Certificate with the TR7 Internal CA

• How it works A root CA and an intermediate (issuing) CA with client usage are created on TR7; the client certificates are produced with this CA on the Client Certificates screen, and the same CA is selected in the CA Certificate Files field of the mTLS profile. The Client Authentication usage is added automatically to the produced certificates.
• Where it is openedCertificates & PKI → Certificate Authorities (CA) · Certificate Profiles · Client Certificates
• Requirement None
• vService type HTTP, L7 TCP

Step-by-Step Configuration

1

Adım 1 Open the root CA form

On the Certificates & PKI → Certificate Authorities (CA) screen, Add is clicked.

2

Adım 2 Define the root CA

The CA Name is entered; Operation = Create Root CA is selected and the Common Name (CN) is entered (Key Algorithm default RSA 4096, Lifetime (days) default 3650).

3

Adım 3 Save the root CA

Add is clicked.

4

Adım 4 Open the issuing CA form

Add is clicked again on the same screen.

5

Adım 5 Define the issuing CA

The CA Name is entered; Operation = Create Issuing CA, Usage = Client Certificates (default Server Certificates) and Parent CA = the root CA from step 3 are selected, and the Common Name (CN) is entered.

6

Adım 6 Save the issuing CA

Add is clicked.

7

Adım 7 Open the certificate profile form (if needed)

If there is no certificate profile with Client / mTLS usage, Add is clicked on the Certificates & PKI → Certificate Profiles screen (how to add).

8

Adım 8 Define the profile (if needed)

The Profile Name is entered; Usage = Client / mTLS is selected (default TLS Server; profiles with this usage are not listed on the Client Certificates screen). Lifetime (days) (default 365) and Key Algorithm (default RSA 2048) are set.

9

Adım 9 Save the profile (if needed)

Add is clicked.

10

Adım 10 Open the client certificate form

On the Certificates & PKI → Client Certificates screen, Add is clicked.

11

Adım 11 Define the certificate

The Certificate Name is entered; How to Add = Issue from an internal CA (default) is left as is. In the Issuing CA field, the CA from step 6 is selected, and in the Certificate Profile field, the Client / mTLS profile is selected; the Person or Device (CN) and, if needed, E-mail Addresses and Windows Logon Names (UPN) are entered. If the certificate is to be distributed to the client, Allow Download is turned on.

12

Adım 12 Save the certificate

Add is clicked; the certificate is produced. If Allow Download is on, the certificate is downloaded together with its key as a PFX and installed on the client. Steps 10–12 are repeated for each client.

13

Adım 13 Set up the mTLS profile

Steps 4–9 of Method 1 are applied; in the CA Certificate Files field, the issuing CA from step 6 is selected.

Verification

1Connection with a certificateClient side

A connection is made with the downloaded PFX.

Command: curl -sk --cert-type P12 --cert istemci.pfx:parola https://www.example.com/

ExpectedThe connection is accepted; a request without a certificate is rejected

Method 3: WEB-CLI

• How it works The CA record, the mTLS profile and the vService assignment are done from the command line. Because WEB-CLI runs each line as a separate command, the CA certificate is given as single-line Base64 (DER) instead of multi-line PEM; TR7 converts it to PEM during saving.
• Where it is opened TR7 WEB-CLI → lb ca add · lb ssl-security add · lb service update
• Requirement WEB-CLI access; the single-line Base64 form of the CA certificate
• vService type HTTP, L7 TCP

Step-by-Step Configuration

1

Adım 1 Convert the CA certificate to a single line

On the administrator's computer, the PEM file is converted to Base64 that contains no line breaks:

openssl x509 -in istemci-ca.pem -outform DER | base64 -w0

2

Adım 2 Add the CA record

In place of <base64>, the output of step 1 is pasted (lb ca add):

lb ca add name istemci-ca --content <base64>

3

Adım 3 Create the mTLS profile

The version and cipher are also written explicitly; --caFiles.0 takes the CA name from step 2:

lb ssl-security add name mtls --minSslVersion TLSv1.2 --cipherAlgorithm general --clientCertAuth true --clientCertVerifyType required --caFiles.0 istemci-ca --caErrorStrategy denyAll

4

Adım 4 Assign the profile to the vService

--sslSecurity replaces the vService's profile with this profile:

lb service update id <vService> --sslSecurity mtls

Verification

1Record and connectionTR7 side · Client side

The profile is displayed; then the connections without and with a certificate in Method 1 are tried.

Command: lb ssl-security show mtls

ExpectedclientCertAuth true · caFiles.0 istemci-ca

Common Mistakes

• Confusing it with the Client Certificate Presented to Backend (mTLS) field. This field on the Backend Service is the certificate TR7 presents when identifying itself to the server; the setting that validates clients is the mTLS section in the TLS Security Profile.
• Thinking that expired client certificates will be accepted with Ignore All Errors. CA Verification Error Strategy ignores only the validation errors of the CA certificates in the chain; the errors of the client certificate itself (such as expiry) still cause the connection to be rejected. Ignore All Errors is used only for testing purposes.
• Expecting a revocation (CRL) check. The profile has no revocation list field; to remove a client's access, the related CA record is removed from the profile, or the client is blocked with a condition and the Block action.
• Saving the profile without selecting a CA. The form is not saved unless at least one record is selected in the CA Certificate Files field.
• Not selecting the profile on the vService. The mTLS profile is not applied unless the SSL Security box is checked and the profile is selected on the vService.

How it is done in the documentation

• TLS Security Profiles · Client Certificate Verification (mTLS) — Frontend
• Certificate Authorities (CA) · Add a trusted CA certificate
• Client Certificates · What Is a Client Certificate?
• WEB-CLI · lb ca add — The Trust Anchor

Related questions

• How do I add my own internal CA to TR7?
• What is a TLS Security Profile, and what does it configure?
• Can I use TR7 as an internal CA to issue, automatically renew and revoke certificates?