From Days to Seconds: Automating AWS Certificate Requests with n8n and Slack

Developers asking for AWS certificates are like teenagers asking for car keys – there’s a lot of waiting around, paperwork, and crossed fingers. If you’re tired of playing certificate gatekeeper or being the developer stuck in ticket purgatory.

Let’s turn that mind-numbing certificate request process into a simple Slack command using n8n, an intuitive workflow automation tool that will have your developers saying, “That’s it?”

We’ll cover an example scenario from A to Z, not skimping on the details, to show you how the n8n workflow automation tool can save busy developers and managers countless hours of overtime.

The Current Certificate Request Dance

Picture this all-too-familiar scenario: A developer needs a new AWS certificate for their dev environment. Here’s how it typically goes:

1. Developer submits a ticket with enough text to write a novel
2. Ticket sits in the queue while developer stress-refreshes their inbox
3. Approver finally sees the ticket between 47 other urgent requests
4. Half the required info is missing (obviously)
5. Back-and-forth emails ensue like a painful game of ping-pong
6. Approver logs into the AWS console (after finding their 2FA device)
7. Manual certificate creation happens
8. Developer finally gets certificate details… maybe
9. Everyone loses a little bit of their soul

Sound familiar? I thought so. Let’s fix this.

The Dream: Slack Command → Instant Certificate

What if your developers could just type /newcert in their dev environment’s Slack channel, get an AWS certificate ARN back in seconds? No tickets, no waiting, no soul-crushing back-and-forth. That’s precisely what we’re building.

In this scenario, you’re a developer in an organization that uses Slack for communication. You’ve created a Slack channel for each development environment to keep conversations organized.

Here’s how our automated workflow will work:

1. Developer types /newcert in their environment’s Slack channel
2. The n8n workflow receives the request with channel context
3. The workflow creates certificate in AWS
4. Certificate ARN appears in the same Slack channel

That’s it. Four steps instead of nine, and zero waiting around for humans to do human things!

Since we’re not skimping on the details, this post will not just tell you that n8n can automate this process, but I’ll show you (I did it myself from scratch!).

n8n uses workflows to tie together tasks using nodes. These workflows can then be executed, triggering all nodes inside the workflow to automate simple to complex processes.

If you’re interested in learning how to set up this workflow or in learning how an n8n workflow could be set up, read on!

First Things First: The Webhook Trigger

Open your n8n instance, and let’s start with a blank canvas:

1. Create a new workflow. Below, you’ll see the blank canvas of a new n8n workflow ready to set up the first trigger node.

2. Next, add a webhook trigger node. The webhook trigger note is how Slack will communicate with this workflow to notify the workflow when to issue requests to AWS to create new certificates.

You can see from the screenshot above that the webhook trigger node will be listening for POST HTTP requests.

3. Configure it to receive POST requests from Slack

This webhook will be our front door – it’s where Slack will knock when someone uses our /newcert command.

Creating the Slack App

Time to set up the Slack side of things. You’ll need a Slack app to allow users to issue slash commands (/newcert) in the channel. The Slack app will also act as a way for n8n to authenticate back to Slack to return messages.

1. Once on the Slack apps screen, click on Create New App where you can provide a name.

2. Next, set the Scopes to be able to issue slash commands and to also send messages back to the channel. You’ll need

– channels:read

– chat:write

– commands

3. Next, set up a slash command. A slash command allows users to issue commands to your Slack app as a forward slash followed by some command. In this case, the command will be /newcert to generate a new AWS certificate.

In your app’s settings, go to “Slash Commands” and click “Create New Command”

4. Install the app into your workspace Once you’ve set up the scopes and slash command.

5. Finally, invite the bot (the application you just created) to a Slack channel to work in. In this case, the channel will be the name of the dev environment qa-1.

/invite @devenvironmentautomation

Testing the Webhook Trigger

You now have the Slack app and webhook trigger configured. It’s time to test their interactivity.

1. In your n8n workflow, click the Listen for Test Event button. Doing so will allow the webhook trigger to start listening for requests the Slack app should send.

2. Next, in your dev environment Slack channel, issue the slash command /newcert. Once you do, you should see the webhook node receiving the request in n8n.

Notice below it includes the channel name and user id in the request. This will allow us to see what dev environment this certificate is for and the user requesting it.

If all went well, you should see the default JSON response telling you that the workflow received the request that started the workflow.

Setting up AWS Access

n8n needs to authenticate to AWS to create new certificates. To do that, an IAM user with the appropriate rights is needed. Since we’re starting from scratch in this tutorial, below, you’ll find a way to quickly set up this IAM user via the AWS CLI.

If you don’t already have an IAM user, you can use the following code to do so:

## create the policy file
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "acm:DescribeCertificate",
                "acm:ListCertificates",
                "acm:GetCertificate",
								"acm:RequestCertificate"
								"acm:AddTagsToCertificate"
            ],
            "Resource": "*"
        }
    ]
}

## crate the user
aws iam create-user --user-name CertificateManager

## create the acceess key id and secret access key
aws iam create-access-key --user-name CertificateManager --query 'AccessKey.[AccessKeyId,SecretAccessKey]' --output text > certificate_manager_credentials.txt

## create the policy
$policy = Get-Content -Raw ~/Downloads/cert-policy.json                                                           PS /Users/adam> $policy_arn = aws iam create-policy --policy-name CertificateManagerPolicy --policy-document $policy --query 'Policy.Arn' --output text

## attach the policy

aws iam attach-user-policy --user-name CertificateManager --policy-arn $policy_arn

## read the access key id and secret we'll need later for the workflow
Get-Content ./certificate_manager_credentials.txt

This code uses the AWS CLI to perform various tasks:

1. Policy Creation: Creates an IAM policy that defines exactly what certificate-related actions are allowed:

– Viewing certificate details

– Listing certificates

– Retrieving certificate data

– Creating new certificates

– Adding tags to certificates

2. User Creation: Creates a dedicated IAM user named “CertificateManager” that will be explicitly used for certificate management tasks

3. Access Key Generation: Creates an access key pair (Access Key ID and Secret Access Key) for the new user and saves them to a file

4. Policy Attachment: Creates the IAM policy and attaches it to the new user, granting them only the specific certificate management permissions defined in the policy

5. Uses the PowerShell Get-Content command to read the text file with the access key and secret you’ll need to provide to the workflow.

This follows security best practices by:

• Using the principle of least privilege (only granting necessary permissions)

• Creating a dedicated user for certificate management

• Separating the credentials from the admin account

Note: In a production environment, you’d want to store the generated credentials securely, not in a plain text file. Consider using AWS Secrets Manager or another secure secrets storage solution.

Setting up the n8n Workflow AWS Credential

When we get to that step, the workflow must be able to authenticate to AWS Certificate Manager to issue new certificates. n8n uses credentials to do that. To create a new credential for AWS:

1. In your workspace, click on Credentials at the top of your screen and click Add credential.

2. Specify AWS as the credential type.

3. Provide the access and secret access keys generated from the AWS CLI commands earlier.

n8n has a nice feature that automatically tests the credential when you save it so you’ll know immediately if the credential works or not.

Creating the HTTP Request Node

Although n8n does have support for the AWS Certificate Manager service, it currently does not support creating new certificates, so you’re not out of luck! You can use the generic HTTP Request node. This node allows you to issue generic HTTP requests to API operations that are currently not supported.

1. To create the HTTP Request node we’re after, first, define all of the parameters that the AWS API requires. Those are:

– URL – The API endpoint to the region you’re working in

– Authentication – Use Predefined Credential Type to leverage the credential previously created.

– Credential Type – AWS

– AWS – The AWS credential previously created.

– Send Headers – You’ll need the X-Amz-Target header to tell the API which operation you’d like to use; that’s CertificateManager.RequestCertificate in this case.

– Body Content Type – application/x-amz-json-1.1

2. Next, set up the HTTP body. This is a crucial step in making an API request with the dev environment name. In this scenario, we’re assigning an AWS tag called Environment to the certificate and setting the value of the environment name received from the Slack request.

You’ll need a dynamic input or Expression for this task. Click on Expression in the Body field, and you’ll see the input turns into a function text.

3. Click on the expand-out icon in the lower right corner of the body field, and you’ll get an intuitive editor.

The HTTP body needs to be in JSON. I’m using one of my domain names here and validating the certificate with DNS.

You can see below I can include the tag value by dragging the value received from Slack into the expression.

    {
        "DomainName": "atademos.com",
        "ValidationMethod": "DNS",
        "Tags": [
            {
                "Key": "Environment",
                "Value": "{{ $('Webhook').item.json.body.channel_name }}"
    }
    ]}

The value is now {{ $('Webhook').item.json.body.channel_name }} This variable will be passed to AWS in the API request containing the Slack channel name (the dev environment name in this scenario).

4. Finally, test the HTTP request node by clicking on Test step. If all went well, you should see the JSON response from AWS, including the certificate ARN

Create the Slack Node

At this point, you have two of the three nodes complete in this simple n8n workflow: the webhook trigger for Slack to call and the HTTP Request node that will make API requests to AWS. The final node is the Slack node, which initiates a response message to the user.

1. Open the Nodes panel and click the plus button to create a new Slack node in your workflow.

2. Search for Slack and choose the Send a message action.

3. Next, click on Credential to connect with and choose Create a New Credential to create a Slack credential similar to the AWS Credential. Once you’ve set up a credential, you can use it in the Slack node.

4. Provide the appropriate parameters to the Slack node:

• Resource – Message (to send a channel message)
• Operation – Send
• Send Message To – Channel
• Channel – By Name. You can use the expression editor again and drag the channel_name attribute from the webhook trigger to use a dynamic expression.
• Message Text – In this scenario, the workflow will return the certificate ARN received from AWS to the developer in the Slack channel. Since AWS returns a JSON string, we can use the built expression function JSON.parse to parse the JSON to just pull out the CertificateArn value.

 The ability to run simple JavaScript like JSON.parse directly in expressions is extremely handy. If I didn’t have this ability, I’d have to create a whole new node just to format this simple data. 

5. Click on Test step and the originating Slack channel should get the message!

Test The Workflow

At this point, you should have a workflow with three nodes. It’s time to test the entire workflow together!

Clicking on Test Workflow, you’ll see that n8n begins to wait for the trigger.

Go into the dev environment Slack channel and issue the /newcert command. Voila, the workflow should execute seamlessly!

You should now have a certificate tagged explicitly for the dev environment it will be used in, a history of the request, and a lot happier developers, for instance, access to new certificates!

Why This Matters

Think about what we just built:

• Eliminated the ticket system middleman

• Reduced certificate request time from days to seconds

• Automated documentation (AWS tags)

• Made developers happier (priceless)

This blog post covered only one task: building the workflow. It can now be executed unlimited times to save countless hours!

And the best part? This is just the beginning. You could extend this workflow to handle different certificate types, add approvals for prod environments, or even automate certificate renewal notifications.

Check out Pre-Built Templates

n8n provides hundreds of pre-built templates like this workflow. These templates allow you to shortcut the process we covered to leverage workflows built and tested by n8n.

Final Thoughts

n8n makes it ridiculously easy to automate these kinds of workflows. We took a process that usually involves multiple systems, people, and patience levels and turned it into a single Slack command.

Want to try this yourself? The basic n8n version is free, and you can probably set this up faster than processing a single certificate request the old way. Your developers will thank you, and you’ll have one less administrative headache.