Configuring a web server to encrypt traffic–something that should have always been a simple and free process–is finally a simple and free process.
The concept of encrypting web traffic isn’t terribly complex. A webmaster configures their favorite web server to encrypt all traffic based on HTTPS. Part of the configuration is to install an SSL certificate. Certificate authorities (CA) provide the SSL certificate.
All major web browsers have a list of trusted security certificate issuers. If you’ve ever tried to acquire and implement a certificate, you’d realize the process is frustrating. The open source project Let’s Encrypt aims to solve several of the challenges.
To obtain a certificate today, you contact a CA to purchase a certificate. The fee is normally between $50 and $1500. One of the original objectives of a CA is to validate the identity of the certificate requestor.
Before scale issues, this was done by the CA physically contacting the requestor. Today, many CAs handle the request via email and automated phone callback. During the process, the web server administrator would generate a certificate request. Finally, the CA generates a certificate with a set expiration date.
Once obtained, the web server administrator installs the certificate and configures encryption on the web server. The web server administrator needs to understand what type of encryption to implement. The administrator should be fairly up to speed on the latest security encryption concerns such as SHA-1 vs. SHA-2 or SHA-3. Setting up encryption is a challenge for even some experienced administrators.
Let’s Encrypt approaches the problem by creating an easy to use client. The client establishes a connection with Let’s Encrypt enrollment servers and passes what Let’s Encrypt calls shrubbery.
Shrubbery is the process of sending and receiving the challenges from Let’s Encrypt. The shrubbery process acts as a validation of the web server’s identity. A combination of DNS challenges and shrubbery answers from the web server validates the identity of the web server.
Once identity has been verified, Let’s Encrypt issues the client a certificate. The web server administrator selects what level of security or client level compatibility desired, and Let’s Encrypt completes the configuration of the web server, including redirecting all traffic to the HTTPS site of the web server.
With all this in mind, these are the potential pain points that Let’s Encrypt could fix:
- Cost of certificates
- Steps to request certificates
- Time required to receive certificate
- Knowledge of encryption methodologies
- Knowledge of configuring https on a web server
Let’s Encrypt is currently in a limited beta. Let’s Encrypt’s method to validate ownership of a domain is new and needs testing at scale. Today, the project is Apache and NGINX focused with no existing support for Windows IIS.
I’m personally encouraged. The complexity of obtaining an SSL certificate and configuring a web server may become a thing of the past.
What do you think?
What will it take for you to use Let’s Encrypt over existing CAs? Share your thoughts in the comments section.