Skip to main content
banner image
venafi logo

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

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

wildcard certificates
June 19, 2018 | 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.

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

Like this blog? We think you will love this.
graphic image of an electrically lit tunnel, apparent from the inside but invisible from the outside
Featured Blog

The Fight over DNS over HTTPS

DoH, Browsers and ISPs

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

CIO Study: Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

Forrester Consulting Whitepaper: Securing the Enterprise with Machine Identity Protection
Industry Research

Forrester Consulting Whitepaper: Securing the Enterprise with Machine Identity Protection

Machine Identity Protection for Dummies
eBook

Machine Identity Protection for Dummies

About the author

Scott Carter
Scott Carter

Scott is Senior Manager for Content Marketing at Venafi. With over 20 years in cybersecurity marketing, his expertise leads him to help large organizations understand the risk to machine identities and why they should protect them

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more
Chat