Imagine you're throwing the biggest party of the year.
You send out one fancy invitation… but it only has your main mansion's address written on it.
Your guests show up at the front gate, but half of them were actually invited to:
- the pool house
- the rooftop bar
- the secret garden lounge
- the after-party yacht docked 3 km away
Most of them would just stand confused at the main gate forever.
That, my friends, is exactly what happens on the internet when you have a TLS certificate without proper Subject Alternative Names.
The Name Game – How We Got Here
| Period | Main name field used | Multiple names? | Reality check |
|---|---|---|---|
| ~1995–2000 | Common Name (CN) | Almost never | One hostname per cert – painful |
| 2000–2010 | Common Name (CN) | Very rare multi-CN hacks | Browsers started complaining |
| 2010–2015 | CN + very early SAN support | SAN slowly becoming recommended | Many still abused CN field |
| 2015–2019 | SAN is strongly preferred | CN still technically parsed | Browsers become stricter every year |
| 2019–2023 | SAN is mandatory for new rules | CN completely ignored by major browsers | Chrome 58+ (2017) → full enforcement later |
| 2024–2026 | SAN-only mindset | CN field basically museum piece | Some CAs don't even let you put anything |
The Different Flavors of Names You Can (and Should) Put in SAN
text
Subject Alternative Name types that actually matter in 2025–2026
1. dNSName ← The king (99.8% of usage)
• www.example.com
• api.staging.example.com
• shop-frankfurt-3.example.cloud
2. iPAddress ← Surprisingly still useful
• 192.168.77.254
• 2607:f8b0:4004:808::200e (yes, IPv6 too!)
3. uniformResourceIdentifier ← Rare but powerful for certain OAuth/JWT scenarios
• uri:spiffe://cluster1/workload/web-frontend
4. registeredID ← Very niche (mostly government/specialized PKI)
• 1.3.6.1.4.1.311.21.7
5. otherName → The wild west (mostly Kerberos/SPNEGO, Apple stuff)
• 1.3.6.1.5.2.2;UTF8;ram@CORP.EXAMPLE.COMReal-World Examples – What People Actually Buy in 2026
Bash
# Style 1 – Classic business multi-domain (still very common)
*.company.com
company.com
www.company.com
portal.company.com
api.company.com
status.company.com
# Style 2 – Modern microservices / SaaS 2026 flavor
*.app.company.dev
*.staging.company.dev
app-1-eu-west-1.app.company.dev
feature-flags-us-central.app.company.dev
cdn.assets.company.com
# Style 3 – The paranoid security team special
www.example.com
example.com
example.org # defensive registration
example.net
xn--80aivjhhtk.xn--p1ai # IDN defense
185.199.108.153 # GitHub Pages IP
2606:50c0:8000::153Quick SAN Decision Flowchart (2026 edition)
text
Do you need more than 1 hostname?
↓ Yes
Do you control all the names?
↓ Yes
Are they all subdomains of one main domain?
↓ Yes ──→ Wildcard *.example.com + example.com (cheap & clean)
↓ No ──→ Multi-domain SAN certificate
↓
< 100 names? → Standard multi-domain cert
> 100 names? → Consider certificate manager + automationBrutally Honest Truths About SAN in 2026
- Most browsers have completely stopped looking at the Common Name field (Chrome since ~2017 gradually, almost all major clients in 2024–2025)
- Putting only CN and no SAN → certificate is invalid for almost every browser
- Too many SAN entries (>~100–150) → some clients start getting nervous (size of extension)
- Wildcards do not match multiple levels: *.example.com ✓ matches api.example.com*.example.com ✗ does NOT match eu.api.example.com
- The future is leaning towards very short-lived certificates + very specific names rather than huge SAN monsters