Can I attach more than one certificate to a vService; how is the right certificate selected (SNI)?

Short answer

Yes. More than one certificate can be selected in the Certificate field of HTTP and L7 TCP vServices. During the TLS handshake, the client sends the name it wants to connect to (SNI); TR7 matches this name against the CN and SAN values of the certificates and presents the matching certificate, and an exact name match takes precedence over a wildcard match. If no SNI is sent or it matches no certificate, the first certificate in the list is presented; for this reason, the certificate to be presented to clients that do not send SNI is placed first. On vServices that share the IP and port with Virtual Hosting, however, a connection without SNI or one that matches the domain name of no vService is closed.

Background

SNI (Server Name Indication) is the TLS extension with which the client states the domain name it wants to connect to in the first, unencrypted packet of the TLS handshake (ClientHello). When a server serves more than one domain name on the same IP and port, it decides which certificate to present based on this information. All current browsers and libraries send SNI; very old clients and some embedded systems may not send it.

How Does It Work?

1. At the start of the connection, the client sends the domain name as SNI (e.g. portal.example.com).
2. TR7 searches the certificates in the Certificate field of the vService for a CN or SAN value that exactly matches this name; if there is none, it looks for a wildcard match (*.example.com).
3. The matching certificate is presented. If there is no match or the client did not send SNI, the first certificate in the list is presented. If Virtual Hosting is used, the vService is first selected based on SNI; if there is no SNI or it matches the domain name of no vService, the connection is closed before reaching this step (Relationship with Virtual Hosting).

Certificate selection is shared by all the encrypted frontend rows of the vService; there is no separate certificate list per row.

Binding the Certificates

1

Adım 1 Add the certificates (if needed)

If the certificates to be bound are not on the Certificates & PKI → SSL/TLS Certificates screen, they are added first (How do I upload my certificate to TR7; which formats are supported?).

2

Adım 2 Open the vService edit form

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

3

Adım 3 Check the encrypted frontend

In at least one of the frontend rows, an option from the Encrypted (HTTPS) group must be selected in Protocol on an HTTP vService, or Protocol = TCP + TLS on an L7 TCP vService; only then does the Certificate field appear.

4

Adım 4 Select the certificates

The certificates are selected in order in the Certificate field; the Type, Expiry Health and Used in filters in the selector filter the list. The certificate to be presented to clients that do not send SNI is selected first.

5

Adım 5 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.

In WEB-CLI, the existing certificate.N lines are first viewed with lb service show <vService>; the new certificate is written to the first empty position, because a certificate written to a filled position replaces the certificate there (Binding to a vService). If the vService has one certificate, the second one is added as follows:

lb service update id <vService> --certificate.1 <certificate>

Relationship with Virtual Hosting

On more than one HTTP vService that shares the same IP and port (Virtual Hosting), the connection is first forwarded to the relevant vService based on SNI, and then that vService presents its own certificate; if SNI matches the list of no vService or is not sent at all, the connection is closed. More than one certificate on a single vService, on the other hand, is for the same vService to serve with different domain names (Can I define more than one vService on the same IP:port?).

Verification

Each domain name is queried separately; a query without -servername imitates a client without SNI:

openssl s_client -connect 203.0.113.10:443 -servername portal.example.com
openssl s_client -connect 203.0.113.10:443 -servername api.example.com
openssl s_client -connect 203.0.113.10:443 -noservername

Expected: in the first two commands, the subject value of the certificate that matches the name; in the third, the first certificate in the list. If the vService uses Virtual Hosting, the connection is closed in the third command.

Common Misconceptions

• "The order of the certificates does not matter." Clients whose SNI matches no certificate and, if Virtual Hosting is not used, clients that do not send SNI receive the first certificate in the list.
• "A wildcard certificate overshadows a certificate with an exact name." An exact name match comes first; portal.example.com and *.example.com can be in the same list together.
• "On L7 TCP, a certificate is also presented without terminating TLS." On a frontend with Protocol = TCP (passthrough), TR7 does not present a certificate; SNI is read only for routing (With passthrough, can I route to different backends based on SNI?).

How it is done in the documentation

• HTTP (L7) vService · Certificate
• L7 TCP vService · Certificate

Related questions

• Can I use a wildcard certificate?
• The browser says "certificate not trusted"; what are the possible causes?
• Can I define more than one vService on the same IP:port?