Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform
Can I use a wildcard certificate?
Short answer
Yes. A wildcard certificate (*.example.com) can be uploaded in the Manual or PFX type, obtained automatically in the ACME.SH type with the DNS-01 challenge, or signed by a CA by being written to the Subject Alternative Names list in the CSR (External CA) tab; it is selected in the Certificate field of the vService like other certificates. A wildcard certificate covers only a single subdomain level: portal.example.com is covered, while a.b.example.com and example.com itself are not covered.
Ways to Obtain a Wildcard Certificate
| Way | How in TR7 | Note |
|---|---|---|
| Wildcard obtained from a commercial or corporate CA | Certificates & PKI → SSL/TLS Certificates → Add → Type = Manual or PFX (How do I upload my certificate to TR7; which formats are supported?) | The most common way |
| Automatically with ACME (Let's Encrypt, etc.) | Type = ACME.SH, Challenge Type = DNS-01, an ACME DNS Providers profile in the DNS Provider field (Can I get certificates automatically with Let's Encrypt / ACME?) | A wildcard cannot be obtained with HTTP-01; the form gives the Wildcard domains require the DNS-01 challenge error |
| By generating the key on TR7 and having it signed by a CA | In the CSR (External CA) tab, the wildcard name is written to the Subject Alternative Names list (Can I create a CSR on TR7?) | The Common Name (CN) field does not accept the * character |
Scope Rules
| Name | Does *.example.com cover it? |
|---|---|
portal.example.com | Yes |
api.example.com | Yes |
a.b.example.com | No (two sublevels) |
example.com | No (the domain name itself) |
For the domain name itself to be covered as well, example.com is additionally added to the certificate: in ACME, two rows (example.com and *.example.com) are written to the Domain list; in the CSR, both names are added to the Subject Alternative Names list. If a request comes for a name the certificate does not cover, the browser gives a name mismatch warning.
In TR7
- The wildcard certificate is selected in the Certificate field of the vService; certificates with full names can also be added to the same vService. The certificate that carries exactly the name the client requests (SNI) is selected before the wildcard certificate (Can I attach more than one certificate to a vService; how is the right certificate selected (SNI)?).
- To obtain a wildcard with ACME, a DNS provider profile is first created on the Certificates & PKI → ACME DNS Providers screen (how to add); the profile can also be defined without leaving the form, with the adding icon next to the DNS Provider field in the ACME add form.
- The validity of the wildcard certificate is followed from a single record; since all the vServices in which the certificate is used are bound to the same record, the renewal is done from a single point (When I renew a certificate, do I need to replace it on each vService one by one?).
Common Misconceptions
- "A wildcard covers all sublevels." It covers only one level; for
a.b.example.com,*.b.example.comis required. - "The
*.example.comdefinition in Virtual hosting is the same thing as the certificate." The wildcard definition in the Virtual Hosting list is for mapping traffic to the vService and matches more than one sublevel; the scope of the certificate, on the other hand, is a single level. - "Let's Encrypt issues a wildcard with HTTP-01." A wildcard is obtained only with DNS-01 (What is the difference between HTTP-01 and DNS-01 in ACME; why is DNS-01 required for wildcards?).
- "In a CSR, the wildcard is written to the CN field." In the CSR form of TR7, the Common Name (CN) field does not accept
*; the wildcard name is written to the Subject Alternative Names list. Current browsers already read the name of the certificate from the SAN list.
How it is done in the documentation
