Massive system breaches seem to be a common headline in the news today. Reading between the lines, you can hear someone say, “If only we had…” I understand the temptation to skip certain security best practices if you feel the cost to implement them is high and the likelihood of their occurrence is low. Modern-day Infrastructure as Code (IaC) processes, though, have lowered the costs of implementing many security best practices. It would be a good idea to revisit these past decisions you have made (you recorded them, didn’t you?) to see which ones have become low-hanging fruit. Wild card TLS certificate is a case in point since using them makes all of your servers as vulnerable as the least secure one. A better approach would be individual certificates or an investment in SAN certification.
What Does a TLS Certificate Do?
A TLS (Transport Layer Security) certificate, formerly known as an SSL (Secure Sockets Layer) certificate, is used to authenticate the identity of a server. The certificate contains the server’s public key and other identifying information, such as the domain name, and is issued by a certificate authority. This allows for secure communications between, for example, a user and a website they are accessing. When the user’s web browser sends a request to establish a secure connection with that website’s server, the server returns its TLS certificate. The user’s browser then checks the certificate’s digital signature against those in the browser’s (or system’s) list of trusted issuing authorities. If the name(s) on the certificate matches the server the browser is contacting AND that certificate is determined to be cryptographically valid AND it was issued by a trusted authority AND it has not expired, then the connection is presumed secure and the two can now encrypt their communications.
What is the server claiming to be? The domain name! When we set out to secure tenmilesquare.com, we requested a TLS certificate from Let’s Encrypt. Before they would grant one to us, we had to prove we owned that domain. There are several ways to do that:
- Add a TXT or CNAME record on your DNS for the domain.
- Upload a file to your server.
- You can also do it via phone or email, but that’s more involved.
Once you have the certificate, you will need to install it on your server. Where and how depends upon the server itself. It’s important to remember that the certificate has an expiration date, so you’ll need to renew it regularly.
The Dangers of a Wildcard Certificate
For my 2 personal websites, every 90 days, I go through the same process, which takes about 10 minutes. Most of that time is taken up by proving I own the domains and then shutting down and restarting the web servers. This isn’t a great burden for me. But what if you have dozens, even hundreds? This is easy to do if you’re providing software as a service (SaaS). If your customers use subdomains (e.g., cust-1.example.com, cust-2.example.com, etc.), a quick solution would be a wildcard certificate. Instead of certifying each customer, you get only one for *.example.com. That covers any possible subdomain beneath example.com. Easy-peasy.
That would be a mistake with potentially catastrophic consequences.
First of all, this introduces a single point of failure into your system. Should something go wrong with that certificate, it could affect ALL of the subdomains covered. Yes, there are technical glitches that can cause you headaches. This single point of failure, though, means that it takes only one compromised server to put all of the infrastructure covered by that certificate at risk. The latest, as described by the National Security Agency (see link below under More Reading), is the Application Layer Protocols Allowing Cross-Protocol Attack (ALPACA). Suppose someone can compromise a server covered by a wildcard certification. In that case, they can redirect traffic meant for other servers to that compromised machine for any number of nefarious activities, such as getting user credentials. The affected users would be none the wiser because the system tells them the destination is certified.
The More Secure Options
What can you do to mitigate the vulnerability? Manually certifying each server would be time-consuming, but still better than wild certificates or no certification at all. However, there are better options.
As mentioned at the beginning, IaC using tools such as AWS Cloud Development Kit (CDK), AWS CloudFormation, or Terraform can help alleviate the tediousness of setting up so many domains quickly, for example in response to a SaaS sign-up. Ongoing maintenance is minimized by utilizing built-in automation in systems like AWS Certificate Manager working with AWS Route53 to both certify and provide certification for auto-renewal. If these tools are utilized properly, using individual certificates is as easy or easier than a wildcard certificate.
A multi-domain certificate, also known as a Subject Alternative Name (SAN) certificate, is another solution. A single certificate can cover multiple, discretely named domains/subdomains. Theoretically, this can cover hundreds of domains/subdomains, but when you get above 10, you become as vulnerable as a wildcard TLS. The pricing of this approach varies from around $100 to $2,000 a year. The costs vary depending on the certificate authority you choose, the level of validation you require, the number of SANs included, and the duration of the certificate.
Ten Mile Square Can Help
We have helped many companies automate the securing of their infrastructure. Contact us for a free consultation.
More Reading
- Certificate authorities
- Ten Mile Square’s certifying authority: Let’s Encrypt
- National Security Agency: Avoid Dangers of Wildcard TLS Certificates and the ALPACA Technique
- Multi-Domain and Wildcard SSL: what’s the difference?
- Relevant automation services:
