top of page

Managing SSL Certificates with AWS Certificate Manager(ACM)

Updated: Oct 9, 2024

Managing SSL Certificates With AWS ACM

Every compute platform, be it virtualised or containerised, requires an endpoint that can expose the applications or services running on it to the internet or intranet. 


The legacy approach of achieving this has been, assigning a public/elastic ip to the server instances. This has major security implications since threats on the internet are growing and exposing servers directly to the internet puts them in the frontline of such threats. Not to mention this option does not work when there is a cluster of such instances such as an EKS cluster. 


How to secure Application Load Balancer(ALB)s with AWS Certificate Manager(ACM) certificates.


Today’s modern infrastructure requires one endpoint that can securely interface, balance and share load of multiple instances hosting the same application. One such and most commonly used endpoint solution is “Application Load Balancers” a.k.a the ALB


AWS ALBs are layer7 load balancers which provide special features such as http/https path based routing, very useful for multi tenant applications. An ALB receives traffic at a certain port/protocol and then forwards it to a target group of either instances or ips. 


In the case of EKS, services can either be directly assigned to such a target group of an existing ALB (Target Group Binding) or you can create an ALB by deploying an ingress resource of type load balancer (Ingress ALB). 


AWS ALBs can accept traffic on either HTTP or HTTPS ports/protocol. And we all know for security reasons, it's always recommended to expose internet facing applications or services on HTTPS with a valid SSL certificate.


A major advantage of using certificates on the ALB with SSL/HTTPS for applications is that you can do SSL offloading on the load balancer which then becomes a central place for certificates management like renewal etc. 

Otherwise, without SSL offloading ALB, certificates will have to be managed on each instance and that becomes quite a challenge especially when you have hundreds of them to update. It can also bring your business down for more than a day. 


Valid SSL certificates are those that have been verified by a known certificate authority that authenticates the website owner's identity and establishes a secure communication channel between the server and the client. In other words, one that can be recognised as valid by most browsers or other client devices.


Certificate management can become a big hassle if not done correctly. Especially when you try to self manage it with a cert-manager or used self signed certificate it can become quite a management task to keep track of renewals or expiry dates which can impact your business heavily if not done in a timely manner. So it's recommended to purchase a certificate from the same domain registrar.  


Even better is to use a certificate management service, if available with the cloud provider. That way it can all be managed under one single provider. 


AWS provides “AWS Certificate Manager” a.k.a ACM for public and private certificates. This solution guide will focus specifically on public certificates and its usage with AWS Application Load Balancer.


ACM creates valid public signed certificates either for a new domain registered under AWS or for an externally hosted domain with some other registrar like bigrock or go-dady. And, it can be easily provisioned with Infrastructure As Code (as described in the deployment guide).


One other advantage of AWS ACM is that Public SSL/TLS certificates provisioned through AWS Certificate Manager are free (https://aws.amazon.com/certificate-manager/pricing/). 


So you can either create a wild card certificate like *.mydomain.com for your entire organization or create a specific one for applications like myapp1.mydomain.com.


ACM does certificate validation in two ways:

  1. DNS Validation

  2. EMAIL Validation

I chose option 1, because it could be automated(except for the name server update part) plus it did not need anything other than a registered domain which was cost effective.


For option two, you need an additional resource that is an email registered under the domain name and in this situation, the terraform resource is simply a waiter for manual email approval of ACM. 


Here are some pre-requisites needed to create valid public certificate with ACM using DNS validation:


  1. Purchase a domain name such as mydomain.com either with AWS or external registrar like godaddy, namecheap, bigrock etc.

  2. Create a public hosted zone of the same domain name as your registered domain. 

  3. Copy the name servers from the Route53 hosted zone and update them under the external registrar domain nameservers. In case your domain is registered under AWS, you can skip this step.

  4. Test dns resolution for the domain name with nslookup or dig. It must show the same servers as created under Route53. The dns replication usually happens within a few seconds, but sometimes it can take up to 48 hours to replicate worldwide.

  5. Once this is done, proceed with the ACM public certificate creation. 



The first 3 steps above are important for the ACM certificate validation process. 

For, instance, if you are creating a SSL certificate for the domain name www.example.com or *.example.com, ACM will need to validate the domain’s name server over the internet through dns resolution for the same. If it cannot resolve the domain name the certificate validation will fail. So before you start creating the certificate on ACM , make sure your domain name can resolve over the internet. You can test it by running the following:


$ nslookup www.example.com or 


Remember, for domains registered outside AWS,  if you have not updated the nameservers for your external domain with AWS’s host zone nameservers, ACM would not be able to reach them for certificate validation. And that's why we need to update our domain with AWS’s zone name servers , since then ACM can successfully do the lookup and create the valid certificate. So it is necessary  that you have one of the following configured.


  • Domain is registered(purchased) with AWS Route53 

  • For existing domains registered with other providers (ex: godaddy, namecheap, bigrock etc), update the nameservers in your provider’s portal with ones created under AWS hosted zone with the same domain name.


Steps 1-4 are manual as this requires domain registration from the console both in case of AWS or other registrars.

Once it's done, certificates can be created in the ACM either from the console or using Infrastructure-As-Code(IaC). Once you have created the ACM certificate, you can copy and use the ARN while deploying the ALB listener. 


Point to be noted: The certificate arn is a required parameter for creating an ALB listener with port/protocol 443/HTTPS with SSL policy. So ACM certificates must be created before the ALB.


The deployment guide contains steps on how to do it using the terraform modules packed in this product. 


Summary:

  • To securely interface, balance and share load of multiple instances hosting the same application, ALBs with HTTPs.

  • ALBs must be enabled SSL policy and valid certificates so that SSL offloading can be handled efficiently in one place. 

  • Always use valid public signed certificates. 

  • When you are on AWS, ACM is the most suitable option available for a secure and scalable certificate management for services as well as for other platforms that require/recommend SSL certificates.


If you like this article, I am sure you will find the 10-Factor Infrastructure even more useful. It compiles all these tried and tested methodologies, design patterns & best practices into a complete framework for building secure, scalable and resilient modern infrastructure.


 

Don’t let your best-selling product suffer due to an unscalable, vulnerable & inconsistent infrastructure.



 


Thanks & Regards

Kamalika Majumder

11 views0 comments

Recent Posts

See All

Comentários


Join the 10factorinfra Club

Learn about secure, scalable & sustainable modern infrastructure development & delivery.

Thank You for Subscribing!

©2024 by Staxa LLP. All Rights Reserved.

bottom of page