This course covers the core learning objective to meet the requirements of the 'Designing Compute solutions in AWS - Level 3' skill
Learning Objectives:
- Evaluate and enforce secure communications when using AWS elastic load balancers using HTTPS/SSL listeners
- Evaluate when to use a serverless architecture compared to Amazon EC2 based upon workload performance optimization
- Evaluate how to implement fully managed container orchestration services to deploy, manage, and scale containerized applications
In this lesson, we will discuss the importance of digital certificates and key features of AWS Certificate Manager. We've all been using digital certificates for decades and most of us probably use digital certificates every day. Whenever we go to a website that uses HTTPS, we're using digital certificates. Digital certificates are also used during the authentication of endpoints taking part in site-to-site VPNs so that a VPN tunnel can be established, during the validation of digital signatures used as part of integrity checks of data at rest and in transit, as part of multi-factor authentication and more.
Fundamentally, digital certificates allow us to trust that the website, service, or user we are communicating with is valid. If we trust that the entity we are communicating with is valid, we can then do things like configure authentication, configure non-repudiation, configure integrity checks, and configure encryption. Digital certificates come embedded with a public key. The certificate is validating the public key, meaning that we can trust the public key and use it to perform tasks such as configuring secure communications with web servers and validating digital certificates. Digital certificates themselves need to be trusted.
If we can't trust digital certificates, then we can't trust the public keys embedded with them and therefore we cannot use those public keys to secure our connections. In order to obtain digital certificates that we can trust, we request digital certificates from trusted certificate authorities. Certificate authorities can be either public or private. Public certificate authorities are already trusted by most operating systems. Public certificate authorities issue certificates to businesses with embedded public keys that can be trusted. Certificates issued by public certificate authorities are generally used on public-facing services such as websites. When requesting a certificate from a public certificate authority, you usually generate a key pair on-prem. You keep your private key secret and then generate a certificate signing request, a CSR. The CSR contains your public key, the DNS names you wish to secure, and your digital signature.
You submit your CSR to your chosen certificate authority and after you validate that you own the domain names in the CSR, a digital certificate will be issued. Public certificate authorities will charge a fee for their services. Private certificate authorities are not automatically trusted by our browsers and operating systems. We configure our browsers and operating systems to trust certificates issued by private certificate authorities by importing the certificate authority's root certificate into the trusted root certificate store of our operating systems. Once we have completed this import, certificates issued by the private certificate authority would be trusted and we can use them to secure connections. We request certificates from private CAs in the same way we do from public CAs by submitting a CSR.
One big difference between public CAs and private CAs is that for private CAs, we deploy the certificate authority infrastructure. We are responsible for securing, backing up, high availability, and day-to-day management of the certificate authority, which might mean managing multiple certificate servers. As you are on the infrastructure, certificates issued by private CAs are free. Certificates issued by private CAs are used internally only, as they will not be trusted by your customers or other services on the Internet. There are lots of challenges when working with digital certificates as well as the challenge of managing your own infrastructure for private CAs. Additional certificate challenges include: Managing certificate requests, renewing and replacing digital certificates that are due to expire, the cost of certificates from public CAs, securing the certificate authority infrastructure, and managing certificate revocation lists (CRLs) for your private CAs.
CRLs are lists of certificates that have been issued by a CA that should no longer be trusted. Each CA is responsible for publishing a list of revoked certificates to a CRL that their customers can access, so that if they come across a certificate on the list, they know not to trust it. AWS Certificate Manager allows us to request SSL/TLS certificates for free from a trusted public certificate authority. These certificates can be used to secure connections with AWS services such as Elastic Load Balancers, Amazon CloudFront, and API Gateway. Certificates issued by AWS Certificate Manager public certificate authorities can only be used with AWS services. Using Certificate Manager, you could also set up a private certificate authority. Once set up, you can use your private certificate authority to issue certificates to secure communications with your applications running on EC2 and your applications running on-premise.
Benefits of AWS Certificate Manager include: Publicly trusted certificates are available for free, there's no need to generate key pairs or issue a CSR, these will be created automatically for you during your certificate request, there's no need to configure certificate authority infrastructure. Even when you create a private CA, it is managed by AWS Certificate Manager. So, AWS are responsible for the high availability, backup and day-to-day management of the servers hosting your CA. One of the best features of AWS Certificate Manager is its ability to alter the new certificates. I have seen many services go down because the certificates they have been using have expired. Using AWS Certificate Manager, that shouldn't happen as it will automatically generate new certificate requests to replace eligible certificates that are expiring and then replace the expiring certificates in the configuration of the services that they are protecting.

Software Development has been my craft for over 2 decades. In recent years, I was introduced to the world of "Infrastructure as Code" and Cloud Computing.
I loved it! -- it re-sparked my interest in staying on the cutting edge of technology.
Colleagues regard me as a mentor and leader in my areas of expertise and also as the person to call when production servers crash and we need the App back online quickly.
My primary skills are:
★ Software Development ( Java, PHP, Python and others )
★ Cloud Computing Design and Implementation
★ DevOps: Continuous Delivery and Integration