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

English

Türkçe

English

Türkçe

Appearance

Intermediate

Can I do Virtual Hosting with a wildcard domain (*.example.com)? ​

Short answer

Yes. *.example.com is written to the Virtual Hosting list of the vService. This pattern matches a subdomain such as shop.example.com and multi-level subdomains such as a.b.example.com; it does not match example.com itself, which is added as a separate row. On HTTPS, a wildcard certificate is required for *.example.com. If two vServices match the same domain, TR7 does not give priority to the exact match; the vService created first receives the request. If the wildcard certificate also covers the domains of other vServices, SNI/Host Validation is turned on in the TLS Security Profile.

Problem: How to Avoid Writing Many Subdomains One by One? ​

In applications that use a subdomain per customer (musteri1.example.com, musteri2.example.com…), adding a domain to the vService list for every new customer is not sustainable. All subdomains are expected to reach the same vService with a single pattern. Which names the wildcard matches and how it interacts with the domains in other vServices must be known.

Solution ​

Wildcard Pattern in the Virtual Hosting List ​

  • How it works A pattern in the list that starts with *. matches every name under that domain (one or more levels).
  • Where it is opened vService → Virtual Hosting → domain row
  • Requirement A wildcard certificate for HTTPS; not letting the pattern overlap with the domains in other vServices
  • vService type HTTP

Step-by-Step Configuration ​

1
Adım 1 Open the vService

The Load Balancer → Load Balancer vService List steps are followed and the HTTP vService is opened.

2
Adım 2 Add the wildcard pattern

The Virtual Hosting switch is turned on and *.example.com is written to the list. The wildcard is accepted only in the leading *. form; entries with a * in the middle (e.g. a.*.example.com) are considered invalid.

3
Adım 3 Add the main domain separately

If example.com itself will also reach this vService, example.com is added to the list as a separate row.

4
Adım 4 Select the wildcard certificate

On HTTPS, the *.example.com certificate (and, if it does not cover example.com, a second certificate that covers it) is selected in the Certificate field. If the certificate is not on TR7, it is first uploaded with Certificates & PKI → SSL/TLS Certificates → Add.

5
Adım 5 Save

The Save button is clicked.

Verification ​

1Request with different subdomainsClient side
Commandcurl -v --resolve musteri1.example.com:443:203.0.113.10 https://musteri1.example.com/
ExpectedThe wildcard certificate and the response of the vService
The same command is tried with example.com; if a separate row was not added, the connection is closed.

Common Mistakes ​

  • Assuming that the exact match has priority. If one vService has *.example.com and another has api.example.com, the api.example.com request goes to the vService created first. To prevent the overlap, if api.example.com will be published in a separate vService, the other subdomains are written one by one instead of the wildcard, or Conditional Backend Services (Content Switching) is used inside the vService with the wildcard.
  • Assuming that the wildcard certificate covers every level. The *.example.com certificate covers only a single level (a.example.com); a.b.example.com matches in Virtual Hosting, but the browser gives a certificate warning.
  • Forgetting to add the main domain. The *.example.com pattern does not match example.com.
  • Switching to another site on the same connection with a wildcard certificate. If the wildcard certificate also covers the domain of another vService, the browser can reuse the HTTP/2 connection and send the request to the wrong vService; to prevent this, SNI/Host Validation is turned on in the TLS Security Profile.

How it is done in the documentation

Related questions