All Google Cloud users can get certificates from Google Trust Services. For a description of this feature and how to set it up, please read the Certificate Manager Public CA documentation and the Certificate Manager Public CA tutorial.

Google Trust Services issues most of the certificates used by Google and provides certificates for many other enterprises, Google Cloud customers and users.

Google Trust Services offers TLS, Signed HTTP Exchange and S/MIME certificates. See our Certification Practice Statements to better understand our issuance practices.

We use Domain Validation (DV) for all TLS and Signed HTTP Exchange certificates. Google Trust Services is a strong proponent of automation and DV offers robust and fully automated validation.

Google operates globally and its customers expect a highly available, secure, and scalable service.

By operating Google Trust Services as a dedicated entity in the Alphabet group, Google can best meet these expectations.

Google Trust Services performs a set of verifications before issuing a certificate. The exact steps can be found in our Certification Practice Statement (CPS). You can find the current version of Google Trust Services' Certification Practice Statement in the Repository section.

Yes, we issue TLS certificates that contain an IP address instead of a domain name in the certificate subject field.

Control over internet IP addresses tends to change more frequently than control over domain names. For this reason we limit the lifetime of IP certificates to 10 days and only enable the capability to be issued IP certificates for customers who provide a valid business need.

Yes, GTS will issue TLS certificates that contain the clientAuth capability, but only in conjunction with the serverAuth capability that is used by default.

clientAuth and mTLS use cases are better suited for a private PKI, such as Google Cloud's Certificate Authority Service.

The ability to get clientAuth certificates is likely to go away in the future as rules governing the WebPKI change. Chrome has signalled their intention to prohibit clientAuth in the WebPKI.

A Certificate Signing Request (CSR) that sets both the clientAuth and serverAuth capabilities may be created with OpenSSL:

                    $ openssl req -new -keyout my-site.key -out my-site.csr \
                    -subj "/CN=my-site.com" \
                    -addext extendedKeyUsage=clientAuth,serverAuth \
                    -addext subjectAltName=DNS:my-site.com,DNS:my-other-site.com
                  

ACME clients differ a bit in terms of how to pass in a CSR, so check your ACME client's documentation, but generally it will be something like certbot, which uses a `--csr` flag instead of `--domains` for requests using a CSR.

Please follow the reporting instructions at this Google Legal Help Center page.

Select 'Other' as the product under the 'See more products' option.

As detailed in the Google Trust Services (GTS) Certification Practice Statement and Subscriber Agreement, GTS may need to revoke or opt to revoke for a number of reasons. Subscribers must be able to rotate certificates quickly should revocation be necessary. To prepare for revocation that may need to happen within a tight time interval, it is strongly suggested that subscribers use an ACME client with ACME Renewal Information (ARI) support and configure certificates such that they have fully automated lifecycle management. There are circumstances where Google may need to revoke within 24 hours or 5 days, even if doing so would cause adverse impact to a subscriber.

View the Google Trust Services Status Dashboard to see the current status of services. Use the RSS Feed or JSON History links at the bottom of the page to view a feed of current and past issues. Every post to the dashboard will trigger a post to the feed.

The Google Trust Services Status Dashboard provides information about services and APIs that are part of the Google Trust Services ACME API. If there is an active incident, information will be posted in the dashboard for each specific affected API and service. Status indicators are always shown, representing the overall health for each API and service, from one of the following:

• Service Outage: A production system or service is down. Workaround is not available or is not easily implemented.
• Service Disruption: A production system or service is partially impaired and/or does not work as expected. Workaround exists.
• Service Information: A production system or service is partially impaired and/or does not work as expected. Generally, the service is still available, impact is minor, and affects a small number of users.
• Available: Service is fully functional and working as expected.

Currently Google Trust Services is trusted by Microsoft, Mozilla, Safari, Cisco, Oracle Java, Qihoo's 360 browser and Chrome. All browsers or operating systems that depend on these root programs are covered.

In addition, some of Google Trust Services' root CAs may rely on a cross-signature to ensure optimal support across a wide range of devices.

Google certificates are issued by different CAs depending on the current business needs and best practices. Therefore a certificate chain cannot be considered static.

Developers of applications connecting to Google services must take this into consideration and never hardcode Intermediate or Root Certificate Authorities. Developers should instead build a robust mechanism to update the set of CAs trusted by their applications.

Google services' certificates can be issued by any of the Certificate Authority from this regularly updated list. Applications connecting to Google services should trust all the Certificate Authorities from that list. Beware that some tools do not support working with a PEM file that contains multiple certificates bundled together. We also maintain a Java KeyStore version of the list.

It is recommend that Developers continue keeping their root certificates stores in sync with the above curated root CA bundle to harden their services against future root CA changes, at least on a semi-annual basis.

GTS does not provide or set a TLS policy, for Google or for any other entity. However, other organizations like Mozilla and OWASP publish good recommendations.

Google Trust Services strongly advocates the use of TLS 1.3. The Google Front End (GFE) proxies which terminate TLS connections for most Google services prefer TLS 1.3 and have downgrade protections to ensure that a third party cannot force a client which supports TLS 1.3 to negotiate a less-secure version of the protocol. Our frontends will always use the newest version which a client supports. However, Google continues to support TLS 1.0 and TLS 1.1 in order to accommodate older clients which may be unable to upgrade. Some higher-security services do not offer support for TLS 1.0 or TLS 1.1.

Google Cloud Load Balancer customers may set SSL Policies to enforce a minimum TLS version.

Follow the revocation instructions below if you have control of the private key or can prove control of the domain. If you cannot self-revoke provide details via the contact form at the bottom of this page so we can investigate.

Follow the revocation instructions below if you have control of the private key or can prove control of the domain. If you cannot self-revoke provide details via the contact form at the bottom of this page so we can investigate.

There are multiple ways to revoke a certificate if can prove control of the domain(s) included in it or possession of the private key.

Your ACME client's documentation will explain how that client has implemented ACME Revocation

If you cannot revoke via an ACME client, please use the contact form at the bottom of this page to request manual revocation.

If you are looking to report a security incident involving Google certificates, please follow the steps outlined at Google security and product safety.

If you wish to report a probable phishing site that uses a Google Trust Services certificate, please report it via the Google Safe Browsing Phishing Report Form. Please note, Google Trust Services follows the CA industry standard and does not revoke for probable phishing. Reporting to Safe Browsing is the best way to address suspected phishing sites. For additional information, please see the Google Trust Services statement on abuse.

If you wish to report a probable phishing site that uses a Google Trust Services certificate, please report it via the Google Safe Browsing Phishing Report Form. Please note, Google Trust Services follows the CA industry standard and does not revoke for probable phishing. Reporting via Safe Browsing is the best way to address suspected phishing sites.

Certificate Authorities have limited options to detect and prevent abuse. Please see the Google Trust Services statement on abuse for more details.

No.

Google is a financial supporter of Let's Encrypt and members of the Google Trust Services teams have helped, and continue to work closely with, Let's Encrypt to make the web safer and improve standards.

Additionally, some Google products utilize Let's Encrypt for some use cases.

Yes. You can find guidance on how to search the Certificate Transparency logs in the  Google HTTPS Transparency Report and certificate-transparency.org.

The Certification Authority Authorization (CAA) DNS resource record enables you to specify one or more CAs that are authorized to issue certificates for your domain. If there is no CAA record, all CAs are allowed to issue for that domain.

If you use CAA and want to authorize Google Trust Services, we are identified by our domain name:

pki.goog

For more information on how to configure CAA SSLMate maintains a tool that makes it easy to create the necessary resource record.

A certificate binds a cryptographic key to an identity.

TLS/SSL certificates are used to authenticate and establish secure connections to websites. Certificates are issued and cryptographically signed by entities known as Certificate Authorities.

Browsers rely on certificates issued by trusted Certificate Authorities to know that the information transmitted is sent to the right server and that it is encrypted while in transit.

Secure Sockets Layer was the most widely deployed protocol used to encrypt internet communications. The SSL protocol isn't considered secure anymore and should not be used.

Transport Layer Security is the successor to SSL.

A Certificate Authority is like a digital passport office for devices and people. It issues cryptographically protected documents (certificates) to attest that an entity (e.g. website) is who it claims to be.

Prior to issuing a Certificate, CAs are responsible for verifying that the names in the Certificate are linked to the person or entity requesting it.

The term Certificate Authority can refer to both organizations like Google Trust Services, and to systems which issue certificates.

A Certificate Policy is a document published by a CA to state what entities belong to its Public Key Infrastructure and to define what their roles and duties are. You can find the current and previous versions of Google Trust Services's Certificate Policy in the Repository section of this website.

A Certification Practice Statement is a document which describes a CA's issuance practice. It explains to subscribers and relying parties certain aspects of the CA's operation. You can find the current and previous versions of Google Trust Services's Certification Practice Statement in the Repository section.

A Subscriber Agreement describes the rights and duties of a CA towards its Subscribers and vice versa.  You can find the current and previous versions of Google Trust Services's Subscriber Agreement in the Repository section.

 

A Relying Party Agreement related to a certificate describes the responsibilities of everyone who relies on the certificate when visiting a website that uses it.

For example, a user who relies on the TLS certificate for https://pki.goog is a party to the GTS Relying Party Agreement.

You can find the current and all previous versions of Google Trust Services's Relying Party Agreement in the Repository section.

Public Key Infrastructure is a set of technologies, policies, and procedures that make it possible for a Certificate Authority to verify the identity of a certificate requestor, produce a certificate attesting to that verification, and for internet users to rely on the certificate.

Public-key cryptography is the technology that makes this possible

PKI is also used on internal networks but its most common use case is to enable encrypted communication on the web. Web browsers trust certificates issued by CAs included in their root certificates store.

Public Key Cryptography is a form of cryptography using key pairs. One of the keys is considered public and can be distributed widely, the other is considered private and must be kept secret.

Data encrypted with a public key can be decrypted with the corresponding private key and vice-versa.

This enables the concepts of digital signatures and public-key encryption which are the basic building blocks of protocols like TLS where two parties can authenticate each other and share encrypted data without prior exchange of secret information.

A root certificates store contains a set of Certificate Authorities trusted by an Application Software Supplier. Most web browsers and operating systems have their own root certificates store.

To be included in a root certificates store, the Certificate Authority must fulfil strict requirements set forth by the Application Software Supplier. Typically these include compliance with industry standards such as the CA/Browser Forum requirements.

Web PKI is the name of Public Key Infrastructure used by browsers and other user agents on the web.

A Root Certificate Authority, or more correctly, its certificate, is the topmost certificate in a certificate chain.

Root CA certificates are usually self-signed. The private keys associated with them are stored in highly secure facilities, and maintained in an offline state to protect them from unauthorized access.

An Intermediate Certificate Authority, or more correctly, its certificate, is a certificate that is used to sign other certificates in a certificate chain.

Intermediate CAs primarily exist to enable online certificate issuance while allowing the Root CA certificate to remain offline.

An Issuing Certificate Authority, or more correctly, its certificate, is the certificate that is used to sign the bottom most certificate in a certificate chain.

This bottom most certificate is commonly called a subscriber certificate, end-entity certificate or leaf certificate.

Certificates are linked to (cryptographically signed by) their issuer. A certificate chain is made of a leaf-certificate, all its issuer certificates and a root certificate.

Application Software Suppliers Clients must update their root certificates store to include new CA certificates for them to be trusted by their products. It takes some time until products containing the new CA certificates are widely used.

To increase compatibility with older clients, CA certificates can be "cross signed" by another older established CA. This effectively creates a second CA certificate for the same identity (name & key pair).

Depending on the CAs included in their root certificates store, clients will build a different certificate chain up to a root they trust.

ocsp.google.com and o.pki.goog are Google Trust Service's Online Certificate Status Protocol (OCSP) servers. OCSP provides information about the revocation status of digital certificates. OCSP is used by web browsers and other clients to check if a certificate has been revoked by its issuing Certificate Authority (CA).

Google OIDs are available on our OID page

See https://certificate.transparency.dev/.