FAQ
Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform

English

Türkçe

English

Türkçe

Appearance

Intermediate

Can certificate verification be done in an HTTPS health check? ​

Short answer

Yes. Verify Server Certificate is turned on in the HTTPS profile; it is off by default, and while it is off, self-signed or expired certificates are also accepted. Verification is done against TR7's trusted root certificates; for certificates signed by an internal CA, a CA record is selected in the Verification CA Profile field; if it is left empty, the CA profile of the Backend Service is used if SSL Service is on and Certificate Verification is Required on the Backend Service. The name match is checked only if Virtual Domain (Host/SNI) is filled; if the server requests a client certificate, a certificate is selected in the Client Certificate to Present (mTLS) field.

Problem: The Health Check Does Not Notice an Invalid Certificate ​

While verification is off, the health check does not look at the server's certificate; even if the certificate expires or a wrong certificate is installed, the server appears healthy. If the data traffic verifies the certificate (Certificate verification Required on the Backend Service), the server can stay in traffic while clients get errors.

Solution: 2 Methods ​

The two methods make the same setting from different interfaces.

Your situationSuitable method
I configure the profile from the interfaceMethod 1: Verification in the HTTPS profile
I create or update the profile from WEB-CLIMethod 2: WEB-CLI
  • How it works The health check verifies the server's certificate chain against TR7's trusted root certificates and the selected CA record; if Virtual Domain (Host/SNI) is filled, it also compares the name in the certificate. If verification fails, the check fails with "Certificate error".
  • Where it is opened HTTPS profile → Verify Server Certificate / Verification CA Profile / Client Certificate to Present (mTLS)
  • Requirement If an internal CA is used, the CA must be registered on the Certificate Authorities (CA) screen; if mTLS is required, a client certificate on the Client Certificates screen
  • vService type All
  • Other TLS types The same fields are also present in the TCPS, FTPS, LDAPS, SMTPS and SMTP with Use STARTTLS on types

Step-by-Step Configuration ​

1
Adım 1 Open the CA record form (if an internal CA is used)

If the server certificate is signed by the organization's internal CA and the CA is not registered in TR7, the Configuration Menu is opened with the TR7 logo at the bottom left; the Certificates & PKI → Certificate Authorities (CA) path is followed and Add is clicked.

2
Adım 2 Enter the CA certificate

A unique name is written in the CA Name field; Add a trusted CA certificate (default) is left in the Operation field, and the CA certificate is pasted into the CA Certificate (PEM) field.

3
Adım 3 Save the CA record

The Add button is clicked; the record appears in the Verification CA Profile list in the health check form.

4
Adım 4 Open the client certificate form (if mTLS is required)

If the server requests a client certificate and there is no suitable client certificate in TR7, the Certificates & PKI → Client Certificates path is followed and Add is clicked.

5
Adım 5 Enter the client certificate

A unique name is written in the Certificate Name field. For a certificate issued by the organization, Import an existing certificate is selected in the How to Add field, and the certificate and private key are pasted as PEM; if it will be generated with TR7's internal CA, Issue from an internal CA is selected.

6
Adım 6 Save the client certificate

The Add button is clicked; the record appears in the Client Certificate to Present (mTLS) list in the health check form.

7
Adım 7 Open the Health Checks profile form

The Load Balancer → Profiles → Health Checks path is followed; for a new profile Add is clicked, and for an existing HTTPS profile the profile is selected and Edit is clicked. In a new profile, Name is entered and HTTPS is selected in the Check Type field; the TLS fields are located at the top of the form.

8
Adım 8 Turn on verification

Verify Server Certificate is turned on; the Verification CA Profile field appears. If an internal CA is used, the CA saved in step 3 is selected; if None is left, the CA profile of the Backend Service is used and From the backend is written in the profile preview.

9
Adım 9 Set the name and the client certificate

If the name in the certificate is also to be checked, the name for which the certificate was issued is written in the Virtual Domain (Host/SNI) field (e.g. portal.example.com); this name is also sent as the Host header in the request and as SNI in the TLS connection. If the server requests a client certificate, the certificate from step 6 is selected in the Client Certificate to Present (mTLS) field; if None is left, the certificate in the Client Certificate Presented to Backend (mTLS) field of the Backend Service is used.

10
Adım 10 Save the profile

The Add (Edit when editing) button is clicked. If the profile is already assigned, the change is applied to all the Backend Services that use the profile.

11
Adım 11 Open the Backend Service form

For a new profile, the Load Balancer → Backend Services path is followed; the Backend Service is right-clicked and Edit is selected.

12
Adım 12 Select the profile

The profile is selected in the Health Check field.

13
Adım 13 Save

The Edit button at the bottom of the form is clicked. In a cluster, the change is transferred to the peer device automatically by default; if Manual Sync Mode is on, it is sent with Synchronize.

Verification ​

1Health statusBackend Services list

The indicator in the Health column of the Backend Services list is checked (Health status indicator).

ExpectedOK (green)
2Verification errorHealth Check card

If the certificate cannot be verified, the error text appears in the error strip of the Health Check card in the Backend Service preview and in the Health Checks tab.

ExpectedCertificate error: …

Method 2: WEB-CLI ​

  • How it works The TLS fields are written with --verifyCertificate, --tlsVerifyCa, --virtualDomain and --tlsClientCert; --tlsVerifyCa is used only while --verifyCertificate true.
  • Where it is opened WEB-CLI → lb hc add / lb hc update (lb hc · The TLS Fields)
  • Requirement WEB-CLI access; the ID of the CA record (lb ca list)
  • vService type All

Step-by-Step Configuration ​

1
Adım 1 Create the profile

checkType and name are required and are written in this order; the ID of the CA record is taken from the lb ca list output:

text
lb hc add checkType https name tls-denetimi --uri /health --virtualDomain portal.example.com --verifyCertificate true --tlsVerifyCa <ca-id>
2
Adım 2 Assign the profile to the Backend Service

The profile ID is taken from the lb hc list output, and the Backend Service ID from the lb backend list output:

text
lb backend update id <backend-id> --hc <profile-id>

Verification ​

1RecordWEB-CLI

The profile record is displayed.

Commandlb hc show <profile-id>
ExpectedverifyCertificate true, tlsVerifyCa and virtualDomain filled

Common Mistakes ​

  • Assuming that the verification on the Backend Service is also applied to the health check. The verification of the health check depends on Verify Server Certificate in the profile; only the CA profile, the client certificate and the lowest TLS version and the cipher list of the Backend SSL Security Profile are inherited from the Backend Service.
  • Turning on verification without registering the internal CA. A certificate signed by the organization's own CA cannot be verified, and the server becomes Error.
  • Expecting a name check while Virtual domain (Host/SNI) is empty. If the field is empty, only the certificate chain is checked; the name in the certificate is not compared.
  • Selecting a CA while Verify server certificate is off. Verification CA Profile is applied only while verification is on.

How it is done in the documentation

Related questions