Conversations with the Inventor of Wild Card Certificates—Part 2: Beware of the Easy Button

Here’s part two of my interview with George where we talk about the temptation to push the easy button for wildcard certificates:

• Do you think that organizations overuse wildcard certificates?
  I don’t think they do, I know they do. So often I see organizations clearly not using best practice when they create a wildcard certificate using a singular key pair, so they can deploy it to 20, 30, 40 or even 2000 or 3000 servers. Wildcard certificates make that really easy, but it’s a huge exposure. Think about it; if you compromise just one of those private keys, you compromise the entire trust infrastructure for every one of those servers. But it’s easy. It’s the easy button and that’s pretty tempting
   
• Why is the wildcard “easy button” pushed so often?
  If there are no restrictions on name form, administrators are likely to request the easiest option: *company-name.com. Then they will deploy it for just the intended websites. But then one time when they are super busy, some other application group comes along with a new service that they are going to stand up. They need some key material for it and a certificate and they need it pronto. It’s easy for the administrator to say, “I don’t really have the time for that with your domain name. But hey, I’ve got this wildcard certificate. Here take this .p12 container with the key pair and the wildcard certificate and deploy it on your website.” This is the type of behavior that will undermine your trust model.
   
• Why aren’t organizations using more secure alternatives like SANs?
  One of the reasons people overuse wildcard certificates is because their CA doesn’t make it easy to add additional Subject Alternative Name (SAN) certificates. It’s not like you can just go to some of the CAs and say, “Look up this SAN certificate, it has 15 entries on it, here’s two more. Just add these two new ones and then send me back the revised certificate. Then I’ll deploy that on these other two sites and then I’ll rotate the certificate to the other sites in the future.” Without an automated management solution, it’s hard to really use SANs properly because of the challenges connected with the distribution and provisioning of it.
   
• Wouldn’t it be better to take the time to use SANs instead of wildcards?
  Of course, but it’s always an emergency. Here’s an all too common scenario for last minute requests: You didn’t tell me that you needed this and I usually need 5 days to get you the key pairs and the right certificate. So, I’ll just use this wildcard certificate that I have laying around and that will work. Rather than request a SAN certificate or a more restricted name form wildcard certificate, they just reuse key pairs and certificates and eventually all of their TLS web servers end up using the same key material and certificate.
   
• What’s the future of wildcard certificates, now that you can get them for free?
  I don’t think things are going to change. Organizations will continue to abuse wildcard certificates and ignore best practices. People will take shortcuts because they are busy. They will say, “Gosh, it worked over here, I’ll just duplicate the key pairs and the certificate on all these other sites.” You have to realize that many of these administrators are not security experts. So, even organizations that are trying to be really careful with wildcard certificates will bump up against the old operational efficiency vs. security argument. If I’m an administrator or if I’m standing up websites, and I’m not a security person, I’m going to do what’s easiest for me.

Do the risks of wildcard certificates outweigh their advantages? Stay tuned for our next (and final) conversation, where George warns of the risks of not treating wildcard certificates with the respect that they deserve.

Related posts

• Conversations with the Inventor of Wildcard Certificates—Part 1: Early Days
• Wildcard Certificates from Let’s Encrypt: Will the Rewards Outweigh the Risks?
• More Wild Cards, More Problems: The Safest Bets for Keeping Threats Out of Encryption

Scott Carter

In my last blog, I covered the first part of my conversation with George Parsons, who is the pioneer of wildcard certificates. We discussed how he created wildcard certificates and why they were needed. In my next conversation with George Parsons, we’ll look at why some companies are tempted to overuse wildcard certificates. Of course, it’s easier to use one certificate instead of many. But there are certain circumstances where pushing that “easy button” can lead to increased exposure.