Certificates

Frequently asked questions and answers about HTTPS certificates and certificate authorities.

What are certificates and certificate authorities?

Websites use certificates to create an HTTPS connection. When signed by a trusted certificate authority (CA), certificates give confidence to browsers that they are visiting the “real” website.

Technically, a certificate is a file that contains:

Web browsers are generally set to trust a pre-selected list of certificate authorities (CAs), and the browser can verify that any signature it sees comes from a CA in that list. The list of trusted CAs is set either by the underlying operating system or by the browser itself.

When a website presents a certificate to a browser during an HTTPS connection, the browser uses the information and signature in the certificate to confirm that a CA it trusts has decided to trust the information in the certificate.

What kind of certificate should I get for my domain?

There are many kinds of certificates in use in the federal government today, and the right one may depend on a system’s technical architecture or an agency’s business policies.

In general:

As a general matter, certificates from any commercial CA will meet the few NIST technical requirements that relate to certificates.

What rules and oversight are certificate authorities subject to?

Since 2012, all major browsers and certificate authorities participate in the CA/Browser Forum. Though self-regulated, the CA/Browser Forum is effectively the governing body for publicly trusted certificate authorities.

The CA/B Forum produces the Baseline Requirements (BRs), a set of technical and procedural policies that all CAs must adhere to. These policies are determined through a formal voting process of browsers and CAs. The BRs are enforced through a combination of technical measures, standard third-party audits, and the overall community’s attention to publicly visible certificates.

The Baseline Requirements only constrain CAs – they do not constrain browser behavior. Since browser vendors ultimately decide which certificates their browser will trust, they are the enforcers and adjudicators of BR violations. If a CA is found to be in violation of the Baseline Requirements, a browser may penalize or inhibit that CA’s ability to issue certificates that that browser will trust, up to and including expulsion from that browser’s trust store.

CA / Browser Resources

Does the US government operate a publicly trusted certificate authority?

No, not as of early 2016, and this is unlikely to change in the near future.

The Federal PKI root is trusted by some browsers and operating systems, but is not contained in the Mozilla Trusted Root Program. The Mozilla Trusted Root Program is used by Firefox, many Android devices, and a variety of other devices and operating systems. This means that the Federal PKI is not able to issue certificates for use in TLS/HTTPS that are trusted widely enough to secure a web service used by the general public.

The Federal PKI has cross-certified other commercial CAs, which means their certificates will be trusted by clients that trust the Federal PKI. However, even when a publicly trusted commercial CA is cross-certified with the Federal PKI, they are expected to maintain complete separation between their publicly trusted certificates and their Federal PKI cross-certified certificates.

As a result, there is not currently a viable way to obtain a certificate for use in TLS/HTTPS that is issued or trusted by the Federal PKI, and also trusted by the general public.

Are there federal restrictions on acceptable certificate authorities to use?

There are no government-wide rules limiting what CAs federal domains can use.

It is important to understand that, while there may be technical or business reasons for an agency to limit which CAs it uses, there is no security benefit to limiting CAs through internal policies alone. Browsers will trust certificates acquired from any publicly trusted CA, and so limiting CA usage internally will not limit the CAs from which an attacker may obtain a forged certificate.

In practice, federal agencies use a wide variety of publicly trusted commercial CAs and privately trusted enterprise CAs to secure their web services.

Then how can I limit which CAs can issue certificates for a domain?

There is no simple and 100% effective way to force all browsers to only trust certificates for your domain that have been issued from a certain CA. In general, the strength of HTTPS on today’s internet depends on the overall standards, competence, and accountability of the entire CA system.

However, domain owners can use DNS Certification Authority Authorization to publish a list of approved CAs.

In addition, domain owners can use Certificate Transparency (see question below) to monitor and discover certificates issued by any CA.

DNS Certification Authority Authorization (CAA) allows domain owners to publish DNS records containing a list of the Certificate Authorities permitted to issue certificates for their domain.

All major CAs participate in CAA and promise to verify CAA DNS records before issuing certificates. Each CA should refuse to issue certificates for a domain name that publishes a CAA record that excludes the CA.

This is only a promise, so a non-compliant or compromised CA could still issue certificates for any domain name even in violation of CAA. But such mis-issuance would be more likely to be detected with CAA in place.

The standard DNS is not secure, so CAA records could be suppressed or spoofed by an attacker in a privileged network position unless DNSSEC is in use by the domain owner and validated by each CA issuer.

CAA can be paired with Certificate Transparency log monitoring to detect occurrences of mis-issuance.

CAA Resources

How can I find out when any certificate is issued for a domain?

Domain owners can use Certificate Transparency to promptly discover any certificates issued for a domain, whether legitimate or fraudulent.

Certificate Transparency (CT) allows domain owners to detect mis-issuance of certificates after the fact.

CT allows CAs to publish some or all of the publicly trusted certificates that they issue to one or more public logs. Multiple organizations run CT logs, and it is possible to automatically monitor the logs for any certificates that are issued for any domains of interest.

Comodo has released an open source Certificate Transparency log viewer that they operate at crt.sh. For example, it is possible to see all recent certificates for whitehouse.gov, and details of specific certificates.

The strength of Certificate Transparency increases as more CAs publish more certificates to public CT logs. Google Chrome requires Certificate Transparency for all new certificates issued after 30 April 2018. Apple platforms, including Safari, require Certificate Transparency for all new certificates issued after 15 October 2018. As a result, most CAs now submit new certificates to CT logs by default.

However, a CA may still issue new certificates without disclosing them to a CT log. These certificates will not be trusted by Chrome or Safari, but they may be trusted by other browsers.

Chrome also exempts private CAs from these transparency rules, so private CAs that do not chain up to any public root may still issue certificates without submitting them to CT logs.

Certificate Transparency Resources