[MUSIC PLAYING]
ANOOSH SABOORI: Welcome to the Google Cloud Security Showcase,
a special web series where we'll focus on security use cases
that customers can solve with Google Cloud.
My name is Anoosh.
And I am a product manager at Google Cloud.
Today, we'll be walking through one of the top questions we
get from customers--
how can I simplify the management of privacy
certificate authorities?
Digital certificates underpin identity and authentication
for many networked devices and services.
Recently, we have seen increased interest in using certificates
in DevOps and device management, particularly for IoT devices.
But one of the most fundamental problems with certificates
remains.
It's hard to set up certificate authorities
that issue certificates, and even harder
to do it reliably at scale.
To help, we introduced Certificate Authority Service
from Google Cloud, which is a highly scalable and available
service that simplifies and automates the management
and deployment of private CAs while meeting the needs
of modern developers and applications.
Let's take a look on how easy it is
to set up a private CA with Certificate Authority Service.
From the console, go to Security, then
Certificate Authority Service.
If you haven't yet, enable the API now.
Create a new CA.
Here you can choose to create a root or a subordinate CA.
For a subordinate CA, you can choose
to have the root CA hosted outside GC.
This is great if you want to continue using an existing root
CA, perhaps hosted on-prem.
Let's choose Root CA.
You can further customize how long this CA certificate
is valid for.
Let's keep the default at 10 years.
We support two tiers for CAs optimized for different use
cases.
DevOps tier is best for high-volume usage patterns
where certificates are short-lived.
For example, microservices certificates
issued every 12 hours.
In this mode, we don't support revocation,
as certificates are relatively short-lived
and will expire as quickly.
Enterprise tier provides revocation support
and is more suitable for low-volume and longer-lived
certificates.
In both cases, you still benefit from HSM
for protecting CAs private keys.
Let's pick Enterprise tier for the root.
Note that we can configure different CAs in the chain
differently.
Meaning that a root can be Enterprise tier,
whereas as a subordinate CA can be a DevOps tier.
Next choose a region.
At GA will support all regions that Cloud HSM supports today.
You can also see below that we have
some premade recommended templates
to help you save time in CA creation.
Next, configure the new CA, filling out
the necessary fields.
Specifically, organization name and a common name.
Google Cloud Security.
The idea is a unique identifier for this resource inside Google
Cloud, and it will be used by other services.
Now, we need the key for CA.
You can customize a key algorithm and size here.
Let's pick an RSA for key.
Note that all these keys, it will
be generated using Cloud HSM.
You can also use an existing Cloud KMS key for CA service
by picking Customer Managed Key.
Now, on to revocation, for when we
need to tell clients to no longer trust certificates.
We use certificate revocation list, or CRL,
to communicate this.
By default, certificate revocation lists are enabled.
We automatically create a GCS Bucket for you.
You can also use your existing GCS Bucket
that you created before.
Below you can also decide to enable authority information
access, or AIA, extension.
That enables chain validation code on the recipient device
to navigate the full certificate chain to DevOps.
Next, you can add a label to enable easy grouping
of your Cloud resources.
Go on Final Review to finalize the details before you create.
If it all looks good, then let's run with it.
You'll now see the newly-created CA under the CA Manager tab.
Great.
We've got our CA set up.
Let's request a certificate.
Choose the CA you want to use and click Request Certificate.
There are two ways you can request a certificate.
One, is to provide a certificate signing request, or CSR.
In this case, you will need to use an existing tool,
like OpenSSL, to create a private-public key pair.
And then generate CSR before visiting this page.
Alternatively, you can have the CA service
generate both the private-public key pair and the certificate
for you.
Let's try this.
Certificate name uniquely identifies the certificate
as a resource in the Cloud.
We don't need to change that.
Let's pick a domain name--
foo.com Pick the Server TLS as the extended key usage.
Here you can customize what signing algorithm to use.
Let's pick the default.
Now you can download the private key and certificate
and use it in your application, as simple as that.
You can see all certificates issued by your CA
under Issued Certificates tab.
Click on the dots to download the new certificate
or for inspection or use, including revocation.
Congratulations.
You have created a new CA and got a new certificate
in minutes.
Much faster than days or weeks it used to take to host it
yourself.
Thank you for watching.
Please visit cloud.google.com/security
to learn more.