Subdomain Certificates: Security Risks & Fixes

TL;DR

Yes, there *are* security concerns with certificates covering multiple subdomain levels (like *.example.com). While convenient, they can be misused if not managed carefully. This guide explains the risks and how to secure your setup.

Understanding the Problem

Certificates issued for wildcard subdomains (e.g., *.example.com) protect any subdomain directly under ‘example.com’. However, they also potentially cover deeper levels without explicit configuration. This can lead to unexpected security issues.

Step-by-Step Security Guide

1. Understand Certificate Scope: A certificate for *.example.com will generally cover:
   • blog.example.com
   • shop.example.com
   • dev.example.com
   • But also, potentially: test.dev.example.com and even deeper levels like stage.test.dev.example.com!

   This is usually what you want, but it’s crucial to be aware of the full coverage.

2. Control Subdomain Creation: The biggest risk comes from uncontrolled subdomain creation. If anyone can create a subdomain (e.g., through a self-service portal or misconfigured DNS), they could potentially issue a certificate for it, even if you don’t intend to secure that subdomain.
   • Implement strict DNS controls: Limit who can add/modify DNS records.
   • Automate Subdomain Discovery: Regularly scan your DNS zone for unexpected subdomains (see Step 5).
3. Certificate Authority (CA) Restrictions: Some CAs allow you to restrict the levels of subdomains a wildcard certificate covers. Check your CA’s documentation.
   • For example, some CAs offer options to limit coverage to only one level deep.
4. Use Subject Alternative Names (SANs): For specific subdomains that *must* be secured, consider adding them explicitly as SANs to your certificate instead of relying solely on a wildcard.

   openssl x509 -text -noout -in your_certificate.pem | grep 'Subject Alternative Name'

   This shows you the domains covered by the certificate. Add specific subdomains here if needed.

5. Regular DNS Zone Transfers & Monitoring: Regularly check your DNS zone file for unexpected entries. Tools like dig or online DNS lookup services can help.

   dig example.com ANY

   Review the output carefully for any subdomains you don’t recognise. Automate this process with scripting if possible.

6. Certificate Revocation: If an unauthorised subdomain certificate is issued, *immediately* revoke it through your CA’s control panel. Don’t delay!
7. HSTS Considerations: Be very careful when using HSTS (HTTP Strict Transport Security) with wildcard certificates. If you add a domain covered by the wildcard to your HSTS policy, all its subdomains are also protected.
   • Incorrectly configured HSTS can lock users into insecure subdomains if they later become compromised.

Summary

Wildcard certificates are powerful but require careful management. Control subdomain creation, understand the certificate scope, and regularly monitor your DNS zone to mitigate potential security risks.