If you have been in IT for the last few years, no doubt you will have heard of Let's Encrypt, an open certificate authority. Its goal is simple: Ensure the internet is no longer transmitted in plaintext. To that end it issues digital certificates for free. The service is completely automated in the right circumstances, and you can be quite creative about what other automation technologies you can link it with.
In fact, Let’s Encrypt is fully automated in most instances. This is certainly so on Linux; when paired with Apache or NGINX it will take care of the whole process of requesting, validating and installing a certificate for you. Even on Windows, with some Let's Encrypt tools it will take care of the whole process for you.
However, if you are not running a web server and cannot use an HTML validation method (a file stored on your web server that the Let's Encrypt service looks for), you have to use a DNS challenge. If you have requested any certificate in the past, chances are you had to set up a DNS challenge response where your certificate authority says, “Create this DNS record with this value to prove you own the domain.” As you'll see, this can create a challenge for automation.
On Windows, of course, PowerShell is the automation tool of choice. There is a Let’s Encrypt module, Posh-ACME, you can install from the PowerShell gallery and request certificates using PowerShell commands.
You'll see that to validate domain ownership you need to complete a DNS challenge as mentioned earlier.
DNS challenge request
That is fair enough, and indeed easy enough, but to automate that, you need to be using a DNS service that has an API. Not all of them do.
The DNS host I use for this example does not. However, it is easy to work around this issue, and Posh-ACME has support for several DNS hosts and different validation methods. I prefer using the DNS challenge alias method as it means I can host a special DNS zone just for DNS challenges, and that can be separate from the domain I want to issue a certificate for.
Amazon Web Services (AWS) has such a DNS service called Route 53. If you don’t have an AWS account, then you should sign up and start exploring its cloud services. From the AWS dashboard, find “Networking and Content Delivery.” Select “Route 53.” On the Route 53 dashboard, click “Hosted Zones.”
Select Route 53 from the AWS dashboard
Create a new Hosted Zone. This zone will be used to create DNS challenges.
Create a new hosted zone
I wanted to keep things relatively organized, so I created a subdomain of my main domain name, which had the benefit of not needing to pay to register a new domain.
Hosted domain to be used for DNS challenges
Once you have created your zone, you will see the record sets inside it. The NS record set is important, as you need to publish this in your main DNS zone.
At your main DNS host, you will need to add the four NS records from your AWS hosted zone. This tells the public internet that any query for your new subdomain should go to the AWS Route 53 servers and has no effect on the rest of your existing DNS zone.
Name servers
While at your existing DNS zone, add two records. One is for the device you will be securing with a certificate (an A record, which you may already have) and the other is the cname record you will use for the DNS challenge.
Cname for DNS challenge
In the AWS dashboard, go to “Security Identity and Compliance.” Go to “IAM.” From the dashboard go to “Policies.” Create a new policy and select “JSON.”
Paste the following policy code, as shared here.
Paste the IAM policy code
Click “Review Policy,” enter a name and click on “Create Policy.”
The last thing to do is create an IAM user in AWS. From the dashboard go to “Users” and add a new user. Enter a unique name and select “Programmatic Access.”
Create an IAM user
On the permissions page you can chose to attach an existing policy, which is the policy you created in the previous step.
Attach a user policy
On the next page you can optionally add tags, which help identify services for billing, and on the next page you can review the settings. Click on “Create user” to complete the process.
You will then be shown the access key ID and secret access key, you need to record these as you will not be able to retrieve the secret access key again.
Access key ID and secret access key
Once you have these credentials you can use them with the Posh-ACME module to generate certificates using Route53 to handle you DNS Challenges. If you haven’t used Posh-ACME before you will need to run “New-PAAccount” to setup an account to issue certificates. You will also need the AWS PowerShell module installed.
You can see the DNS challenge record published in your Route53 zone. It will be removed once validation is completed.
In this example, the $domain is the common name of the certificate you want to issue—i.e., the internet address you use to access the service or device. The $challengeDomain is the name of the record that LE queries for validation of the certificate request. You have told the New-PACertificate command you are using the DNS plugin Route53 and a DNS alias. The command knows that when it receives the DNS challenge back from LE, it should connect to Route53 to create the record $challengeDomain with the value supplied by LE.
Challenge code in Posh-ACME
You now have a certificate for your device or service and the validation process was automated for you.
Issued certificate
You can check the Posh-ACME folder on your computer to see you have all the files related to the certificate you need, including a PFX file, which is useful for Internet Information Services (IIS), and the cert.key and cert.cer files, which are useful for Linux-based systems.
Cert files
If you’ve followed the steps outlined here, you can then configure Azure Automation to handle the creation, validation and installation of a certificate on a firewall. This article shows what you need to do.