I don’t think it’s going too far to say that free TLS certificate offerings like Let’s Encrypt and AWS Certificate Manager have taken encrypted connections mainstream. TLS/SSL has gone from something fairly arcane that many sites didn’t bother with, to a baseline state that’s so ubiquitous that some browsers now warn when they encounter unencrypted connections.

When ACM first launched, it was straightforward and easy to understand: it generated certificates, but you’d never be allowed to see the private key. That was reserved strictly for AWS-controlled endpoints, like CloudFront distributions and ELBs. Nine months later, it gained the ability to let you import certificates from elsewhere. Again, once you uploaded the private certificate, AWS wouldn’t give it back to you. You could use ACM-generated certs on AWS-controlled endpoints, but nowhere else–not even EC2 instances.

As of this feature launch, ACM will generate a certificate that’s accepted by all major browsers _and_ will give you the private key. Note that you have to elect to make a certificate exportable before it’s issued; you can’t go back and retroactively export certificates that you’re already using. Your CISO can stop hyperventilating.  

The pricing is quite reasonable. It costs either $15 per domain, or $149 for a wildcard certificate. That seemed a bit expensive to me, until I remembered what these things used to cost–and apparently still do. $400 per certificate isn’t at all uncommon from trustworthy vendors, whereas bargain-basement GoDaddy (and it’s my considered opinion and lived experience that you should never put a company with “Daddy” in its name into your critical production path) wants $70 for a single domain cert and $350 for a wildcard. ACM’s pricing is a comparative steal.

The Snake Oil Certificate Ecosystem

Incidentally, when researching the current state of the certificate ecosystem for this post, I found myself taken aback by the sheer level of snake oil in the space. “Extended Validation,” “Organizational Validation,” and other similar terms are consistent upsells that functionally don’t change anything. We’re no longer in an era where special expensive certs turn the browser address bar green; domain-based validation either through email or DNS records is as far as the trust chain goes.

What TLS means, and all it can mean, is that unless someone has made a terrible mistake managing their certificates:

  • the connection between you and an endpoint is encrypted, 
  • the domain owner has authorized the certificate, and 
  • the domain is who they say they are. 

That’s all Let’s Encrypt does, that’s all that ACM does, and functionally that’s all the sleazy arena of SSL certificate vendors do.

What that means is that I have to give AWS points here compared to its SSL-vending competitors, just because they don’t mislead the customer about how any of this works. I really shouldn’t have to do that. You don’t deserve points for doing the right thing, but they’re a beacon of integrity here by comparison.

It’s more expensive than Let’s Encrypt’s $0. That said, large banks still have expensive certs (although for some reason nsa.gov, defense.mil, and a host of other US federal government sites are using Let’s Encrypt, which feels… strange), as do many other enterprise-tier vendors, so there’s at least some lingering perception that there’s value to the CA model. I really don’t have a problem with this price point. Again, there are copious free alternatives if the $15 a year becomes burdensome for the use case.

Certificate Expiry and the Manual Process Problem

ACM exportable certificates currently have a 395-day expiry, which is probably around the right number. Let’s Encrypt is 90 days, which is long enough that you _could_ manually rotate certs, but you probably should find a way to automate it. I’m currently building a CA for my home lab that features a 24-hour expiry, for comparison’s sake.

At least at launch, this feature doesn’t support ACME for automatic renewal, which means there’s likely to be an inherently manual process to renew them. While you can automate the entire certificate issuance dance via AWS APIs, I’ve worked with enough enterprise software to know how this is going to play out: it’s a manual process. “Manual” means “fallible,” and people are going to forget where they put these things, particularly the wildcard certs.

That said, an awful lot of software that you’ll see scattered around enterprises flat out doesn’t support anything remotely like automation, so you’ve sorta got to follow this pattern. BUT FOR GOD’S SAKE POINT MONITORING AT IT AND SET A CALENDAR REMINDER A MONTH BEFORE IT NEEDS TO BE RENEWED! ACM will send CloudWatch Events before expiry, so please pay attention to them—but let’s face reality. If you didn’t set up monitoring, and didn’t add a calendar reminder, you’re exactly the kind of shop to ignore the CloudWatch Event too. 

The Good News

One last point that’s important but sounds kinda rude to say out loud is “you can turn this feature off.” That’s important for shops whose security posture is such that they absolutely do not want private keys leaving AWS endpoints. You can disable it either at the AWS Organization level, or via SCP on an account-by-account basis; the folks who run that security posture should be able to take it from there.

The other boxes I have for feature launches all got checked. The pricing is clear and transparent, billing doesn’t start for a certificate until it gets issued by AWS, the APIs are robust, CloudFormation knows that this exists, and it supports tagging.

Overall, this is a solid addition to ACM that fills a real need in the market, even if it does reinforce some manual processes that make me twitch slightly.