- [Presenter] Hello.
Today, we're gonna be talking
about ACM Private CA Certificate Templates.
The learnings in this session will enable you
to secure communication within your internal applications.
This includes workloads such as TLS client/server apps,
mTLS container-to-container workloads,
IoT applications, ADFS for Windows Servers, and much more.
Before we begin in certificate templates,
let's give a brief background on certificates in general
and their properties.
Let's talk about the structure of a certificate.
Certificates have such attributes as the issuer name,
the validity period, the subject name,
public key algorithm, the subject public key,
as well as optional extensions.
Now, all these attributes can be pre-defined
by a PKI operator for end users to create,
and you may wanna restrict, or specify certain attributes
for your organization.
Let's talk about extensions in more detail.
There are a few kind of extensions I wanna talk about
starting with the basic constraints.
The basic constraints indicate
whether the certificate is a CA certificate,
or an end-entity certificate.
The key usage specifies cryptographic operations
that the certificate can perform.
As an example, you may wanna specify
that signatures are allowed, but encipherment is not.
And then we have the extended key usage.
This specifies the purpose of the public key
contained within the certificate.
As an example, you may say that the certificate is
a server end of a TLS connection,
or it may indicate that the key may be used to secure email.
So where do certificate templates come in?
Well, certificate templates enable PKI operators to control
and specify their X.509 certificate extensions.
ACM Private CA uses configuration templates to issue
both CA certificates, as well as end-entity certificates.
When issuing a certificate,
the appropriate template is then applied.
There are many use cases for private certificate templates.
However, the main purpose is to match
the relevant certificate extensions
for the particular use case.
Some use case examples are end-entity certificates
with TLS clients and servers.
There's OCSP signing certificates,
which creates a mechanism to check
if a certificate has been revoked,
and there's code signing certificates,
where developers can digitally sign software
to ensure that it hasn't been modified.
There are many more examples
that templates enable you to build,
but these few show the extensibility
and customization possible through certificate templates.
So we're gonna jump into a demo,
which showcases creating and using certificate templates
for an email use case.
We will begin within the ACM Private CA console.
As you can see here,
we've pre-created two certificate authorities.
The one that's highlighted is
the root certificate authority.
Underneath the root CA,
we have the subordinate certificate authority,
which is highlighted here.
Within the demo, we will be issuing certificates
off of the subordinate CA.
Now, let's move over to Cloud9
to discuss certificate templates.
Now, we are in Cloud9.
We've pre-created a workshop-environment
within this cloud-based IDE,
which we will be running through the demo.
Let's open that now.
Okay.
What we will start by doing is
we will issue a code signing certificate
with a base certificate template.
This means that we have not altered,
or modified the certificate template
with any custom attributes.
Rather, we are using a pre-defined template
that AWS offers.
This script will go ahead,
and it will issue a a code signing cert
from the certificate authority that we just looked at.
The thing I wanna highlight here is
within the issue certificate API call.
As you can see, we are selecting
the subordinate certificate authority
that we just showed you,
and we are using a pre-defined template right here.
This template is a code signing certificate template,
meaning all the attributes are already configured
to be used for code signing purposes.
Let's look at those attributes now.
Okay.
Now, we are on the AWS Documentation page
for ACM Private CA.
As you can see, there are a number
of what we call base templates.
These are pre-configured templates that you can use
to issue common certificate types.
As you can see, the first one listed is what we are using
within this first demonstration,
which is the CodeSigningCertificate.
However, there are many others,
including an EndEntityCertificate,
a client-based end-entity,
as well as a server-based end-entity, and many others.
Let's look at what the CodeSigningCertificate looks like.
Okay, so here it is.
Now, the two areas that I wanna highlight is the key usage
and the extended key usage.
As you can see, this template pre-configures these for you
to be critical, as well as digital signature for key usage,
and critical and code signing for extended key usage.
This means that this certificate can only be used
for code signing purposes.
The rest of these attributes are passed in through the CSR,
the Certificate Signing Request,
which we've created within the code that I'll show you,
as well as from the CA certificate.
Okay, so let's hop back over,
and actually issue this certificate.
Okay, now that we're back in Cloud9,
we will run this script,
which will issue this, the code signing certificate.
Now, this script does a few things,
and it'll take about a minute.
It first and foremost will look
for the certificate authority,
that subordinate CA that we looked at.
Once it finds it, it will issue a certificate
off of that subordinate.
It creates a certificate signing request right here,
and then packages it here, the certificate signing request.
And then finally, it uses this API call
to ACM Private CA called issue certificate,
and it uses that TemplateArn that then we talked about
to then issue the code signing cert.
Okay, it successfully completed.
So let's look at that code signing cert.
Now, we can open it up.
We can open up the PEM file,
and we could see the certificate.
But let's look at the actual attributes within it.
So we'll run this OpenSSL command
to look at the certificate.
As we can see, this is the certificate that we issued.
And as we saw within the code signing template,
the template actually sets the key usage,
as well as the extended key usage to digital signature,
as well as code signing, like we talked about,
and as you can see, that successfully worked.
So from a PKI operator perspective,
you just have to put in that certificate template ARN,
and then you will be outputted with a certificate
that follows the attributes of that template.
In this case, it's code signing.
So what if you need something more custom
that doesn't fit exactly in a pre-defined template?
Well, that's where customizations come in,
and we'll talk about that now.
In this next example,
we need to use the BlankEndEntityCertificate
with API passthrough.
Now, what we're trying to do is we're trying to create
an email certificate that's used for signing,
as well as an email certificate that's used for encryption.
And we're gonna split these out
into two separate certificates,
but keep in mind your application may only need
one email certificate.
We'll begin with the email signing certificate,
which verifies the email's sender's identity
for the recipient.
And we'll see here that the API passthrough will allow you
to actually pass through certificate attributes
that are more custom than a base template provides.
So as an example, you can pass in
the subject alternative name,
the subject with either the API,
or with the certificate signing request,
and we'll show both,
as well as the extensions,
which are now passed in completely custom
to exactly what you need.
Certificate templates have an order of operation.
For each extension value, the template definition has
highest priority, followed by API passthrough values,
followed by CSR passthrough extensions.
This explains why even if you're using a CSR passthrough
the API passthrough takes precedent,
and is still useful in those situations.
Let's hop back over to our workshop,
and let's see this in action.
So like I said, this is the email signing certificate,
and we can see here that we set the subject name.
The subject name is the S/MIME Signing Cert.
This is the protocol
for Secure/Multipurpose Internet Mail Extensions standard.
This is for email certificates.
And if we scroll here,
we see that the subject name is actually being passed in
through the certificate signing request,
'cause if we remember, you can either pass it in
through the API, or you could pass it in through the CSR.
So we actually pass in the subject name through the CSR.
Now, this is to show you the extensibility, right?
You have a lot of options here,
depending on your workflow, and your needs.
Now, if we look at what we pass in
through the issue certificate API call,
we actually pass in the extensions through the API,
so we do a little bit of both.
We do the API passthrough for extensions,
and we do the certificate subject name from the CSR.
As you can see, the extended key usage is set
to email protection.
This means that it can only be used for signing emails,
and the key usage is non-repudiation,
as well as a digital signature.
And then we can also give it a subject alternative name
of the email that it's coming from.
Now, this would be done programmatically within your client.
Okay, let's run this.
Okay, as we can see,
it successfully created the certificate.
So now, let's go over and look at the certificate again
with that OpenSSL command.
Okay.
Now, here is the email signing certificate,
and as you can see, we successfully created the certificate,
but now with those custom key usage
and extended key usage, which is passed in via the API,
as well as a subject name,
which was passed in via the certificate signing request.
Okay.
And here we go.
Now, based on the use of email protection,
we have that in the extended key usage,
as well as non-repudiation in the key usage.
Okay, so now that we've done an email signing,
let's do an email encryption example, which is very similar.
Okay, now let's jump over
to the email encryption certificate,
so this will actually do the encrypting of the email.
As we can see, it's very similar.
So we are still looking
for the certificate authority to use,
and then we are indicating the name attribute,
the subject name to be the S/MIME encryption cert,
because we're encrypting this time, instead of just signing.
And as you can see, we're passing that in with the CSR
to give you the same example of extensibility,
and this could also be done with the API.
It's up to you.
And the key difference here is that we're still using
the extended key usage for email protection,
but the key usage now is key encipherment,
because this is actually encrypting
the contents of the email.
Okay, so let's run this, and create,
and actually do the issuing for that email encryption cert
from the subordinate CA.
So we'll run that here.
I'll just give it a second.
Okay.
As you can see, now we've successfully issued
the encryption certificate.
So let's do the same thing,
and let's look at the contents of the certificate
to make sure that everything worked as expected.
So first and foremost, we can see
we have the subject alternative name still
as an example email address.
We have the extended key usage
to be email protection once again.
But now, we have key encipherment as the key usage,
since this is actually doing the encryption for that email.
This concludes our deep dive on certificate templates.
In this demonstration,
you've learned about the extensibility
of ACM Private CA Certificate Templates,
and how to utilize them to achieve your goals.
For more information on ACM Private CA,
please watch the other videos within this playlist,
or visit the AWS Console to start building for yourself.
Thank you.