Securing Your Online Presence: Unraveling the Relationship Between DNS and Certificate Management

DNS and Certificate Management Feature Image

In the digital landscape, maintaining a secure and reliable online presence is paramount. Two key components that play a vital role in achieving this are DNS (Domain Name System) and certificate management. Understanding how these elements work is crucial for safeguarding the safety and integrity of your online activities. While they operate independently, they also intertwine as essential security gateways into your domain. In this article, we will explore the intricate relationship between DNS and certificate management, shedding light on their individual significance and their collaborative role in fortifying your online presence. By gaining a comprehensive understanding of these components, you’ll be better equipped to establish a robust and resilient digital foundation. Let’s delve into the world of DNS and certificate management and unlock the secrets to a secure online journey.

Before you start

About this post:

  • 5 – 10 min average reading time
  • Suitable for intermediate through to advanced

What you will gain reading this post:

  • An overview of the DNS and Certificate Management
  • A guide on choosing the best approach to support your solution

What you can do to help support:

  • Like, comment and share this article
  • Follow this blog to receive notifications of new postings

Now, let’s get started.

Overview

This solution is to provide a way to delivery solutions to the market in a quicker and easier manner.

  • Automate DNS and Certificate management
  • Enable teams to support the end to end solution and devops practises

Problem Statement 

This solution is focused on three separate problems.

  • DNS
  • Certificate Management
  • Process

While they can be resolved independently, they are often interconnected and by solving for both of these together it will allow for a more robust and complete solution, while opening up a path for teams to better automate their solutions and therefore improve the ability to deliver.

DNS

  • Does not support AWS services dynamic naming
    • When using ECS the ELB get created with a dynamic name, this means every time the stack is recreated the ELB name changes, resulting in the DNS entry needs to be updated manually each time

Certificate Management

  • Risk of regression causing a production outage
  • Private certificate authority
    • They generally are centrally managed and require other teams to action on your behalf
    • Require manual updates in automated environments during lifecycle management, creating CERTAGEDDON

Process

  • Many teams need to be engaged
  • Lack of automation support

Solution 

This solution captures the DNS and Certificate management for ingress and egress traffic for domains flowing from a centralised account into a cloud account.

High Level – Multi Account – Overview

Naming Strategy

Internal – <api>.<subdomain>.<centraldomain>.<cloud>.example.com

External – <api>.<subdomain>.<centraldomain>.example.com

Key Attributes

api – identifier of the api that is registered in the API gateway

subdomain – the domain registered in the authoritative DNS service of the cloud account the team owns and manages

centraldomain – the domain registered in the authoritative DNS service of the cloud central DNS account the centralised team owns and manages

cloud – the cloud provider the cloud accounts team workload resides in, e.g. aws, gcp or azure, useful for multi cloud enterprises running many workloads.

Zoning

Cloud – Account – Authoritative DNS service: for both public and private domains they should be registered in the Public Hosted Zone, however private domains should NOT be publicly resolvable but have a TXT record registered in the public hosted zone for domain ownership verification purposes.

Refer to Example below for further clarification.

Cloud – Central DNS Account – Authoritative DNS service: for both public and private domains, this is the authoritative service for the centralised domain, E.G. <centraldomain>.<cloud>.example.com and/or <centraldomain>.example.com

Certificate Management

Lifecycle Management

Issuing / Revoking / Renewing / Supporting

Deployment

Detailed – Multi Account – Overview

NOTE: This solution is dependant on the use of AWS PrivateLink, if you do not use AWS PrivateLink this solution will not be suitable, and it is recommended to look into alternative products capabilities to meet your requirements.

Also worth noting if AWS has a more feature rich product, then this could become an option in the future even without AWS PrivateLink – https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-vs-rest.html

Deployment diagram description

  1. Create a public hosted zone in the tenants account in Route 53
  2. Create the Gateway Load Balancer (GLB) for the PrivateLink to connect.
  3. Application Load Balancer (ALB) for scaling up/down. It uses path-based routing to target groups within the service mesh to direct traffic to the correct application.
  4. Gateway Load Balancer (GLB) is exposed as an endpoint service so that it can be consumed from other VPCs.
  5. A public zone / public subdomain are required so that when the endpoint is registered, this subdomain can be provided. If it is not, then you can only have autogenerated AWS subdomains, which has certificate implications. It needs to be public so that you can can add a TXT record against it to “prove ownership”.
  6. TLS termination occurs at Account’s private ALB.

It is worth noting that at the time of writing this post the AWS API Gateway does not support custom domain names for private API’s – Creating a private API in Amazon API Gateway – Amazon API Gateway.

Process

Recommended steps:

Each of these will be different, depending if you are doing this yourself or as part of an organisation.

  1. Procure new domain
    • A sub domain of .example.com
  2. Request certificate
    • Only to verify a txt record within route 53 (verify ownership)
  3. Central Account to Account domain configuration
    • DNS forwarding
  4. Documentation
    • Key Management Plan

Example

<subdomain>.<centraldomain>.<cloud>.example.com would be registered in the public hosted zone where a certificate would be issued to support the domain as well as any subdomains of <subdomain>.<centraldomain>.<cloud>.example.com, because certificates become expensive.

However the subdomain of <subdomain>.<centraldomain>.<cloud>.example.com in this example api.<subdomain>.<centraldomain>.<cloud>.example.com would belong to a private hosted zone ensuring the private domain is publicly registered for ownership verification but not publicly resolvable.

The end result would look like the following:

nslookup api.subdomain.centraldomain.aws.example.com
Server: 10.1.1.1
Address: 10.1.1.1

Non-authoritative answer:
*** Can’t find api.subdomain.centraldomain.aws.example.com: No answer

Did this help?

  • Like, comment and share this article
  • Follow this blog to receive notifications of new postings
  • View previous postings

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.