I have a domain for a public-facing static website that loads fine whether it’s entered into the browser as example.com, http://example.com, or https://example.com.
I have a private (accessible by login) subdomain for a Discourse forum that loads fine whether it’s entered into the browser as discourse.example.com, http://discourse.example.com, or https://discourse.example.com.
The subdomain for Discourse is achieved by addition of a record to the AWS Route 53 hosted zone:
I’d like to provide a shorter alternative/secondary subdomain for Discourse. So I added another record, nearly same as the prior, only with the record name changed from discourse.example.com to d.example.com.
Strangely, this works in HTTP, but in HTTPS the browser warns:
Your connection is not private
Attackers might be trying to steal your information from d.example.com (for example, passwords, messages, or credit cards).
Learn more
NET::ERR_CERT_COMMON_NAME_INVALID
What am I missing? Should I be going about this a different way?
My AWS Certificate covers example.com and *.example.com. My CloudFront distribution covers example.com and d.example.com. I have disabled my Amazon CloudFront cache during this configuration temporarily to ensure that’s not a factor.
The issue you’re seeing — NET::ERR_CERT_COMMON_NAME_INVALID — is caused by the fact that the SSL/TLS certificate served at d.example.comdoes not include d.example.com in its SAN (Subject Alternative Names) list, even though you believe your certificate covers *.example.com.
Let’s walk through this clearly:
What You Did Right
You created d.example.com and pointed it correctly in Route 53.
You ensured d.example.com routes to the same IP (and therefore the same app) as discourse.example.com.
You confirmed that HTTP works — meaning DNS and routing are OK.
Why HTTPS Fails
The TLS/SSL certificate served at d.example.comdoes not cover that domain — despite your certificate covering *.example.com.
This is the key nuance:
*.example.comdoes not cover d.example.com if the certificate only lists discourse.example.com and/or *.example.combut the web server doesn’t actually serve the certificate to d.example.com.
Common Mistakes
Discourse instance is only configured for discourse.example.com
Even though the cert includes *.example.com, the app server (like NGINX, or Discourse’s internal config) only serves HTTPS properly on discourse.example.com, and not d.example.com.
CloudFront or NGINX is only configured with the cert for one domain
If you’re terminating TLS at a load balancer or CDN (like CloudFront), it might be presenting the wrong certificate or expecting Host: discourse.example.com specifically.
The cert in use doesn’t include d.example.com at all
Despite being a wildcard cert, some providers or configurations expect explicit domain mentions or don’t allow wildcards to cover single-letter subdomains (rare, but check this).
Then look at the Certificate chain and Subject Alternative Name. If d.example.com is not listed or not matched by the wildcard, this is the problem.
Option 2: Update Your TLS Termination to Serve Correct Cert
If using:
Nginx or Apache: Ensure server_name includes d.example.com, and that your cert is served correctly on port 443 for that name.
CloudFront: Make sure the distribution covering d.example.com uses the correct ACM certificate (one that includes d.example.com).
ALB / Load Balancer: Make sure HTTPS listeners include d.example.com as an SNI host.
Option 3: Reissue the Certificate
If your cert doesn’t explicitly include d.example.com, reissue it to cover:
example.com
*.example.com
Optionally: explicitly add d.example.com
Even though wildcard certs should cover any *.example.com, some implementations don’t fully support them unless explicitly handled.
Best Practice
If you’re serving multiple subdomains over HTTPS — even short aliases — make sure your TLS certificate explicitly supports all names you use (either via wildcard or SANs), and that your infrastructure is configured to respond with the correct cert based on the hostname.