You need HTTPS on a subdomain (blog.example.com, api.example.com, staging.example.com). Three options:
Option 1: Wildcard certificate (*.example.com)
One certificate covers all subdomains automatically — including ones you create in the future.
| Pros | Cons |
|---|---|
| Covers unlimited subdomains | Requires DNS-01 challenge (needs DNS access) |
| New subdomains work instantly | One private key for all subdomains (shared risk) |
| Only 1 cert to manage | Doesn’t cover nested subdomains (a.b.example.com) |
| Free from Let’s Encrypt | Doesn’t cover the bare domain (add example.com separately) |
Best for: Many subdomains, frequently adding new ones.
*.example.com covers:
✅ www.example.com
✅ blog.example.com
✅ api.example.com
✅ staging.example.com
✅ anything.example.com
❌ example.com (add separately)
❌ sub.blog.example.com (nested)How to get a wildcard certificate →
Option 2: SAN certificate (list specific subdomains)
Explicitly list each subdomain in the certificate’s Subject Alternative Name field.
| Pros | Cons |
|---|---|
| Can use HTTP-01 challenge (simpler) | Must list each subdomain explicitly |
| Can mix different base domains | Adding a subdomain requires a new certificate |
| Each name individually validated | Let’s Encrypt limit: 100 names per cert |
| Free from Let’s Encrypt | More management if subdomains change often |
Best for: Small, fixed set of subdomains (2-5).
SAN certificate covers exactly what you list:
✅ example.com
✅ www.example.com
✅ blog.example.com
❌ api.example.com (if not listed)In GetHTTPS, just enter all the subdomains you need.
Option 3: Separate certificate per subdomain
Each subdomain gets its own certificate.
| Pros | Cons |
|---|---|
| Maximum isolation (separate keys) | Most management overhead |
| Independent renewal schedules | One cert per subdomain to track |
| Compromise of one doesn’t affect others | More server configuration |
| Works with HTTP-01 per subdomain |
Best for: Subdomains managed by different teams, or when security isolation matters.
Comparison table
| Wildcard | SAN | Separate | |
|---|---|---|---|
| Subdomains covered | All (unlimited) | Listed ones only | One per cert |
| New subdomains | Automatic | Re-issue needed | New cert needed |
| Challenge type | DNS-01 only | HTTP-01 or DNS-01 | HTTP-01 or DNS-01 |
| Certificates to manage | 1 | 1 | N |
| Security isolation | Shared key | Shared key | Isolated keys |
| Cost (Let’s Encrypt) | Free | Free | Free |
| Best for | Dynamic subdomains | Fixed set (2-5) | Team isolation |
Common scenarios
”I have example.com and www.example.com”
→ SAN certificate (simplest). In GetHTTPS, enter both names. This is the most common setup.
”I run www, blog, api, docs, staging subdomains”
→ Wildcard (*.example.com + example.com). Covers all current and future subdomains.
”Each subdomain is a different client’s site”
→ Separate certificates. Each client manages their own. Compromise of one doesn’t affect others.
”I have example.com + example.org + subdomains”
→ SAN certificate combining domains + wildcard: example.com, *.example.com, example.org. GetHTTPS supports this.
Frequently asked questions
Does *.example.com cover example.com itself?
No. The bare domain needs to be listed separately. In GetHTTPS, add both *.example.com and example.com. Details →
Can I mix wildcard and specific domains in one certificate?
Yes. A single Let’s Encrypt certificate can include *.example.com, example.com, and other.com as SAN entries. Up to 100 names per certificate.
Which option is cheapest?
All three are free with Let’s Encrypt via GetHTTPS. Some commercial CAs charge extra for wildcards ($200-500/year) and per-SAN ($10-50 each). With Let’s Encrypt, cost is never a factor.
My subdomain is on a different server. Can I use the same certificate?
Yes. Install the same fullchain.pem and privkey.pem on both servers. The certificate doesn’t know which server it’s on — it only validates the domain name.