Welcome to Episode 3 of the Learn AWS series. The purpose behind this series is to build skills and confidence in using the AWS platform, by finding, testing and sharing the best learning resources that teach specific AWS services AS WELL AS the various foundational technologies they depend on. In short: Instead of writing a tutorial that just scratches the surface, we assemble together a learning path of great existing resources to help you towards mastery.
You can learn more about the series here: https://dev.to/gregfullard/learn-aws-with-me-episode-1-introduction-mph
Episode 3 focuses on AWS Certificate Manager. Let's get into it..
A number of AWS services allow/require you to configure details of an SSL/TLS certificate. Instead of uploading cert files directly, these services reference the centralised store of certs managed under ACM. The services that reference ACM include CloudFront, Elastic Load Balancing, API Gateway and others (The full list can be found here: https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html)
ACM makes it possible to import your existing TLS certificates for use on the AWS platform, but it also provides a simple process for creating new certificates. When creating certificates with ACM, it is important to realise that ACM is not a general certificate service like "Let's Encrypt" (or many of the for-profit alternatives). Instead, certificates created on ACM can only be used on integrated AWS services.
Before getting into the nuts and bolts of ACM, it is important to have a baseline knowledge of TLS. This article by @GeekflareHQ provides a comprehensive, but beginner-friendly introduction: SSL/TLS 101 for Beginners https://geekflare.com/tls-101/
A critical aspect to understand about TLS certificates is the different levels of validation that they provide. The levels are: Domain Validation, Organization Validation and Extended Validation. This page from the SSL Store gives a nice summary: https://www.thesslstore.com/new-to-ssl/ssl-authentication-levels.aspx
Certificates issued by ACM are Domain Validation Certificates
Assuming you already have an AWS account created, the best/fastest place to start your ACM journey is by issuing a new certificate for one of the domains you control. The AWS user guide probably offers the best step-by-step instructions: https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html
There are two possible approaches to validate your domain: Email-based, or DNS-based. Depending on your situation you should pick the easiest one for you. In my case, DNS was the way the go. I issued a number of certificates for domains from multiple providers and I can confirm that the exact process varies quite a bit between different providers.
You can also easily import existing TLS certificates into ACM. To test this out, I used the https://zerossl.com website to generate a cert, which I could then import and use on ACM. Take note: if you import your own certs, you will have to take responsibility for managing expiry and replacement, while ACM-issued certs are automatically renewed.
When working with ACM, it is essential to understand a number of core concepts:
- PKI (Public Key Infrastructure)
- Certificate Authority
- Certificate Signing Request
The AWS ACM User Guide includes a handy reference page the lists (and describes) key concepts related to ACM. Definitely worth a few minutes of your time: https://docs.aws.amazon.com/acm/latest/userguide/acm-concepts.html
No technology lives in isolation, and ACM is no different. Although you can begin your learning journey by jumping straight into ACM, becoming a true master will require skills and experience in the prerequisite, complementary and alternative technologies. The following Skills Tetris diagram gives a simple overview of the skills neighbourhood that ACM lives in.
Once you've worked through the resources above, you should be quite comfortable creating and importing ACM certs via the AWS console. But in real life, you may also need to interact with ACM via the AWS CLI or one of the available SDKs. I like the Boto3 (Python) SDK quite a lot, so the two resources I used often were:
- Different DNS providers have very different interfaces for specifying CNAME records, which caused some confusion for me. Also, they replicate those records are different rates. Neither of these were major issues though.
- I did notice that ACM also provides the ability to define a private CA, which would be used when an enterprise needs to issue internal certs. I did not use this functionality at all.
This blog article covered the most important aspects that I came across during the weekly Twitter thread, but if you're interested, you can check out the original thread here: https://twitter.com/devskilldojo/status/1333094917732757506
Next up (Episode 4) is Route 53, you can follow along with episode 4 on this Twitter thread: https://twitter.com/devskilldojo/status/1335841066210250752