🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.
Overview
📖 AWS re:Invent 2025 - Automating Certificate Management with Exportable Public Certificates (SEC322)
In this video, Zach Miller and Praveen Nair from AWS demonstrate automating certificate management using AWS Certificate Manager's exportable public certificates feature. They explain how this feature allows customers to export private keys for public certificates to deploy on non-integrated services like EC2 instances, firewalls, and on-premises servers. The session covers pricing ($15 per FQDN), security considerations including passphrase protection via AWS Secrets Manager, and attribute-based access control using tags. Praveen demonstrates a proof-of-concept solution using Step Functions, Lambda, Systems Manager, and EventBridge for both on-demand and automated certificate renewal workflows. The solution supports cross-account deployments and maintains certificate inventory in DynamoDB. They emphasize the importance of automation as CAB Forum reduces certificate validity periods to 180 days by March and eventually 47 days by 2029. The sample code is available on GitHub in AWS samples.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
Introduction to Automating Certificate Management with Exportable Public Certificates
Good morning, everybody. Actually, good afternoon, I guess. Today we're here to talk about automating certificate management with exportable public certificates. I'm Zach Miller, a principal security SA. I cover our cryptography services. Praveen, would you like to introduce yourself?
Hi everybody. My name is Praveen Nair. I'm a senior security SA at AWS focused on data protection and privacy. I'm hoping everybody can hear me fine. If not, I'm okay to speak up a little bit. I sometimes speak on a lower note, so please let me know if I'm speaking too quietly. Thank you. That's my introduction. I'll pass it back to Zach.
Yeah, so as I said, today we're going to talk about exportable certificates with a service called AWS Certificate Manager. You may be familiar with this launch, but the basic idea is that in the past we had certificates that you could issue from ACM as public certificates, and you could assign or bind those to resources that were integrated with ACM. So you could assign it to an Application Load Balancer, an API Gateway, or CloudFront. Customers said, "I have these use cases where I have a firewall that runs in my data center or runs on EC2 in AWS, and these aren't things that are integrated with ACM. I still want to get public certificates to those devices." That's why we built this new feature where you're able to export the private key of public certificates.
I'll talk a little bit about what that feature is in more detail. We'll go through some of the challenges that we see customers face when it comes to certificate management in general, and in particular with these non-integrated services or devices. We'll discuss how you can handle managed renewal or automated renewal. Praveen has some cool code and a demo that he's going to show, which we built to demonstrate how to automate some of these renewals. We'll talk about public certificates and the challenges with installing them. Many of you are probably already familiar with some of these challenges. We'll go into a deep dive of the architecture and the code, and then Praveen will show a demo of how it works. Feel free to raise your hand and ask questions or interrupt us. That's totally fine. We want to keep it interactive, so if you do have questions throughout, please let us know. We're happy to answer those.
AWS Certificate Manager: Managed Renewal and the New Exportable Public Certificates Feature
So as I mentioned before, we have the service AWS Certificate Manager. It is used to issue both public and private certificates, and it has this nice feature called managed renewal. With things like an Application Load Balancer, about 60 days before the certificate is about to expire, ACM will issue a new certificate. It will bind that certificate to the same resource, say like an ALB or API Gateway, and it'll handle that renewal for you. There are two mechanisms for domain validation: email validation and DNS name validation. We highly recommend you use DNS name validation because it allows you to have a no-touch certificate renewal experience. Email validation is still pretty simple, but you have to click a link in an email. Many times customers will be on vacation, or that person has left the company, or for whatever reason, that email somehow gets missed and that link doesn't get clicked. You could face an outage or something of that nature. We don't want that. So I highly recommend you use DNS name validation because it just means you have to create a DNS CNAME record that basically says, "Yeah, I own this domain."
So what we saw with customers is they said, "I love the managed experience of assigning this certificate to an ALB and having renewal. I don't have to think about certificates. That's great. But I have EC2 instances where I run NGINX and terminate TLS there, and I have maybe a Palo Alto NextGen firewall that I use on-premises, and I need a certificate for that. How do I do that?" They wanted to consolidate down to one certificate provider, so we built this feature called exportable public certificates. Another nice feature of it too is you have the same type of access control you're used to with IAM, of course, and it's integrated with AWS CloudTrail and Amazon CloudWatch, so you get nice observability on how your certificates are used and all the details around rotation and things like that.
When we're talking about the use cases for this, I've called out quite a few of them already, but you might have servers where you're terminating TLS on another cloud provider, and a lot of our customers are multi-cloud. You might have on-premises systems that you want to get these certificates to. Firewalls is a really big use case we hear about, and just other services that aren't integrated with ACM, like EC2 instances, EKS, and containers in general. You want to get public certificates to terminate TLS on those devices, and you need to be able to export the private key.
Pricing Model for Exportable Certificates and Future CAB Forum Changes
If you want to get public certificates to terminate TLS on those devices, you need to be able to export the private key because you need that private key to actually terminate TLS. I'll talk a little bit about pricing too. This has been a driver for customers to reduce their costs because, as some of you know, public services can be pretty expensive. We've priced it very competitively where each FQDN is $15 for each certificate, and you only pay that once when you export the certificate.
When you request a public certificate and assign it to an integrated service like ALB, there's no charge. It's a free certificate. That is still true. You only pay for the certificate when you export it the first time and then never again until it's renewed. It's not like you're paying for it per month or anything like that. You pay for it the first time you export it, and then the next time it's renewed, you'll pay again after you export. So again, $15 per FQDN. If you have one.example.com and 2.example.com, that would be $30.
If you had multiple SANs, that's a good question. Say you had the regular common name and then you had two SANs, that would be three FQDNs, so $45. Is that a one-time fee for the export? Yes, it's a one-time fee for the exports. You can export that as many times as you like after that. Just the one-time fee, and then the next time that certificate is renewed, like the next year, it's technically a new certificate, so you would pay that again. But you can continue to export that certificate as many times as you need.
Is it billed at the time of generation, like if it's flagged as exportable? No, that's a good question. So to repeat the question for everyone: when you create the certificate, if you mark it as exportable, you are only billed the minute you export it. When you call the export certificate API and you get that private key, that's when you'll be billed. So in theory, you can flag everything as exportable, but as long as nobody actually goes in and exports it, you won't be charged.
The only thing I would say is that a bunch of customers, when we talked to them, said they don't want their developers to just export any certificate. So you have to mark it as exportable when you create or request a certificate. If you originally request a certificate and you say this is not exportable, you will never be able to change that. You could reissue a new certificate for the same domain, but you won't be able to change it later. My word of caution there is if you have that use case where some customers view it as a security feature that you cannot export that private key, I wouldn't necessarily advise putting everything exportable unless you have a use case for it.
If I wanted to test the lifecycle by pulling up a certificate and exporting it, but then I don't want the certificate for like a couple of days at the most, I have to basically pay for a whole year, right? Yes, effectively. There's no prorated pricing in that way, unfortunately. There's no way to get a shorter term. However, there are two services. There's AWS Certificate Manager, which issues public certificates and private certificates. There is AWS Private CA, which we're not going to talk about too much in this session, but you can absolutely use short-lived certificate mode for that, and those certificates are priced at a lower price per certificate and they only live up to seven days.
That would be for customers who have a Kubernetes workload where they rebuild their pods every single day. They don't need a certificate that lives a year. They need a certificate that lives a day and they don't want to pay for a certificate for a year. You can do that with private certificates with ACM. At least today, the certificate template is kind of set in stone. It's a 13-month certificate. You can't change that validity period today. I can't say a whole lot more, but we're thinking about other ways to reduce that because, as you may know, the CAB Forum has made some changes where they're going to reduce the certificate lifetime. We will of course adjust our service to deal with that.
What about the pricing? Is it every 30 days? That is also a very good question. I can't say exactly here, but if you talk to me in the hallway after, I can probably give some more detail. Yes, we will be addressing that. There will be a pricing change that will reflect the shorter renewal periods. Because the first drop was like here in March or April, 200 days. Yes, I can't say too much, but if we talk, come find me after in the hallway, we'll talk in more detail. But yes, we are absolutely addressing this.
Yes, we are absolutely planning for those changes, and the pricing will reflect that. Customers should not be paying more based on that.
Security Considerations: HSM Protection and Wildcard Certificate Pricing
Prior to the export of the rack, it's in HSM. Well, yes, so the way that ACM works basically is when you create a certificate in ACM, we generate a private key and we wrap or encrypt that private key with a KMS key in your account. There's a KMS key called the AWS managed key with an alias that says AWS slash ACM. That key is actually used to protect the private key in your account, and that KMS key is protected by FIPS 140-3 level 3 validated HSM.
So it's no longer HSM. That's right. When you export the private key, Praveen will show this, but it is exported encrypted. You basically set a passphrase when you export it, but it will no longer be protected by HSM. It will be exported from the service so it wouldn't be protected by HSM, right? Praveen will get into this a little bit on how we recommend securing those private keys. You're right, once you export that key, that's what I was alluding to earlier with the security consideration. You probably don't want to mark all of your certificates as exportable right away because that does allow application teams to export that private key if they want to. You probably want to make sure there's actually a real use case for that to limit the risk of key compromise.
The only other thing I think I didn't cover is wildcard certificates. Wildcard certificates are priced a little bit differently at $149. If I have SANs attached to that, am I being charged $149 the first time? So if you had three SANs and then the regular common name, that would be four FQDNs, so it would be four times $15, which is $60 per year. No, because with wildcard certificates, there's no charge for the SANs in that way. It's a flat $140. So no, you cannot do that. You could only protect the one subdomain with, so like foo.example.com and bar.example.com, but not foo.bar.example.com. That's right.
Certificate Management Challenges and Solution Architecture Overview
Let me ask, who here deals with certificates daily or at least a lot? Probably everyone's familiar. Does anyone have the experience of creating Outlook calendar reminders to renew your certificates? Yeah, I've been there too. I think that's the obvious example of some of the challenges. You have things I talked about before like if you have manual processes, a human being has to go manually type in that certificate and put it into a key store. It's all this whole manual process, and obviously there's a lot of room for error. Certificates and TLS tend to be a little bit finicky as probably everyone knows.
We do see these challenges from customers, and that's why we originally built ACM. Then of course, we built this feature to export the private key. Aside from just those manual installation challenges, you have things like all these different environments. You have Nginx running on EC2, you have your different load balancers and proxies and all these things where you might need to put a certificate, and there's not a super consistent way always to get the certificates where they need to go. Then you have things like renewal gaps where you have an expired certificate that leads to some type of outage and the TLS stack's broken. Your users aren't able to access your service. Those are the things we want to avoid.
We want to get to a place eventually where customers never have to think about certificates. It's just an automated thing where they get renewed and get placed where they need to go. That's kind of what the solution that Praveen's going to show is attempting to do. When we look at what we wanted to achieve when we built this, we wanted to look at things like event-driven architecture. Make sure that you have the ability to manually renew if you need to, but we really want it to be automated. We want it to be based on those CloudWatch alerts and EventBridge alerts that are published when a certificate's about to expire.
When Praveen shows the demo, you'll see there are kind of two ways to do it. You can manually renew or you can have a Lambda or an EventBridge rule that's basically listening.
When triggered, you'll need to export the certificate and place it where it needs to go. We also wanted to ensure that the private key is secured. When you export the certificate, just like every other ACM API, it happens over HTTPS, so it is encrypted in transit. You also specify a passphrase, and the certificate will be encrypted with that passphrase. In our case, we store that passphrase in AWS Secrets Manager for more secure storage.
When we get into these two types of workflows, we have the on-demand method, which allows you to manually renew a certificate. Maybe there's some type of compromise, or maybe you have a requirement where you need to manually renew it earlier than expected. You're able to trigger an API and manually trigger the automation. Then you also have automated certificate renewal where EventBridge does the trigger, and we listen for that event. In an automated way, we export the certificate and put it where it needs to go.
Domain Validation Methods and Cross-Account Certificate Deployment
You can export the key and put it on a device in another account. Our solution does support that. When you export that key, you could definitely put it on a device in another account. We use domain validation, so you need to create a CNAME record that proves you own that domain when you request the certificate, regardless of whether it's a wildcard or not. You could also use email validation, though that's not really something we recommend.
Typically, if you use Route 53 for DNS, ACM will actually create that record on its own. You don't need to do it manually; it's kind of a one-click button. However, you may need to update your DNS records manually if you have another provider. As long as that CNAME record is there proving you own that domain, we'll validate it and issue the certificate.
You did mention the one-click update, but there are often situations where your ACM and your Route 53 zone are in different accounts, which causes problems. Have you thought of any solutions allowing RAM shares or ACM so that it can be shared across multiple accounts to make that easier? That's a good question, and it is something that customers have challenges with. Maybe you have Route 53 zones in a different account from where you're issuing the certificate, and it doesn't have that same integrated seamless workflow around creating the CNAME record.
When you issue the certificate, it publishes an EventBridge notification with the CNAME information you need. Oftentimes, customers have to create automation on their own to grab that record, put it in some kind of central repository, or feed it into another account and create the record through automation. They assume a role in the other account and do it that way. There are workarounds that customers build today, but we're looking at ways to make that experience easier. It's not something I can talk about right now, but it's a good question.
When you export that private key, you can put it wherever you would like. What Praveen will talk about is how the sample code we've written helps you actually install that certificate securely on, for example, an on-premises server. He'll get into those details.
I'm not going to go too deep into it because he'll show that in practice, but yes, you can absolutely do that for on-premises servers as well.
On-Demand Certificate Deployment Workflow Using Systems Manager
I'll pass over to Praveen now. He's going to talk about the architecture and then do a deep dive into the code and the demo. I'll go over the architecture diagram.
So there are two workflows to this solution. This is the first workflow, which is on-demand certificate deployment. What it requires is that you already have a certificate issued with ACM with DNS validation, and it is issued. Once you have the certificate, you need to have the ARN of the certificate. What we're going to do is use an API Gateway, which will take an API call. We have an API template which we will share, and it's available in the sample code as well. You pass the certificate ARN and certificate name details, and what the solution does is install the certificate on EC2 instances. This can be done at scale, so if you have multiple EC2 instances, you can install it on more than one instance. Because it's tag-based, we're using tags to identify which EC2 instances need the certificate installed.
What we're using internally is Systems Manager. For those not familiar with Systems Manager in AWS, it's a management solution that people use to manage their fleet of EC2 instances. If you have multiple EC2 instances that you want to patch or run ad hoc commands on, you can do that with Systems Manager. It has a concept called an automation document. You can write custom commands or scripts in that automation document and run them at scale across multiple EC2 instances. Systems Manager can also manage servers on-premises, so you could manage some of your on-premises servers through Systems Manager and run commands to install certificates on-premises as well.
Going back to our solution, what we're doing is calling the API to specify which EC2 instances need the certificates applied. You give the name of the certificate and the ARN of the certificate. That triggers a Step Functions workflow. A Step Functions workflow has three Lambda functions. The first Lambda function exports the certificate from ACM. To export a certificate from ACM, you need to pass a passphrase, which encrypts the private key as it comes out of ACM. Inside ACM, the private key is encrypted by KMS. Once you bring it out, it's not encrypted, so we provide encryption with a passphrase to keep it encrypted when it comes out.
In this automation, you don't have to create or manage the passphrase yourself. We generate a dynamic passphrase that even the user is not aware of. We take that passphrase and store it in Secrets Manager. Then we take the private key and public key and pass them to the second Lambda function. We also have a DynamoDB table that stores metadata about where the certificate is being installed. When you export certificates, people often forget where that certificate has gone. The DynamoDB table stores exactly which EC2 instances the certificate is installed on, including the tags, the ARN, the expiry date, and everything else. So if you ever want to check how many certificates you have exported, where they are, and which EC2 instances they're installed on, all that information is in the DynamoDB table.
Once we have that, we pass the certificate details like the private key and public key to the Systems Manager automation document. This example installs it on a Linux machine, which is a normal Amazon Linux machine. It goes into the certificate folders and installs it. You could modify this.
The automation document to do a clean installation on an EGX server or any custom application that you might have. It's just a bunch of commands that you have to run. You can do it for Windows as well. If you have an IIS server that you want to update the certificate to, that's just another automation document. If you want to move that certificate outside to another cloud provider, you could do that too, but you may not be using Systems Manager at that point. You might have to use a different solution.
So I'm looking at trying to move the certificate into an external vault or somewhere from where it can be integrated by other cloud providers as well, but that's an extension I'm working on. I'll be working on that for the next year, and I'll have a solution on the samples updated with that. But for now, it does it on EC2 instances and it uses Systems Manager. If you're planning to use any of this and you have a specific application or anything, absolutely feel free to reach out. I'm happy to help out if you're looking for any assistance or direction on how the code should look like.
Securing Private Keys with Attribute-Based Access Control and Automated Renewal
It is also open source as well on GitHub, so feel free to contribute as well. It's a GitHub resource, and if you have questions you can reach out. I'm going to share the link where it is available and it's in AWS samples. So one of the key things of exportable certificates is that once the certificate is exported, it becomes the customer's responsibility to secure that private key. We did two things to make sure your private key is secured. First, we generate the passphrase for you, and we store that passphrase inside Secrets Manager. Then we also tag Secrets Manager the same way that we tag the EC2 instances.
What we are doing is Attribute-Based Access Control, which means the EC2 instance tag and the secret tag need to match for the EC2 instance to get the passphrase and decrypt the private key and use it in the application. It's not like I put a secret somewhere and any EC2 instance can go and access that secret. It's attribute-based, so only specific EC2 instances where the certificate is installed can access that secret to encrypt or decrypt the private key for their use. Those are the two key things that we provide with this solution. Any questions on this?
It would not auto-discover existing certificates that we haven't solved. For example, if I have my certificates that renew once a year, would all this cover that, or do I need to do something else? No, so it cannot auto-discover certificates. It's only if you issue the certificates to ACM and you want to export it and install it outside. That's the part that is going to automate. The second part of the solution is the renewal of the certificate. What we have is an EventBridge rule created with CloudFormation. It looks for the event when the certificate, the public certificate, is renewed. Your public certificate, which is exportable, is basically renewed 60 days before the expiry. So 60 days before when the certificate is renewed and issued, it will trigger a job where we call our Lambda function.
That Lambda function takes the certificate ARN. It's able to look up based on the ARN whether that certificate was exported and installed on an EC2 instance. If it is, then it is going to take the relevant details from the database, and it is going to trigger the Step Functions workflow. Then the process is the same. It's going to export the new renewed certificate. It's going to create a passphrase for it. It's going to update the passphrase in Secrets Manager, and it's going to go and install those certificates exactly where it installed last time, running the same scripts.
What this means is you do not have to worry about renewal of the certificate even on your EC2 instances. This solution is going to automatically identify that and go and install it on your EC2 instances. Obviously we have logging and everything enabled, so if there's any issues, you will be able to go and check that and create alerts based on that as well.
Can we use the tags to identify the server that needs the certificate? Would it read the tags and identify which server uses which certificate? There is fundamentally no way based on tags or instance for us to identify what certificate is on that server unless you create an application that actually searches across different folders and identifies the certificates on there. There is no easy way to identify what certificate is installed on which server without knowing who put it there or where it is. There are third-party solutions that try to do it. The other way I've seen people do it is they identify the endpoint and try to do a TLS connection to get the certificate information based on that.
Even the agent would have to search across the disk to identify what certificates are already stored on that device. This solution does not do that. It only takes the exportable certificate, installs it on EC2, and then it also renews it for you at the end of it. This is a proof of concept that we built and published on GitHub as sample code for customers. The portable certificates feature is a feature that the ACM service team built, but what we are showing today is something that we built. Regarding certificate inventory, I would agree that I typically see customers use partner solutions like VenFI or AUX to go out and discover where certificates are placed. As far as ACME, today ACM does not support ACME. Let's talk after and we can talk about roadmap, but today ACME is not supported by ACM.
Cross-Account Implementation and DynamoDB Certificate Tracking
We are being recorded, so I cannot really talk about roadmap, but we are a customer-obsessed company. Many customers have asked for ACME, and you can infer what you will from that. The next part is about cross-account functionality. How does it work cross-account? Yes, this solution does work cross-account. You have CloudFormation templates, and there are a couple of CloudFormation templates in here. One is for the central account implementation, which has all your Step Functions and everything in one account from where you want to issue your certificates. Then you just create some IAM rules for cross-account so that your Systems Manager is able to run commands on your EC2 instances and your EC2 instances, once created, are able to access those secrets that are created in that account.
The important thing here is that the passphrase is actually stored in the same account as where the EC2 instances are. We did not want the EC2 instance to go back and get secrets from another account. That is why we cleaned up the solution to do that. Here is the link for the GitHub code. If you scan it or just look for ACM sample ACM export certificate automation in AWS samples, you will find the solution. It has a very detailed README that talks about how to do the installation, how to test out the installation, and everything. It is very detailed. If you still have any issues, feel free to add and comment on there or just reach out to me based on the email that will be shared at the end.
Now I will switch to demo mode to show exactly what we are doing. This is Quiro. I built this solution in Quiro. I know Quiro is something everybody is talking about today. If you have not tried Quiro, definitely try it. It is based on VS Code, but it is still pretty useful. The template that you are seeing over there is the template for calling the API. Like I said, it takes the certificate ARN.
You can give it a name, and you have to provide the target tag values, which in this case are ENV and Dev as the tag value, along with the target account—the account where you want to install the certificate. You provide these values and this will trigger the Step Functions state machine. I'm going to sit down and do the demo now. If you have any questions, please raise your hands and let me know.
The API Gateway is actually IAM protected. Whoever calls the API must have the right and valid IAM role to actually invoke it. This is a security layer we've added so that not just anybody can export the certificate and put it on any EC2 instance. We've added an additional layer of IAM protection. What I'm going to do is use the AWS curl command, which takes my IAM profile from my desktop and uses it to call the API directly, rather than me passing STS tokens through the curl command.
You can see the execution ID here. This started the execution of my code. First is the export cert step. We have the input of the certificate ARN and all the details. What it did was export the certificate and add the secret to Secrets Manager. This contains the whole encrypted public-private key that you're seeing here. This detail is now stored, and if you see the certificate name is demo December 2. After creating everything in Secrets Manager, it's going to call Systems Manager for the automation document. I'm passing all the certificate details to Systems Manager, and it's going to execute. If you see here, there is an automation execution ID, which means the automation execution has started.
This is a cross-account deployment. I'm on an account starting with 70, and this is going to install on another account which starts with 090. So you can see that it's going to do a cross-account deployment. We do have examples of cross-account deployments there. Great. A lot of times the automation takes some time if you're installing on multiple EC2 instances across accounts, so there is a wait section for that. It basically waits for the automation document to complete successfully. Once the automation status shows completed, it just moves to success states based on the number of EC2 instances.
If it fails to install on any one EC2 instance, it will generate an error, and you'll have to go back and check in Systems Manager to see what exactly happened there. This code handles all of that. This is the DynamoDB table. As I mentioned, it's going to have all the details of the certificate. It has a primary key and the certificate ARN. It has the certificate's expiry date and the certificate name that you provided. In this case, we used December 2, so that's the one. It has the details of where the passphrase is stored in Secrets Manager and which target account the certificate is installed on. Even that detail is available in the database, so if you want to check anything about what's going on, you can do that from here.
Live Demo: Certificate Installation and EventBridge-Triggered Renewal
I'm going to the other account now. Yes, it's expandable as well. That's a good question. I was actually trying to do that, but I didn't get any customer feedback on people who wanted to go on EC2 clusters. However, if it's an EC2 instance and you can run an automation document on it, you will be able to install it anywhere over there. The code exists today but doesn't have run documents like Praveen mentioned for ECS.
But there's no reason you wouldn't be able to. That's good feedback, and I think we can adjust it to include that because you will definitely be able to put that private key on an ECS task. We haven't built that into the solution as of right now.
You have a custom solution for what? I'm sorry. Service mesh? No, I don't think we did that. So you mean for the MTLS between services? Yes, so really public certificates, which is what we're talking about today, you can no longer use them for MTLS because you might be aware of another CAB forum change recently. Public certificates are no longer allowed to have what's called the client authentication extended key usage, which is necessary for MTLS. So this particular solution with public certificates would not work there.
I mentioned AWS Certificate Manager Private CA earlier, and you can absolutely issue private certificates of any template. As long as it's X.509, you can adjust that template however you'd like. We do have customers that use that for service-to-service communication. There was a service called AWS App Mesh that customers would sometimes use for that. I more commonly see customers use partner solutions like Istio today. So yes, but you would not necessarily be doing that with these public certificates since you're not able to anymore. That would be something you would look at private certificates with AWS Certificate Manager Private CA or Windows PKI or something like that. Any time you're using a private certificate, that's where you would do MTLS between services, for example.
This is the EC2 instance. It has the tag ENV set to dev, so it went and installed it on this one. This is the instance profile of that EC2 instance, basically the IAM roles that EC2 instance has. If you see, this is the IAM policy that was added to the EC2 instance, which is using tag-based access to actually go and access the secret that is created by the automation at this point. If you go ahead and check for the secrets over here, you will see that it has created a secret. Right now, this is a brand new secret created which has the passphrase. And it also has the tags attached to it. So basically what it did is it went to the other account, it installed the certificate, and I can show the certificates that are installed over here. This is exactly what I didn't want it to happen, so it logged me out.
All right, we can actually go and check the certificate. I have commands ready on that. So right now, it is installing the certificates on EC2 in the SSL certs folder in this Linux machine. If I run the grep, if you can see those two certificates, this is the public certificate. It has the full chain of the certificate and the certificate itself in there. Then the private key actually goes in another folder, which is SSL private. Over here is the private key that is installed on that server, which is cross-account. Now to access that certificate, I have a small script which will actually extract the passphrase from Secrets Manager. I can use that passphrase now to actually decrypt the private key.
So a lot of times, some applications ask for private key unencrypted, or some ask for private key with a passphrase inside the application. So depending on how you want it, your EC2 instance now has access to retrieve the passphrase and do the changes on that part. So that's the cross-account part. This is part one of the solution where you created and exported a certificate and installed it on an EC2 instance. Now, part two of the solution is the EventBridge part. So when you install this CloudFormation template, this service actually installs an EventBridge rule, which looks for a specific pattern. Now, I modified it. If you look at the source over here, it says test. But when you actually run the CloudFormation template, it will be ACM service.
I did that because I wanted to manually invoke this event to show the flow. However, when you actually do it, you don't need to run it manually for testing purposes. As soon as the ACM generates the event, your flow will be kicked off. In my case, for it to renew and do the step, it takes a few minutes. Since it's not good for demo purposes, I changed the source to test. I'm going to trigger this event, and this event will go and trigger a Step Function. Let's look at that. The command shows how to trigger this event as well, inside the code sample that I showed you. Let's run this from here. That should have triggered an execution. I see it's running three executions because the ARN of that certificate is attached to 23 different EC2 entries. It's going to renew it in all three places in the database. That's why you're seeing three instances.
What it's doing now is performing the same steps. It got the details from the DynamoDB table as to where that certificate is being referenced, and then from there, it's taking those details and installing it. This is basically hands-off, just like Application Load Balancer and CloudFront. Once you install the certificate with ACM, you just forget about it. It renews on its own. Similarly, with the EC2 instance, this solution can renew on its own as well. That's how this would work. Do you have any questions on any of this at this point?
Prerequisites, Fine-Grained Access Control, and Wildcard Restrictions
The only prerequisite for this to work is to make this certificate exportable, right? Yes, it's because we have a few certificates that are in AWS and not on load balancers, so this will work fine for the load balancers if the certificate is exportable. If you have services that are already integrated with ACM like Application Load Balancer, CloudFront, API Gateway, and so on, for those services, you don't have to worry about it. It will just do it out of the box. The problem comes when you export the certificate and move it to EC2.
I have customers who are also trying to use this solution to export the certificate and put it on an S3 bucket or somewhere for a third-party team to pick up the certificate and install it on some custom solutions as well. They don't want to do the automation to go and install it directly inside somewhere because they have a very specific use case. All they want is a self-service where somebody requests the certificate. You could actually modify the IAM rules and policies as well as the Lambda function to allow specific teams to only request specific certificates based on their tag or naming conventions. So you could add that customization in the Lambda function side as well.
If you have those kinds of requirements, you could do the modification, or if you need any help around that, if there are a lot of requests coming in saying they want to see that, you can do that because I was playing around with that and yes, you could actually do a little bit more fine-grain access control on how the certificates are managed. It uses IAM condition keys, so you would basically write a policy that says only Team A can request certificates with the domain name example.com and App Team B can request certificates with food.com but not example.com. Right, so you can create condition keys like that in IAM policy or SCPs, for example, or Service Control Policies to limit that as well as things like key type, right, like RSA versus ECC, and things like that. So you can get fine-grained with those permissions.
To your point about having the certificate on a managed service as well as on-premises, even if the certificate is marked as exportable, managed renewal with integrated services still works the same way. It would still be renewed in the same way on, say, your Application Load Balancer, and then you would also get a notification through EventBridge that a new certificate is available for export. You could either manually export or use a solution like this to grab it automatically through that granular control that you were just discussing.
Would it be possible to restrict requests for wildcards to still allow the route naming convention? So any FQDN at the subdomain level is fine, but not the wildcard. Yes, you can specifically restrict wildcards from being issued because some customers say they don't want their customers or developers to ever issue wildcards. Yes, you can absolutely do that.
Key Takeaways, Sample Code Customization, and Closing Remarks
Let me wrap up here, and if folks have other questions, feel free to ask. We have about nine minutes left, and then after that we'll be out in the hallway if you want to talk more, particularly about roadmap stuff. We can absolutely talk a little bit about that in the hallway.
So here are the key takeaways that we want you to remember after the session. Obviously, we want you to think about this new feature from ACM exportable public certificates. Think about how you're going to manage renewals for certificates that you export the private key for, whether it's something like this or a more manual process. Obviously, we want you to get to this place of automation when you can, but it's becoming more and more important, like we talked about with those CAB Forum changes. Someone pointed out I think in March it's going down to 180 days, and then I believe by 2029 it's 47 days. So for customers that are doing this manually, if you have hundreds of certificates that you have to renew manually every single month or so, a month and a half, that's not super sustainable.
Even if you're not doing all this through automation today, we're definitely encouraging customers to start moving more towards automated solutions for replacing these certificates. When we're looking at that sample code, we just want to keep in mind that you want to protect that passphrase or that private key because that's how it works when encrypted. You want to limit the risk of that private key being put accidentally somewhere and then being able to be decrypted, like blogged somewhere in your application or accidentally put on GitHub or something. You want to protect that with a passphrase and store that passphrase in a very secure place.
That's why when Praveen and I built this sample code, we put it in AWS Secrets Manager and we specifically generated it through an API in Secrets Manager called get_random_password. No human being sees that secret. It's put in Secrets Manager, and even your developers shouldn't be able to access that. It's just the automated service that can access it. We designed it with the tag-based approach just because that makes it easier to understand where these certificates are placed and which EC2 instances have which certificate. Through those tags and that DynamoDB table that Praveen mentioned and showed, that's how we're looking at that.
Of course, with the question around ECS, there are going to be some customizations for this. This is just like we mentioned earlier, kind of a proof-of-concept sample code we built. So definitely feel free to reach out to Praveen and me, or contribute back to the GitHub code and make our life easier if you want to do it for us. We're happy to do it as well if you have specific things you want to see added to this. Just let us know.
If you have solutions or if anybody over here is looking to actually use ACM certificates outside the AWS environment, like on a third-party cloud provider and stuff like that, on-premises is fine. What about Azure stuff? Yes, so I'm actually working on something where it moves it to the vault over there. There is recently some new IAM method that has come out where you could actually generate JWT tokens, authenticate to a third party, and put stuff in there. I'm trying to work on that, but that's something we can talk about after the presentation.
In that case, I don't know that we've tested that, but I believe that should work if they have VMs in another cloud provider that are managed by Systems Manager. If we just run an automation against it from Systems Manager, the way Systems Manager works is as long as there is an agent running there and connectivity back is there, it should work. That's how on-premises works, so I don't see why it wouldn't work on any other cloud provider. As long as the agent's installed and has a network path and access to the API and whatnot, yes, absolutely it should.
Any other questions or anything before we wrap up? I'm happy to answer anything. Will you throw that back up? Yes, just go to the next slide.
You can grab that. Or I think if you search AWS DBS samples export cert automation, it should come up as well. That's the GitHub link there. Even if you look it up with ChatGPT, it actually brings up that solution. I've seen it. How do you automate certificates in AWS? One of the solutions is that one. I did not know that. That's neat.
Any other questions? I appreciate your time. Thank you very much, and feel free to find us in the hallway if you have other questions or want to talk through anything. Thank you.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)