Why does secondary subdomain for Discourse in AWS fail?

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:

Record name: discourse.example.com

Record type: A

Value: 123.45.678.90

Alias: No

TTL: 300

Routing policy: Simple

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.com does 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.com does not cover that domain — despite your certificate covering *.example.com.

This is the key nuance:

*.example.com does not cover d.example.com if the certificate only lists discourse.example.com and/or *.example.com but the web server doesn’t actually serve the certificate to d.example.com.


Common Mistakes

  1. 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.
  1. 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.
  1. 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).

How to Fix It

Option 1: Check the Certificate’s SAN List

Run:

openssl s_client -connect d.example.com:443 -servername d.example.com

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.