How Sysadmins Can Prevent Rogue SSL Certificates Using DNS

You can prevent rogue SSL certificates and stop unauthorized Certificate Authorities from issuing TLS/SSL certificates for your domain by publishing DNS Certification Authority Authorization (CAA) records. A CAA record tells all global CAs which organizations are explicitly permitted to issue certificates for your hostname, acting as a hard security boundary at the DNS level. If a compromised or malicious CA receives a certificate request for your domain, it must check the DNS zone, see your restriction, and immediately abort issuance.

Understanding the Threat of Rogue SSL Certificates

Traditional Public Key Infrastructure (PKI) trusts any publicly trusted Certificate Authority to issue a certificate for any domain, provided the requester can pass a basic domain validation challenge via email, HTTP, or DNS. This creates a significant attack vector known as misissuance. If an attacker compromises a third-party domain validation mechanism or if a CA suffers a severe internal security failure, rogue certificates can be minted without your knowledge.

Once a rogue certificate exists, malicious actors can execute seamless Man-in-the-Middle (MitM) attacks against your users, bypass corporate firewalls, decrypt HTTPS traffic, and spoof your brand identity. While Certificate Transparency (CT) logs help you detect rogue certificates after they are issued, they do not block them in real-time. DNS CAA records solve this by implementing preventive control before the cryptographic handshake even begins.

How CAA Records Work

When a Certificate Authority receives a Certificate Signing Request (CSR) for example.com, industry standards mandate that the CA queries the DNS for CAA records prior to validation and issuance. The CA checks the requested domain, and if no record is found, it walks up the parent domain tree (e.g., checking example.com, then .com, and finally the root) until it finds a policy.

If a CAA record exists, the CA inspects the authorized domain names inside the record. If the querying CA's domain is listed as an issuer, the process continues. If the CA is not listed, or if a restrictive policy is set, the CA is legally and technically bound to reject the certificate request.

CAA Tag Types

Standard CAA records utilize three primary tags to dictate behavior:

• issue: Authorizes a specific CA to issue any type of certificate (wildcard and single-name) for your domain.
• issuewild: Authorizes a specific CA to issue wildcard certificates only. This overrides the issue tag specifically for wildcards.
• iodef: Defines a URL (such as mailto: or https://) where CAs should report invalid certificate issuance attempts.

Determining Your Current DNS Posture

Before you deploy new DNS restrictions, you must audit what CAs currently hold authorization or if any stale records exist in your zone. You can inspect your domain interactively using the CAA Lookup tool to instantly verify existing DNS configurations and catch misconfigured properties across global name servers.

Alternatively, you can query records locally using command-line utilities. For instance, running a standard DNS query via dig yields the raw resource record set.

dig example.com CAA +noall +answer

Sample output for a domain with no restrictive policy:

; (1 server found)
;; global services:
;; no servers could be found

If records are present, the output displays the flags, tags, and CA domain values.

Exact DNS Record Syntax

Adding CAA records to your authoritative DNS zone requires precise syntax. A standard CAA record consists of four distinct components: a Flags byte (usually 0), a Tag (issue, issuewild, or iodef), and the Value (the domain name of the authorized CA).

Here is how standard zone file entries look in BIND format:

example.com.     IN  CAA  0 issue "letsencrypt.org"
example.com.     IN  CAA  0 issue "digicert.com"
example.com.     IN  CAA  0 issuewild ";"
example.com.     IN  CAA  0 iodef "mailto:security@example.com"

Breaking Down the Syntax

• Flags (0): The critical flag is bit 0 (the critical flag). A value of 0 means the flag is non-critical; if a CA does not understand a custom tag, it can ignore it. A value of 1 (or 128 depending on DNS provider implementation) means if a CA does not understand the tag, it must abort issuance. For standard issue tags, use 0.
• Tag (issue): The policy directive.
• Value ("letsencrypt.org"): The domain identifier authorized by the CA/Browser Forum. Note that each CA publishes its specific issuance identifier (e.g., letsencrypt.org, sectigo.com, digicert.com).
• Null Issuer (";"): Setting the value to a semicolon explicitly forbids all CAs from issuing that certificate type. This is commonly used with issuewild to prevent anyone from issuing wildcard certificates.

Step-by-Step Implementation Guide

Implementing CAA records safely requires careful planning to prevent accidental website outages caused by blocking your own legitimate automated renewals.

Step 1: Inventory Your Certificate Providers

List every service, vendor, and internal team that generates SSL certificates for your organization. Check load balancers, CDN providers, email gateways, and Kubernetes ingress controllers. Note the exact CA used by each service.

Step 2: Formulate Your Policy

Determine which CAs require access. If your web apps use Let's Encrypt and your enterprise assets use DigiCert, your zone file will require multiple issue records.

Step 3: Add Records to Your DNS Provider

Log in to your DNS hosting provider. Navigate to your DNS zone management dashboard (menu paths and terminology vary by provider, typically found under "DNS Records", "Zone Editor", or "Manage DNS"). Select "Add Record", choose CAA as the record type, and populate the host, flag, tag, and value fields.

Step 4: Verify via PowerShell or CLI

Confirm your changes have propagated globally by executing an explicit DNS lookup.

Resolve-DnsName -Name example.com -Type CAA

Sample output:

Name                                  Type TTL   Section   Value
----                                  ---- ---   -------   -----
example.com                           CAA  3600  Answer    0 issue letsencrypt.org
example.com                           CAA  3600  Answer    0 issue digicert.com

Comparative Analysis: CAA vs. CT Logs

Common Mistakes and How to Fix Them

Even experienced engineers encounter specific pitfalls when deploying CAA records. Avoid these common operational errors:

• Omitting Subdomains: A CAA record on example.com does not automatically apply to *.example.com unless specified, though CAs check parent domains if no child record exists. Explicitly define records for critical subdomains if they use different CAs.
• Using Incorrect CA Strings: CAs require their exact canonical identifier string. Using a human-readable brand name instead of the registered domain token (e.g., writing Let's Encrypt instead of letsencrypt.org) causes CAs to reject the record and potentially fail issuance.
• Forgetting Wildcard Rules: If you set issue "letsencrypt.org", Let's Encrypt is permitted to issue both standard and wildcard certificates. However, if you want to allow standard certificates from one CA and wildcards from another, you must use the issuewild tag explicitly.

Sysadmin Implementation Checklist

• Inventory all active and legacy SSL certificate authorities.
• Draft the exact issue and issuewild DNS entries required.
• Configure an iodef record pointing to a monitored security email address.
• Add the records to your authoritative DNS server or provider control panel.
• Test resolution using command-line query tools and online validation checks.
• Monitor automated certificate renewal cycles to verify zero disruption.