Security Blog
The latest news and insights from Google on security and safety on the Internet
How Google does certificate lifecycle management
10 mars 2020
Posted by Siddharth Bhai and Ryan Hurst, Product Managers, Google Cloud
Over the last few years, we’ve seen the use of Transport Layer Security (TLS) on the web increase to more than 96% of all traffic seen by a Chrome browser on Chrome OS. That’s an increase of over 35% in just four years, as reported in our
Google Transparency Report
. Whether you’re a web developer, a business, or a netizen, this is a collective achievement that’s making the Internet a safer place for everyone.
Percentage of pages loaded over HTTPS in Chrome by platform (
Google Transparency Report
)
The way TLS is deployed has also changed. The maximum certificate validity for public certificates has gone from 5 years to 2 years (
CA/Browser Forum
), and that will drop to 1 year in the near future. To reduce the number of outages caused by manual certificate enrollments, the Internet Engineering Task Force (IETF) has standardized Automatic Certificate Management Environment (
ACME
). ACME enables Certificate Authorities (CAs) to offer TLS certificates for the public web in an automated and interoperable way.
As we round off this exciting tour of
recent TLS history
, we’d be remiss if we didn’t mention
Let’s Encrypt
- the first publicly trusted non-profit CA. Their focus on automation and TLS by default has been foundational to this massive increase in TLS usage. In fact, Let’s Encrypt just issued their billionth (!) certificate. Google has been an active supporter of Let’s Encrypt because we believe the work they do to make TLS accessible is important for the security and resilience of the Internet's infrastructure. Keep rocking, Let’s Encrypt!
Simplifying certificate lifecycle management for Google’s users
These are important strides we are making collectively in the security community. At the same time, these efforts mean we are moving to shorter-lived keys to improve security, which in-turn requires more frequent certificate renewals. Further, infrastructure deployments are getting more heterogeneous. Web traffic is served from multiple datacenters, often from different providers. This makes it hard to manually keep tabs on which certificates need renewing and ensuring new certificates are deployed correctly. So what is the way forward?
With the adoption numbers cited above, it’s clear that TLS, Web PKI, and certificate lifecycle management are foundational to every product we and our customers build and deploy. This is why we have been expanding significant effort to enable TLS by default for our products and services, while also automating certificate renewals to make certificate lifecycle management more reliable, globally scalable, and trustworthy for our customers. Our goal is simple: We want to ensure TLS just works out of the box regardless of which Google service you use.
In support of that goal, we have enabled automatic management of TLS certificates for Google services using an internal-only ACME service,
Google Trust Services
. This applies to our own products and services, as well as for our customers across Alphabet and Google Cloud. As a result, our users no longer need to worry about things like certificate expiration, because we automatically refresh the certificates for our customers. Some implementation highlights include:
All Blogger blogs, Google Sites, and Google My Business sites now get HTTPS by default for their custom domains.
Google Cloud customers get the benefits of Managed TLS on their domains. So:
Developers building with Firebase, Cloud Run, and AppEngine automatically get HTTPS for their applications.
When deploying applications with Google Kubernetes Engine or behind Google Cloud Load Balancing (GCLB), certificate management is taken care of if customers choose to use Google-managed certificates. This also makes TLS use with these products easy and reliable.
Performance, scalability, and reliability are foundational requirements for Google services. We have established our own publicly trusted CA, Google Trust Services to ensure we can meet those criteria for our products and services. At the same time, we believe in user choice. So even as we make it easier for you to use Google Trust Services, we have also made it possible across Google’s products and services to use Let’s Encrypt. This choice can be made easily through the
creation of a CAA record
indicating your preference.
While everyone appreciates TLS working out of the box, we also know power users have specialized needs. This is why we have provided rich capabilities in
Google Cloud Load Balancing
to let customers control policies around TLS termination.
In addition, through our work on
Certificate Transparency
in collaboration with other organizations, we have made it easier for our customers to protect their and their customers’ brands by monitoring the WebPKI ecosystem for certificates issued for their domains or those that look similar to their domains, so they can take proactive measures to stop any abuse before it becomes an issue. For example, Facebook used Certificate Transparency Logs to
catch
a number of phishing websites that tried to impersonate their services.
We recognize how important security, privacy, and reliability are to you and have been investing across our product portfolio to ensure that when it comes to TLS, you have the tools you need to deploy with confidence. Going forward, we look forward to a continued partnership to make the Internet a safer place together.
Aucun commentaire :
Enregistrer un commentaire
Libellés
#sharethemicincyber
#supplychain #security #opensource
android
android security
android tr
app security
big data
biometrics
blackhat
C++
chrome
chrome enterprise
chrome security
connected devices
CTF
diversity
encryption
federated learning
fuzzing
Gboard
google play
google play protect
hacking
interoperability
iot security
kubernetes
linux kernel
memory safety
Open Source
pha family highlights
pixel
privacy
private compute core
Rowhammer
rust
Security
security rewards program
sigstore
spyware
supply chain
targeted spyware
tensor
Titan M2
VDP
vulnerabilities
workshop
Archive
2024
déc.
nov.
oct.
sept.
août
juil.
juin
mai
avr.
mars
févr.
janv.
2023
déc.
nov.
oct.
sept.
août
juil.
juin
mai
avr.
mars
févr.
janv.
2022
déc.
nov.
oct.
sept.
août
juil.
juin
mai
avr.
mars
févr.
janv.
2021
déc.
nov.
oct.
sept.
août
juil.
juin
mai
avr.
mars
févr.
janv.
2020
déc.
nov.
oct.
sept.
août
juil.
juin
mai
avr.
mars
févr.
janv.
2019
déc.
nov.
oct.
sept.
août
juil.
juin
mai
avr.
mars
févr.
janv.
2018
déc.
nov.
oct.
sept.
août
juil.
juin
mai
avr.
mars
févr.
janv.
2017
déc.
nov.
oct.
sept.
juil.
juin
mai
avr.
mars
févr.
janv.
2016
déc.
nov.
oct.
sept.
août
juil.
juin
mai
avr.
mars
févr.
janv.
2015
déc.
nov.
oct.
sept.
août
juil.
juin
mai
avr.
mars
févr.
janv.
2014
déc.
nov.
oct.
sept.
août
juil.
juin
avr.
mars
févr.
janv.
2013
déc.
nov.
oct.
août
juin
mai
avr.
mars
févr.
janv.
2012
déc.
sept.
août
juin
mai
avr.
mars
févr.
janv.
2011
déc.
nov.
oct.
sept.
août
juil.
juin
mai
avr.
mars
févr.
2010
nov.
oct.
sept.
août
juil.
mai
avr.
mars
2009
nov.
oct.
août
juil.
juin
mars
2008
déc.
nov.
oct.
août
juil.
mai
févr.
2007
nov.
oct.
sept.
juil.
juin
mai
Feed
Follow @google
Follow
Give us feedback in our
Product Forums
.
Aucun commentaire :
Enregistrer un commentaire