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 Certificate Transparency to reduce the risk or impact of misissued or fraudulent certificates.

Certificate Transparency (CT) allows domain owners to detect missuance 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. Certificate Transparency is not currently a requirement for CAs – however, as the use of CT increases, so does the viability of requiring CT for publicly issued certificates.

Certificate Transparency Resources