Skip to main content
banner image
venafi logo

Conversations with the Inventor of Wildcard Certificates—Part 3: The Risk of Exploit

Conversations with the Inventor of Wildcard Certificates—Part 3: The Risk of Exploit

Wild Card Certificates
August 9, 2018 | Scott Carter

In earlier blog, I spoke with George Parsons, the inventor of wildcard certificates, about why he created them and how they may be overused. During that conversation, George mentioned that he is concerned that organizations may not be taking wildcard certificates seriously enough. He noted that many organizations may be unaware of the risks connected with hasty certificate deployment strategies as well as a couple of attack scenarios that you may not have thought about.

Here’s the final portion of my interview with George:

  • What will change now that Let’s Encrypt is offering free wildcard certificates?
    With free wildcard certificates, the natural filtering or controlled use of wild cards based on cost just isn’t going to be there. I’m not a huge fan of DV certificates in general because it’s too easy to validate ownership of the domain. It doesn’t give us the assurances that we mere mortals need. It’s important to understand that it’s relatively easy to register a domain and order a certificate that’s DV only. I recently heard an analyst say that 80% of all malware shops use DV certificates. People go to these sites that are putting out this malware, and they think, “Well, it’s encrypted, it must be a safe vendor or website.” And certainly, the average user doesn’t know the difference between DV, EV, and OV.

    Unfortunately, I think what’s going to happen with free Let’s Encrypt wildcard certificates is that more and more people will use wildcard certificates for their entire domain (*.website.com) without thinking about how easily these can be abused.

  • Are organizations thinking enough about the security of wildcard certificates?
    No, not really. For example, if they are using an internal PKI vs. an external CA, they may not always worry about using best practices for certificates. They often think that, because they have control over the access to these systems, no malicious actors are ever going to get to them. This is just naive thinking, but often these same companies leave the key pairs for wildcard certificates laying around in .p12 containers living on file shares. And they rely upon the permissions to those file shares to restrict access to them. You know how easy it is to get access to file shares in certain companies? As long as you’re a member of a group, you have access to the file share and you can download anything.
  • What happens when attackers have access to a wildcard certificate?
    If you’re a bad actor and you get access to a file share through escalated privileges of some sort, you are then free to download an .p12 file (these contain a private key and its corresponding wildcard certificate) and exfiltrate it. Then you can do a brute-force attack on that .p12 using a password cracker, extract the key pairs, and you then have the ability to do man-in-the-middle attacks within that organization. At that point, you can impersonate any server inside the organization because you now control the key and the wildcard certificate.
  • What kind of sloppy practices have you seen with wildcard certificates?
    I worked with one company that left their keys and certificates in .p12 files on a server with no passwords. Their reasoning was that their orchestration software couldn’t do lights-out functions with the password injection so they had to do it without passwords. It gets worse; they weren’t all that worried about doing so, because they felt that they had strong permissions on the file server where they were storing the .p12 file for the wildcard, so they thought they’d be okay.

You name it, I’ve seen it. I’ve seen administrators leaving .p12 files lying around, emailing them to colleagues or partners, or leaving them on FTP servers. I’ve also seen them dropped inside of orchestration software.

  • What are the potential risks of treating wildcard certificates too lightly?
    Emailing a .p12 file containing wildcard assets immediately exposes it to attackers who may be sniffing email traffic that’s not encrypted. Another risk is that organizations may leave a .p12 file lying around on file shares, as I mentioned before. If the network has been infiltrated, those .p12s can be exfiltrated. Using brute force to factor the password, attackers can open up the .p12 and export the key pairs. Once they have the private key and are inside the website they can potentially impersonate an internal trusted server and capture sensitive data. Or, if it’s an external server, they can capture customer or user information in a phishing attack.
  • Why do you have to be careful about where you store wildcard certificates?
    Let’s say administrators get sloppy and leave .p12 files for wildcards lying around. If one of those is exfiltrated then there’s all sorts of exposure to targeted phishing attacks. Here’s another scenario: 10 admins have left the company over the past 5 years. Every one of those 10 admins have left SSH keys on a variety of different servers. This means the SSH privileged access into those servers is still enabled. Attackers that gain access to these SSH keys can pivot over to the file server where the .p12 files are , and then exfiltrate them. So much for the folks who say they are not exposed because they store .p12 files on servers that have strict permissions. The reality is that—even if they never (officially) allow escalation privileges or anything like that—they can still be at risk.

As an executive at Venafi, George feels obligated to mention that we offer a different kind of easy button. And by pushing it, you’ll actually become more secure. Venafi automates the entire key and certificate lifecycle. So, whether you choose to use wildcard or SAN certificates, we make it easy for you to automate the deployment of keys and certificates that follow your approved policies and workflows. This means you won’t have the additional overhead of manually provisioning certificates to their respective endpoints.

Related posts

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

Déjà Vu at LinkedIn: Second TLS Certificate Expiry in 2 Years

Déjà Vu at LinkedIn: Second TLS Certificate Expiry in 2 Years

Prepare this presentation and send it to me, once approved you can teach entire team.

Overheard at Machine Identity Protection Global Summit 2019

machine identity protection

Leaders Underscore the Critical Nature of Machine Identity Protection at Inaugural Global Summit

About the author

Scott Carter
Scott Carter

Scott Carter writes for Venafi's blog and is an expert in machine identity protection.

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