Skip to main content
banner image
venafi logo

A Valentine’s Day Warning for Let’s Encrypt TLS-SNI Users

A Valentine’s Day Warning for Let’s Encrypt TLS-SNI Users

Let's Encrypt TLS-SNI vulnerability
February 5, 2019 | Guest Blogger: Kim Crawley

Many organizations need to use free certificate authorities. If your business doesn’t have a budget for a paid CA, it’s certainly better to deliver your website or web app through HTTPS with the help of Let’s Encrypt than to use the plaintext web through HTTP. Recent versions of popular web browsers on both desktop and mobile such as Mozilla Firefox and Google Chrome have started to warn web surfers that HTTP sites are “not secure.”

I imagine that has probably convinced many organizations which previously avoided HTTPS because they didn’t want to pay for TLS certificates to sign up with Let’s Encrypt so that their users wouldn’t be dissuaded to visit their websites with a web browser-delivered warning.  Also, Google has acknowledged that HTTP web pages are now being ranked lower in their search engine than HTTPS web pages, so many new Let’s Encrypt customers probably have search engine optimization in mind as well.

If your organization uses Let’s Encrypt as a CA, there’s an important deadline coming up very, very soon. On February 13, 2019, Let’s Encrypt will disable support for TLS-SNI-01 domain validation. Especially if you use multiple subdomains on the web, such as,,,, this will probably affect you. If you don’t change how your TLS certificates are configured, you’ll find that your HTTPS-delivered web content will no longer be properly accessible to your users. And there are significant security concerns as well.

Unfortunately, last year it was brought to the attention of Let’s Encrypt that they had a vulnerability pertaining to their deployment of Server Name Indication, specifically TLS-SNI-01 and TLS-SNI-02. Server Name Indication makes it possible for multiple certificates to be used with the same IP address and TCP port number. That’s especially necessary for web domains which use multiple subdomains. SNI is an extension to the TLS networking protocol which enables the hostnames that a web client is trying to connect to during the handshake process to be validated. But the vulnerability that was discovered in how Let’s Encrypt deploys SNI enables a cyber attacker to acquire TLS certificates for domains that they don’t own. That makes a certain type of man-in-the-middle attack possible, because a certificate is a machine identity that acts as a key to unlock TLS encryption.


When you administrate a web server, it’s pretty easy to create new subdomains to your domain name. Let’s say that there’s an online shoe retailer and their domain name is A year ago, the store had an online promotion where if a customer buys a pair of shoes, they get to choose a second pair of shoes at or below the retail price of the first pair for free. So was deployed to make a dedicated website for the promotion. It’s the kind of thing online businesses do all of the time. The buy-one-get-one promotion ended a while ago, and Choosy Shoes stopped delivering content at the subdomain. Choosy Shoes still uses a CA to deploy TLS certificates for and some other subdomains of theirs.

An external cyber attacker sets up a legitimate account with the same web hosting provider that Choosy Shoes uses. Choosy Shoes’ web administrator forgot about the subdomain, which had been abandoned months ago. Exploiting the vulnerability in how Let’s Encrypt implements SNI, the cyber attack could add their own HTTPS web server for, use the same CA that Choosy Shoes uses, Let’s Encrypt, and impersonate the shop online.

Let’s Encrypt decided to mitigate the vulnerability by disabling SNI for new accounts but allowing previously existing accounts to continue to use SNI... for the time being.

Now the time’s almost up. On February 13th, 2019, Let’s Encrypt will disable SNI completely. They suggest TLS extensions DNS-01 and HTTP-01 as an alternative for the name validation needed to deploy multiple certificates for one IP address.

Whether or not your organization uses Let’s Encrypt as a CA, this incident should serve as a useful warning. Effective network cryptography requires full visibility into all of the machine identities that your organization uses. Do you have any abandoned or orphaned subdomains? What about main domains? Are there any addresses which point to network resources that you have which lack necessary machine identities or have improperly configured machine identities? Don’t wait until spring for this sort of spring cleaning, full machine identity visibility should be acquired as soon as possible.


Related posts

Like this blog? We think you will love this.
wildcard certificates
Featured Blog

Wildcard Certificates Make Encryption Easier, But Less Secure

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

Subscribe Now

See Popular Tags

You might also like

TLS Machine Identity Management for Dummies

TLS Machine Identity Management for Dummies

Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

About the author

Guest Blogger: Kim Crawley
Guest Blogger: Kim Crawley

Kim Crawley writes about all areas of cybersecurity, with a particular interest in malware and social engineering. In addition to Venafi, she also contributes to Tripwire, AlienVault, and Cylance’s blogs. She has previously worked for Sophos and Infosecurity Magazine.

Read Posts by Author
get-started-overlay close-overlay cross icon
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