Conversations with the Inventor of Wildcard Certificates—Part 1: Early Days

Recently, when Let’s Encrypt began offering wildcard certificates, I began to wonder how this would change the encryption landscape. Would we see more companies encrypting more of their online assets? Would best practices for wildcard certificates scale to meet this new demand? Would we see a corresponding increase in phishing and other attacks?

Cybercriminals are phishing with TLS certificates found on the Dark Web. Find out more.

As I was discussing these issues with a colleague, I was surprised and delighted to learn that the inventor of wildcard certificates, George Parsons, works with me at Venafi. To better understand some of the ramifications of the availability of free wildcard certificates, I sat down with George for a lengthy and informative chat about the history, use and abuse of wildcard certificates. Some of his anecdotes were amusing. And some were downright frightening. But I’m sure you’ll enjoy all of them as much as I did.

Here’s part one of my interview with George Parsons:

• How wild was the certificate process in the early days?
  I remember when the Royal Bank of Canada requested a certificate, the operations person at Verisign said, you’ve got to send me a copy of your certificate of incorporation or some type of legal documentation, the bank replied, “I can’t do that, it’s on parchment under glass at a museum.” And the operations person said, “Okay can you get a copy of that for me?” Of course, this was before the days of cameras on cell phones. We all had a good laugh about that.
   
• What inspired you to create wildcard certificates?
  The goal was to make sure that we had certificates that would support certain use cases that were particularly difficult at that time. The way we used digital certificates to validate trust with a website hasn’t changed. But for companies like AT&T, for example, special characters were challenging. In the early days, browser companies were barely able to process certificates with special characters. But the real problem was how to support the scaling of websites. Companies needed an easier way to add web servers without adding the complexity of managing additional key pairs and certificates to authenticate them with. So, we invented the wildcard certificate using standard Unix regex characters. As a result, servers that had previously used "www1.company.com", "www2.company.com", and "www3.company.com" could all use a “www*.company.com” wildcard syntax instead.
   
• What was the original purpose of wildcard certificates?
  One of the first applications of wild card certificates was when companies started realizing the value of placing a load balancer in front of web servers to accommodate spikes in traffic. Those companies ended up with, say, five different web servers for one domain, all of which are behind a load balancer. They wanted to be able to use one certificate to authenticate anyone coming in through that front end. Wildcard certificates made that possible.
   
• How did wildcard validation work in the early days?
  When I designed the OV process way back when, we worked with Dunn and Bradstreet to do the look ups and we created a special portal to do that authentication manually. Automating that process would be challenging. I suppose, one could screen scrape the data and automate some of that but at a certain point a human needed to be involved.
   
• How did you intend wildcard certificates to be used?
  The best practice was never to have "*.website.com" because that defeated the purpose of trying to give the end user the assurances that they are talking to the intended website. The challenge is that when administrators request a wildcard certificate, they really have to understand what the different environments they are standing up with the domain. They need to know exactly what the qualified domain name is going to look like before they create that certificate. If not, they increase their chances of becoming a victim of an attack that misuses wildcard certificates that are too broad.
   
• Looking back, how successful was the wildcard certificate?
  Wildcard certificates fulfilled their original intent, but the problems we faced then were a lot different. For example, now we have the ability to do SANS certificates. These require that you define your subdomains, rather than relying on the * marker. This gives you a lot better control, but it also requires a lot more planning. If you think about what best practices should be, one could argue that SANS certificates are the way to go and, in that case, there would be no real need for wildcard certificates today.

Have wildcard certificates outlived their usefulness? In the next two conversations with George Parsons, we’ll look at potential attacks that misuse wildcards and the ongoing temptation to use wildcards widely across enterprise networks.

Learn more about machine identity management. Explore now.


Related blogs

• 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
• Reddit Clone Site Uses SSL Certificate to Lure Users into Handing Over Login Credentials