Last update: 5 January 2025

EXECUTIVE SUMMARY: Internet PKI (Public Key Infrastructure) is a sensitive and sometimes fragile ecosystem. Ever since Netscape designed the kernel of its trust in 1995, the global security community has worked to understand the threats and, over time, evolve various mitigations, all while the world continued to function around the changes. Red Sift has been closely involved in this space, exploring the state of the art for PKI protection and working to protect our customers.

This whitepaper provides a deep dive into the lessons we learned while building Red Sift Certificates, our flagship solution for PKI posture monitoring. We start with an overview of how the world manages trust and introduce more and more complex concepts and technologies until we explore the techniques we implemented to help our customers achieve their security objectives. Finally, we introduce High-Assurance Certificate Transparency Monitoring, a must-have technique for those organizations that require top public PKI security.

The last 15 years have been great for the Internet when it comes to transport layer security. After decades of neglect prior to that, we saw a determined effort to get encryption right, the effort that still continues. It took many years, but the engineering community worked to update the Transport Layer Protocol (TLS) to upgrade it with modern cryptography, remove cruft, as well as retain backward compatibility. A resounding success.

And, yet, public PKIs remain essentially as secure as they've always been.

In 2011, a small Dutch Certification Authority (CA) called DigiNotar was struck and its security completely compromised. In the following days, hundreds of certificates were issued for some of the world's most important properties. Google, Microsoft, Mozilla, Twitter… take your pick—fraudulent certificates were issued for all of them.

To make the situation worse, these certificates were used against approximately 300,000 users in an active network attack designed to compromise encryption and collect their secrets and passwords. An attack of that scale was unprecedented; it hadn't been seen before and hasn't been seen since.

The same thing could happen today, because the fundamental weaknesses in our trust model remain.

Public Key Infrastructure (PKI) refers to the framework of technologies, policies, and procedures that are used to manage digital identities. For example, every website needs a digital identity that can be verified by consumers to support secure encrypted access to it. These identities are built around private encryption keys that can be verified using the matching public keys. In practice, we roll these public keys into certificates that contain all the necessary information to perform the validation. From an end-user perspective, certificates are a technical detail that ensures security, but there's a complex ecosystem behind the scenes that ensures that the certificates provide the security we need.

Despite the word "public" in the name, PKIs don't have to be public. Anyone can create their own private PKI and enforce whatever rules they wish. However, world-scale security can be provided only by public PKIs that are built using well defined rules and allow anyone to participate. Web PKI is one such public PKI; it's tightly regulated and managed by large browser vendors and used to protect websites. There is also Internet PKI, which is less defined, but sometimes works within Web PKI and sometimes outside. For our purposes here, the distinction is not very important most of the time, but we'll emphasize it when it is.

As already mentioned, at the surface, we use digital certificates to authenticate access to websites. That part is straightforward: before you can access your destination, the website is required to present a valid certificate and prove possession of the corresponding private key. However, the process we use to issue certificates is very elaborate.

First, we select a group of trusted organizations we call Certification Authorities (CAs). We make sure that they know what they're doing in terms of network security and overall competence, and we give them precise instructions about what certificates should look like. The chief requirement here is to ensure that digital certificates are issued only to their rightful owners, through the process called validation.

Here comes the tricky part: performing validation at world scale is not easy, because you have to create trust relationships from scratch. The dominant approach in use today is proof of infrastructure control. Practically speaking, this means that, if you want a certificate for "google.com", you just need to demonstrate a level control over that domain name, for example by publishing a special file on its website.

This design, created by Netscape in the early days of the Internet, is what powered the explosive growth of the Web, because it's easy for anyone to use. Unfortunately, it comes with two inherent weaknesses:

• Validation is done over public networks without cryptographic authentication. An adversary who can successfully attack network routing or DNS, or hijack network communication, can subvert issuance and obtain fraudulent certificates.
• Domain owners have no control over what certificates are issued for their properties. In other words, CAs are trusted to do their job correctly. Although we audit them to establish their competency, in practice there are a variety of things that can go wrong and have gone wrong. As we've already seen with DigiNotar, their own security can be broken. They can make mistakes in their operations or become victims of social engineering. Or they can be legally compelled by their governments to do things that are not allowed.

Understanding these weaknesses is important for our ability to craft strategies to detect or prevent attacks, and to minimize the damage should they happen.

As already discussed, certificates are issued only after a successful demonstration of control over the relevant part of network infrastructure. For domain names, the process is approximately as follows:

1. A certificate for example.com is requested from a CA
2. The CA generates a long random number and sends it back
3. The initiator publishes the random number on the plaintext example.com website
4. The CA then verifies that the random number can be observed over HTTP
5. The CA issues the certificate

What can we deduce? The validation process relies on some basic Internet plumbing, such as DNS resolution, IP address routing (via BGP protocol), and assumes that the communication will not be hijacked. Today, neither of these operate securely and there are a variety of attacks that can be executed against them. For example, a BGP attack can redirect traffic for an IP address to the attacker, instead to the rightful owner. DNS spoofing can be used to redirect the traffic for a website to an IP address that's under the attacker's control. An active network attack against either end of the conversation (website or CA) can achieve the same effect.

Now that we understand how important CAs are for internet security, what do we know about them? Browser vendors rely on a system called Common CA Database (CCADB) to track CAs and their digital certificates that have special powers of issuing end-user certificates. This database is publicly available and so I recently took a look at the data. Here's what I discovered:

• There are 94 CA organisations in the database that are trusted by at least one out of four major vendors (Apple, Google, Microsoft, or Mozilla).
• Out of those, 39 organisations are trusted by all four vendors.
• The 94 organisations are spread across 42 countries.
• The smaller group of 39 organisations is spread across 22 countries.

What can we conclude from this data? First, there is a substantial attack surface in the number of organisations alone. For our security to be preserved, all of them have to do the right things to stay secure and avoid operational mistakes. Second, in a world with complex political relationships, having the CAs in so many countries creates theoretical and practical possibilities for political abuse.

These weaknesses are not just theoretical. In fact, all of them have happened at various points in time.

• In 2011, the security of the DigiNotar CA was completely compromised and hundreds of rogue certificates issued.
• In 2021, the .cd top-level domain name was discovered to have a misconfigured nameserver, allowing the researcher to redirect 50% of all .cd DNS traffic (including subdomains).
• In 2022, attackers executed a BGP attack against KLAYswap, a Korean crypto exchange, and stole $2m USD in crypto currency.
• In 2023, network access to the "jabber.ru" web server was hijacked, allegedly by law enforcement in Germany, allowing for issuance of a certificate that was used to decrypt all encrypted access.
• In 2024, activity of the Salt Typhoon espionage group was discovered; it was thought to have compromised network connectivity of 60 organisations across 80 countries.
• In 2025, the Fina CA was discovered to have issued twelve certificates for the 1.1.1.1 IP address (property of Cloudflare) without permission, over a period of 16 months.

These problems are just a representative sample of what we know about. I've selected each example to demonstrate one particular attack vector. It's likely that there have been other similar attacks that remain undiscovered.

In the wake of the DigiNotar attack in 2011, many proposals were made for how to improve the security of public PKIs. Those that aimed for substantial changes to how certificates issues failed. Those who aimed at incremental improvements succeeded, and Certificate Transparency (CT) as one of them. It certainly helped that this effort originated at Google, who were able to wield substantial power via their Chrome browser.

The goal of CT, as the name implies, is to extend Web PKI with systems that provide complete visibility into certificate issuance. If we can't change the fundamentals of how the trust works (no technical controls over CAs' activities), then we can at least focus on being able to observe what they're doing.

With CT, Web PKI is extended with CT logs, which serve as auditors. Before a certificate can be issued, its essential information has to be recorded by several independently-operated CT logs. For every observed certificate that's about to be issued, CT logs return confirmations in the form of digital signatures. As the final step, these signatures are embedded in the certificates themselves.

It's the last step that makes this system work: now that all certificates carry proofs of inclusion in CT logs, browsers can extend how they validate certificates and fail any certificates whose inclusion can't be validated. As a result, only publicly recorded certificates can be used for websites.

Note: This one area where the distinction between Web PKI and Internet PKI matters. Certificate Transparency has currently been implemented only as part of Web PKI and enforced by browsers. Certificates without CT information are still perfectly valid; they will work for Internet PKI purposes, but not for websites. This may change in the future.

CT has been effectively mandatory since 2018. Chrome was the first browser that started to require it, and that alone was enough given its market dominance. Apple, Microsoft, and Mozilla later followed. The visibility provided by CT was of tremendous value as it enabled wholesale worldwide monitoring of certificate issuance, enabling continuous improvements and tuning that is still ongoing.

Note: Technical specifications that regulate certificate issuance are managed by an industry body called CA/Browser Forum. Browsers and CAs work together to decide on how validation is performed and certificates issued. The relationship is not symmetric; browsers control which CAs they trust, which means that they have the upper hand in the conversations.

As we've already seen, Certificate Transparency is a very useful tool for global ecosystem monitoring, but it also enables domain name owners to monitor issuance of certificates that are connected to their properties. If you recall from earlier, the weaknesses in how public PKIs operate make it possible for third-parties, malicious or not, to issue certificates for domain names they don't own. With CT, anyone can monitor certificates for any domain name.

Organizations that are concerned about unauthorized activity can deploy CT monitors to examine the global stream of certificates and find the ones that apply to them. This activity opens up two exciting possibilities:

• Domain owners can monitor their own certificates to understand the centers of issuance and patterns, as well as to understand which CAs are used by whom.
• Additionally, it's possible to discover certificates that have not been authorized. In other words, CT makes it possible to detect misissued certificates.

Certificate Transparency, as currently implemented, doesn't provide perfect visibility into worldwide certificate issuance. That's because not all vendors require publishing to CT as part of their root store policy. Here's where we're currently:

• Apple requires CT for all certificates, including their browser and any other code that's built in top of their official libraries
• Google's Chrome requires CT for all websites
• Microsoft's Edge is based on the Chromium and requires CT
• Mozilla's Firefox also requires CT

Because CT is not required by Baseline Requirements and because root store policies don't require that all trusted CAs record everything to CT, there are loopholes that can be exploited. Therefore, technically, publishing to CT is not required. Although CAs tend to record to CT by default, some provide an opt-out functionality. Additionally, then could be legally compelled to publish outside CT.

Obviously, such certificates won't be valid for any websites, but they may pass validation in a variety of cases:

• API requests (except from Apple's platforms)
• Server-to-server communication, for example for email exchange or XMPP

We expect that the scope of CT will expand in the future to include all public certificates. For the time being, have in mind its limitations and update your threat models accordingly.

Certification Authority Authorization (CAA) is a standard that enables domain name owners to control issuance of certificates for their properties. CAA policies are stored in the Domain Name System (DNS), using the CAA resource record. Several features are supported:

• Controlling which CAs are allowed to issue
• Separate controls for the control of issuance of standard certificates, wildcards, as well as email and BIMI certificates
• Ability to communicate fine-grained policies on a per-CA basis
• Supported distribution of contact information should any problems arise

Consider the following example configuration:

example.com.  CAA     0 issue "letsencrypt.org"
example.com.  CAA     0 issuewild "digicert.com"
example.com.  CAA     0 issuewild "sectigo.com"
example.com.  CAA     0 issuemail ";"
example.com.  CAA     0 issuevmc ";"
example.com.  CAA     0 iodef "pki@example.com"

CAA is a control that's applied just prior to certificate issuance. It's not enforced via a strong control, but it's been mandated for all CAs to use via Baseline Requirements. Any issuance that doesn't respect the owner's CAA configuration is considered to be misissuance.

CAA's essential capability is its ability to restrict which CAs can issue which types of certificates. If there is no CAA policy on a domain, all CAs and certificate types are allowed. However, if there is at least one directive for a certificate type (e.g., "issue" for standard certificates or "issuemail" for S/MIME), then only the listed CAs are allowed to issue. If a single semicolon is observed, then issuance is not allowed whatsoever.

Let's decipher the previous example configuration:

• Let's Encrypt is allowed to issue standard certificates
• DigiCert and Sectigo are allowed to issue wildcard certificates
• No one is allowed to issue either S/MIME or BIMI certificates
• The "pki@example.com" address can be used to communicate problems

The "issue" and "issuewild" tags work in tandem. If only the "issue" tag is present, issuance of both standard and wildcard certificates is allowed. However, when the "issuewild" tag is present, it exclusively controls issuance of wildcard certificates.

CAA is flexible in terms of placement. This means that each domain can have a different configuration. Further, if CAA is not observed on a subdomain, the CAA configuration of the parent is checked and used if available.

In the previous section we discussed the mechanics of restricting which CAs can issue, but how does that help exactly? This activity is very valuable because it achieves attack surface reduction. If you recall from earlier, there are a variety of weaknesses in how public PKIs are organized. In particular there are many CAs that can issue certificates for your properties, and all of them have to do the right things every single time.

In practice, most organizations work with a small number of CAs, which leaves all other CAs as a liability. When CAA is used, that liability is minimized.

In practice, the recommended basic approach is as follows:

1. Build a comprehensive list of owned domain names
2. Use CT to build an inventory of all public certificates
3. Monitor CT for a while and build a list of observed CAs
4. Deploy CAA that restricts issuance only to the short list of observed CAs

This straightforward approach can be used to minimize the PKI ecosystem risk with little danger of breaking the existing certificate issuance arrangements. The desired CAA configuration needs to be configured on every domain name registration. Depending on the desired security level, you can choose one list of CAs for all properties, or restrict to only the CAs used on a per-domain basis.

Note: DNS is commonly used to delegate limited control to third-parties, for example to provide a fully managed service on your own domain. This is usually done via the CNAME resource record. Setting a CAA policy on the main domain name should not break issuance, even if when third parties wish to use a CA that's not on our list. That's because, CNAME delegates all aspects of DNS, including the CAA policy. The only catch is that the third parties you use have to be aware of CAA and issue their own CAA policy that works for them.  

The core CAA standard makes a good starting point, but falls short for organizations that need to secure high-value properties. One "loophole" is that CAA restricts which CAs can issue, but have no way of preventing third-parties parties from using those same allowed CAs to obtain certificates. This is made worse by the fact that virtually every organization in the world uses Let's Encrypt, for their free certificates and automation. This makes the barrier to using Let's Encrypt very, very low.

This is where ACME CAA extensions come in. ACME is short for Automatic Certificate Management Environment; it's the standard for automated certificate issuance popularised by Let's Encrypt from its launch in 2015, and now adopted by all other CAs. RFC 8657 standardizes two additional features that are at the crossroads of ACME and CAA:

• Restricting which CA customer accounts can be issued from
• Restricting which ACME validation methods can be used

At the time of writing, RFC 8657 is not mandatory. but it's expected that it will be adopted in the near future. Today, Let's Encrypt is the only CA that officially supports it. The nature of these extensions is that, unlike the base CAA, they don't have to be supported by all CAs to be useful. They need to be supported only the CAs you do business with. If in doubt, talk to your CA. Some of them have proprietary features that can be used with similar effect.

With RFC 8657, it's possible to allow issuance for a domain name from one CA, but in such a way that no other customer of that same CA can issue for the same name. Here's what that might look like when working with Let's Encrypt:

example.com.  CAA  0  issue "letsencrypt.org;
                             accounturi=https://acme-v02.api.
                             letsencrypt.org/acme/acct/1726001367"

For as long as the above configuration fragment is active, only account "1726001367" will be able to get certificates from Let's Encrypt for the domain "example.com". If issuance from multiple accounts is needed, multiple CAA tags can be configured, each allowing a different customer account.

The other feature of RFC 8657 is that it supports restricting which validation methods can be used by ACME before a certificate is issued. ACME comes with a variety of methods and customers are normally able to choose which one they prefer when they request a certificate. The most popular validation method is proof of ownership, which requires that a response to the challenge from CA is published on the website for which the certificate is required.

This approach is often convenient, because it allows every and any server to talk directly to a CA and get certificates for itself. However, in the context of security, allowing servers to get their own certificates is often not ideal; whoever controls a server can get certificates for any domain pointing to it.

One way to exploit such an arrangement is via a dangling DNS misconfiguration. For any domain name to work, configuration changes have to be made in two locations. First in the DNS, where A and AAAA records are used to add IPv4 and IPv6 addresses, respectively. Then, a server has to be configured at those same IP addresses to provide responses. A dangling DNS problem is created when a server is decommissioned, but its DNS entries remain in place. Imagine that the IP addresses came from a cloud service, as is very often the case. Now, anyone who is assigned those IP addresses can get certificates for the dangling DNS domain. This is one example, there are several other attack vectors in the DNS that can be used with the same effect.

An organization that wants to prevent this type of problem may choose to centralize their certificate issuance and use the DNS-based ACME validation option. However, for that to work, they must ensure that all other validation methods are disabled. Here's what that might look like using RFC 8657:

example.com.    CAA    0    issue "letsencrypt.org;
                                   validationmethods=

                                  dns-01"

With this configuration, certificate issuance can be approved only by making changes to the DNS configuration of the domain name where certificates are requested.

The two restriction methods specified in RFC 8657 support restrictions that are in some way similar, but there are key differences between them that may influence which one you will want to use and when.

• Validation method restriction doesn't require request authentication. When issuance is restricted to a method such as "dns-01", only parties who control your DNS (or the relevant parts of it) can satisfy the CAA configuration. This does reduce the attack surface, but, in this case, the request to issue is still not authenticated. For example, it would still be possible to exploit a DNS misconfiguration.
• Account restriction enforces strong authentication. When issuance is restricted to a specific customer account this, in turn, forces strong authentication of the issuance request, before any validation takes place. With ACME, for example, accounts are secured using public cryptography. The very first activity of any ACME client is to create a unique cryptographic identity, which is later used for every issuance. When account restriction is in place, request authentication is the first step in the ACME interaction, as the client has to prove its association with the account specified in the CAA configuration.

Note: In June 2025, the CA/Browser Forum voted to adopt Ballot SC-085v2, which adds a requirement to validate DNSSEC when performing CAA lookups and DCV (domain control validation). These changes will become mandatory for all CAs from March 2026. After that time, domains with DNSSEC will not be susceptible to any form of DNS spoofing. 

The extensions defined in RFC 8657 allow us to deploy stricter security controls for certificate issuance, but doing so doesn't come for free. It takes time and resources to restructure and organize issuance in ways that are compatible and yield better security at the same time. It's normally not useful to use this approach for all domains owned by an organisation, because it's not going to be cost-effective. However, it can be used for a small number of high-value properties. For everything else, the simpler approach of just restricting issuance to a small number of CAs would be sufficient.

For your high-value properties, consider the following approach:

1. Choose two or three competent CAs to work with. You need at least two so as to avoid a single point of failure. Normally, for high-value properties I would recommend always having at least one valid backup certificate in case anything goes wrong with the primary. At a minimum, your selected CAs have to either support RFC 8567 or have equivalent proprietary functionality.
2. Deploy strict CAA configuration on the main domain name that restricts issuance only to the selected CAs and—crucially—only to the specific accounts within the CAs. Such a configuration will enable strong cryptographic validation.
3. Monitor your DNS configuration to a) ensure there are no dangling DNS issues and b) understand if there are any delegations to third-parties via CNAMEs (which may be using their own overriding CAA configuration).

As we've already seen, Certificate Transparency has been a game changer when it comes to our ability to monitor the activities of certification authorities. Still, the monitoring is not without challenges:

• It's still possible to publish public certificates outside CT, as discussed in an earlier section of this document.
• CT monitoring is still not widespread. Despite it having been mandatory for a good number of years, the majority of organisations still don't spend enough resources on monitoring of certificate issuance for their own properties.
• Distinguishing signal from noise is difficult. Certificates often don't contain enough information to help distinguish regular issuance from certificates obtained fraudulently by third parties. Doing this requires advanced monitoring tools, and most organisations are not yet aware of them.

Even though our goal with this document is to explore the art of the possible, we recognise that many organisations don't need state of the art security. Even those that do, often don't need best security across their entire domain name estate and websites.

We advise that you divide your estate into three groups based on their risk profile:

• Very low-risk; put in this group any parked and unused domain names. Depending on the size of your organisations, you may have a few of these, but there could be hundreds as well. Unless you have excellent automation of your DNS configuration across the board, it's probably not going to be worth your time to improve the security of this group. 
• Low risk; put in this group any domain names on which you have actual websites or applications. This should be your default choice. For this group you should aim to deploy a simple CAA configuration that restricts issuance to a smaller number of CAs you want to do business with, as already discussed earlier in this document. These properties are not likely to be attacked, which means that CAA will be used largely to enforce your policy for CA selection.
• High-risk; put in this group your high-risk properties—anything you think might be at real risk of being attacked. Websites and applications dealing with money, government business, communications, and anything that could be exposed to genuine active network attacks. You will want to protect this group with all technical measures that are available to you.

High-Assurance CT monitoring is an approach where you can with high certainty monitor a stream of certificates published to Certificate Transparency and distinguish certificates under your control from certificates under control by unauthorized third-parties.

Conceptually, the approach is simple and based on validating what's known to be good, after which everything else can only be bad:

1. Maintain an inventory of certificates known to be under your control
2. Monitor Certificate Transparency to look for certificates you don't already know about

That's it. Only two steps, but the first step may take a fair amount of work to achieve in practice, depending on what kind of setup you have. Remember, this is something that you will be doing only for your high-risk properties, and not everywhere.

• If you're using a Certificate Lifecycle Management (CLM) tool, or ACME with a commercial CA, they will likely have a built-in certificate inventory. It shouldn't be too difficult to get your certificates out of it, but you will need to do some programming against their APIs for that.
• If you're using ACME with a free CA (e.g., Let's Encrypt), there may not be a certificate inventory you can integrate with. In this case you'll need to implement some sort of mechanism to collect issued certificates and transport them to a central location. This will be easier if all your certificates are issued from the same server, but shouldn't be too difficult even with multiple servers.

In practice, it's more likely than not that you'll need to maintain a separate database where you will store your own certificates. This is because centralised issuance is very rare in real life, especially at scale. There are always special situations, including those where aspects of your public PKI are delegated to third parties. The complete solution will need to integrate a variety of data sources for a comprehensive view.