����TV

A March 2025 update will allow ����TV to enhance security measures for issuing publicly trusted Secure Email (S/MIME) certificates by implementing checking. The update aligns with new industry baseline requirements designed to strengthen email security.

Previously, publicly trusted S/MIME certificates could be issued without verifying whether the issuing certificate authority (CA) was explicitly authorized by the domain owner. That meant that any CA could issue an S/MIME certificate for an email address under a domain, potentially leading to unauthorized issuance and security risks.

Now, ����TV has to check the DNS CAA resource record of a domain before issuing an S/MIME certificate for the email domain. This extra step confirms that ����TV is explicitly authorized to issue the certificate, which provides domain owners with greater control over their email security and reduces the risk of mis-issuance.

An introduction to Certificate Authority Authorization

CAA checking gives administrators an extra layer of protection against unauthorized certificate issuance. By implementing CAA records, organizations can enforce their certificate policies at a technical level, reducing the risk of mis-issuance and ensuring that only authorized certificate authorities can issue certificates for their domains.

How CAA works

When you , you control which certificate authorities are permitted to issue certificates for your website or email domain. This mechanism has been in place for TLS certificates since 2017, and it now applies to publicly trusted S/MIME certificates as well.

Why it matters

One of the core concerns of the Web PKI system is that any certificate authority can potentially issue a certificate for any website or email domain, which creates a security risk if the CA becomes compromised. CAA checking addresses this concern by allowing domain owners to whitelist specific CAs, ensuring that only trusted providers can issue certificates for their domains.

What if you don’t use CAA?

For domains that don’t implement CAA, there are no restrictions—any certificate authority can issue certificates for that domain. Just don’t create a CAA record if you don’t want to restrict issuance; your domain will function as it always has.

Policy enforcement with CAA

CAA isn’t just a security feature—it’s also a powerful policy enforcement tool for organizations managing certificate issuance. Beyond reducing security risks by restricting which certificate authorities can issue certificates for your domain, CAA helps enforce internal policies related to certificate procurement and deployment.

For many organizations, especially those with multiple offices or semi-autonomous departments, ensuring compliance with internal certificate policies can be challenging. CAA provides a technical safeguard to prevent unauthorized certificate requests.

Say a team in your engineering department launches a new service and attempts to request a certificate. If they try to use a CA that’s not on your approved list, their request will be automatically blocked to stay in compliance with your organization’s certificate policy.

You also have the option to configure CAA reporting, which allows CAs to send notifications to a designated email address or URL when they receive a request they’re not authorized to fulfill. This option gives administrators real-time visibility into any attempted certificate requests that don’t align with policy guidelines.

How to deploy CAA

The good news is that CAA is relatively easy to implement and comes with a significantly lower risk of configuration errors compared to stricter security mechanisms like HTTP Strict Transport Security (HSTS) or Key Pinning (HPKP).

But there is one technical prerequisite: If you use a managed DNS provider, they have to support CAA records, as this is a newer DNS resource record type.

Our dives into the technical instructions for deploying CAA, but here’s an overview of the key steps.

1. Align CAA records with your organization’s certificate policy

• Start by referencing your existing certificate policy. If your organization has approved specific certificate authorities, use this list to determine which CAs to include in your CAA record.
• If you don’t have a formal policy, identify which CAs your organization commonly uses.
• CAA records can be updated or removed as needed, with changes taking effect according to your DNS Time to Live (TTL) settings.

2.��Create a CAA DNS record

• Your CAA policy can be as restrictive or flexible as needed. You can choose to allow only one certificate authority or approve a handful of providers.
• Even a more flexible policy that permits ten certificate authorities would come with a much lower risk than the 100+ CAs trusted by many platforms.

Understanding CAA record tags

Here’s an example of a CAA record authorizing ����TV to issue S/MIME certificates for an email domain:

yourdomain CAA�� 0�� issuemail�� "digicert.com"

This record would apply to all subdomains under the domain.

• S/MIME certificates use the “issuemail” tag.
• TLS certificates use the “issue” and “issuewild” tags.

If you want to authorize multiple CAs, just add a new CAA record for each certificate authority.

CAA records and DNS hierarchy

CAA records are checked hierarchically within your DNS tree, starting from the highest-level domain.

��

• If you request a certificate for sub.domain.com, the CA first checks for a CAA record at the subdomain level.
• If no record exists at the subdomain, the root domain’s CAA record will be checked.
• For domains using , the parent domain will be checked last.

The security benefits of CAA

Once your DNS CAA resource record is in place, all future certificate requests are checked against it. Any CA that’s not listed must refuse to issue a certificate for your domain, making mis-issuance far less likely to happen.

CAA checking is good protection against human error, but it also defends your organization from adversaries. A hacker attempting to obtain a fraudulent certificate would be limited to the certificate authorities you’ve explicitly authorized. If your CA enforces strong account controls, the attacker wouldn’t be able to complete OV/EV validation, even if they compromised your web server. And if a specific certificate authority has vulnerabilities in its validation or issuance procedures, restricting issuance to a single trusted CA will reduce the odds that your domain could be affected.

CAA limitations to keep in mind

While CAA is an effective security measure, it does have limitations.

• Malicious or compromised certificate authorities: If a CA goes rogue or gets compromised, it can ignore CAA records and issue certificates anyway.
• DNS security risks: DNS record spoofing is rare, but it remains a potential risk. If an attacker gains access to your DNS, they can remove or modify your CAA record, allowing any CA to issue certificates for your domain.
• Local trust exceptions: CAA only applies to publicly trusted CAs. It doesn’t prevent certificate issuance by local root certificates trusted within an organization’s network (e.g., a corporate intranet).

Despite these limitations, CAA remains a valuable tool for reducing the attack surface and ensuring that only trusted certificate authorities can issue certificates for your domain.

The latest developments in digital trust

Want to learn more about topics like S/MIME, DNS, and certificate authorities? Subscribe to the ����TV blog to ensure you never miss a story.