The SSL/TLS certificate graveyard: Subdomains that never die

The security of a website relies heavily on an SSL/TLS certificate. This digital file acts as an identity card for your server, proving its authenticity and encrypting the connection between the user’s browser and your site.

When organizations manage dozens or hundreds of online services, they often use a single, powerful certificate (either the Wildcard or Multi-Domain (SAN) Certificate) to cover many different subdomains. This is convenient, but it hides a serious, common security threat: the Subdomain Takeover.

This threat arises when a forgotten, abandoned subdomain is still covered by a valid, trusted certificate, creating a silent entry point for attackers. We call this scenario the “SSL/TLS Certificate Graveyard.”

---

The root of the problem: Certificates cast a wide reach

To understand the risk, you need to know what these powerful certificates do:

• Wildcard Certificate: This certificate covers your main domain and all of its subdomains at the first level. For example, a certificate for *.example.com will secure blog.example.com, shop.example.com, and test.example.com.
• Multi-Domain (SAN) Certificate: This covers a specific list of separate, individual names, which can include both full domains and specific subdomains (e.g., example.com, app.widgets.net, and api.internal.org).

Because these certificates cover such a wide scope, an administrator can easily spin up a new service (like staging.example.com) and secure it instantly because the certificate already covers it.

The problem occurs when that service is decommissioned. The server is shut down, the project ends, and everyone moves on.

What people often forget is the DNS record.

---

How a subdomain becomes a ghost

The Domain Name System (DNS) is the internet’s phonebook. It translates a human-readable name (like www.google.com) into a machine-readable IP address. When a subdomain is abandoned, two dangerous things can happen:

1. Dangling DNS

The server hosting old-project.example.com is turned off. However, the system administrator forgets to remove the CNAME or A record from the company’s DNS settings.

• If the DNS record points to a specific cloud resource (like an AWS S3 bucket or an Azure storage account) that has been deleted, the DNS entry becomes “dangling.”
• This means the record is still publicly advertising that the subdomain exists, but the resource it points to is unclaimed.

2. Subdomain takeover

The attacker finds this dangling DNS entry. Since the resource is unclaimed, they can create a new one (e.g., an S3 bucket with the exact same name) and point it to their own server. They have now successfully “taken over” the subdomain.

Here’s the problem: when a user visits the now-hijacked old-project.example.com, the attacker’s malicious server presents the organization’s original, valid, trusted SSL/TLS certificate.

The user’s browser sees that the certificate is legitimate and covers that specific subdomain, so it flashes no security warnings. The attacker now has a fully trusted platform to host phishing pages, serve malware, or launch further attacks, all under the guise of your company’s security. This is why we call them subdomains that never die.

---

Essential security hygiene: Stopping the takeover

Preventing a Subdomain Takeover requires strict attention to detail whenever a digital asset is retired. Your defense strategy should focus on two key areas: DNS Management and Certificate Monitoring.

1. Mandatory DNS removal

This is the single most important step. When you decommission a server or cloud resource, you must immediately remove its corresponding DNS record (A, CNAME, etc.) from your zone file before or simultaneously with the resource’s deletion. Never leave a service running without a specific owner.

2. Routine auditing

You cannot rely on manual memory. Your team must perform regular (ideally monthly) audits of your public DNS zone files. Compare every live DNS entry against your company’s active inventory of servers and services. Any FQDN (Fully Qualified Domain Name) that resolves but has no clear, active owner should be immediately investigated and removed.

3. Limiting certificate scope

Where possible, avoid relying solely on one huge Wildcard certificate. Using Single-Name Certificates for distinct, sensitive applications helps limit the attack surface. If you use a Wildcard, ensure the private key is handled with the highest level of security.

---

Skip the spreadsheets. Try Certificate Monitoring Today.

Manual DNS auditing is time-consuming and prone to human error. The digital world changes too fast to rely on memory or spreadsheets to prevent this sophisticated threat.

For reliable security, you need automated surveillance. 101domain’s Certificate Monitoring Service is designed to solve this exact problem:

• Continuous Scanning: The service constantly monitors global Certificate Transparency (CT) logs (the public record of all issued certificates) looking for your domain names.
• Alerting on Unauthorized Activity: You are immediately notified if any certificate is issued for your domain that you didn’t approve, which is often the first sign of an attempted attack.
• Tracking and Mapping: We help you map and track all subdomains covered by your current certificates, making it easy to see which ones are secured by a living certificate, allowing you to quickly spot and remove the forgotten “ghost” subdomains in your DNS.
• Preventing Outages: receive timely alerts well before your legitimate certificates expire, preventing costly service outages.

Don’t let abandoned subdomains become a trusted path for attackers. Leverage the power of automated monitoring to ensure your entire digital estate is secure and accounted for.