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.
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.
A Subscriber Agreement describes the rights and duties of a CA towards its Subscribers and vice versa.
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.
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.
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 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.
Currently Google Trust Services is trusted by Microsoft, Mozilla, Safari, Cisco, Oracle Java, and Qihoo’s 360 browser. 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 Trust Services issues most of the certificates used by Google.
Yes. You can see our Certification Practice Statement to better understand our issuance practices.
Google Trust Services performs a set of verifications before issuing a certificate. The exact steps can be found in our Certification Practice Statement.
Google certificates are issued by different CAs depending on the current business needs and best practices. 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.
It is recommend that Developers continue keeping their root certificates stores in sync with the above curated root CA bundle to proof their services against future root CA changes, at least on a semi-annual basis.
At this time, the only way to get a certificate from Google Trust Services is via an Alphabet or Google product.
You should contact us with the associated details so we can investigate.
You should contact us with the associated details so we can investigate.
If you are looking to report a security incident involving Google certificates, please follow the steps outlined at Google security and product safety.