As a web developer or architect, you work with SSL certificates every day. Even if you’re not the one managing these certificates, any internet-facing app you work with is almost certainly served over an SSL-encrypted connection. The SSL standard has evolved over time into Transport Layer Security (TLS), and modern browsers will reject connecting to a website that’s incorrectly secured.
While we typically think of banking and eCommerce as ideal use cases for SSL, in reality it provides a fundamental level of communication security for a variety of applications and workload types that communicate across the public internet.
If a mobile app has a user login, it should use SSL/TLS. If a website has a “contact customer support” form, it should use SSL/TLS — as should anything with forms or “submit” button. Pretty much anything connected to the internet that sends data upstream — back to a website or API — should use SSL/TLS.
SSL is valuable even if a site doesn’t accept user input. It’s easy to snoop on unencrypted HTTP requests on shared networks and see exactly what pages other users on the network are requesting from websites. When all connections to a site are SSL/TLS encrypted, however, external observers can only see the IP address the request was sent to.
Finally, SSL is valuable beyond just securing HTTP requests. The WSS (WebSocket Secure) protocol uses SSL/TLS certificates to establish encrypted bidirectional WebSocket connections.
This article provides a practical introduction to SSL and TLS and suggests some ways to ease implementation.
Ivan Ristić developed SSL, and Netscape adapted the technology for Navigator, the first commercial web browser, in 1994. They realized that the burgeoning internet needed secure protocols for consumers to trust online commerce.
The SSL standard has evolved, changing encryption algorithms, including switching from SHA1 to SHA2 and increasing the number of bits those algorithms use from 256 to 2048.
SSL is now called TLS. Many technical details have changed with security holes plugged over the years. The basics are the same and rely on Public Key Infrastructure (PKI). Certificates used in PKI can be validated and trusted.
For example, if we want a TLS certificate for our website, we contact a certificate authority (CA). Assuming the CA is delegated to a registration authority (RA), the RA ensures we own the domain and verifies our identity to the CA. The CA creates a certificate (a string of letters, numbers and symbols) tied to our domain and issues the certificate to us. We then install the certificate on our web server.
The certificate has a chain that a consumer’s browser can trace to the trusted CA. The browser then uses this certificate to encrypt communications with the server. In this way, should web traffic be intercepted (in what’s known as a person-in-the-middle attack), the data will not be usable. While there is a theoretical chance that someone might eventually decode the transmission, it is fully secure in practice.
The current, widely supported standard is TLS 1.2. In many cases, browsers reject connections to insecure (no TLS) or outdated protocols. Additionally, compliance requirements, such as the Payment Card Industry Data Security Standard (PCI DSS), drive encryption standards.
You can quickly check if your website supports TLS 1.2 with tools like DigiCert SSL Tools. Look at your server configuration to see what protocols it uses. TLS 1.2 should be enabled, and older protocols such as SSLv3, SSLv2, TLS1.0, and more, should not be enabled. Payment processors also provide ways to test your integration.
If your web server is not using at least TLS 1.2, what can you do? Setting up TLS 1.2 can be complicated. It may involve both server changes and developer tool changes.
For Windows servers, registry entries enable TLS 1.2 and disable other protocols. The TLS/SSL settings are found here:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols
You will likely have to add these keys to the registry manually.
This screenshot shows SSL 2.0 disabled:
The following screenshot shows TLS 1.2 enabled:
On Linux and Unix, the settings are in configuration files and vary depending on server software. Tools such as this NGINX configurator help.
You may need to update your development tools. For example, .NET 4.6.2 and above support TLS 1.2. You will have to update older versions of .NET.
Java 8 uses TLS 1.2 as the default protocol. For Java 7, the default is TLS 1.0. There are ways to add TLS 1.2 to the Java command line or set it when using SSLSockets or SSLContext.
Each runtime or library dealing with HTTPS, sockets, or other communication methods might have different approaches, but you should find support easy to come by.
A simple certificate protects one website subdomain, such as www.mydomain.com. If you have multiple subdomains, a wildcard certificate, *.mydomain.com, is more cost-effective. One Wildcard SSL certificate can cover web addresses such as www.mydomain.com, portal.mydomain.com, and api.mydomain.com.
Certificates are available with different levels of validation:
Domain Validation – DV
Organizational Validation – OV
Extended Validation – EV
Installing and managing SSL certificates can be time-consuming, complicated, and open to configuration mistakes. To obtain a certificate for your server, you first need to create a certificate signing request (CSR). Certificate providers have tools to do this. Web servers such as Microsoft IIS can create a CSR and install the certificate when issued. A handy standalone tool is OpenSSL.
Using the CSR, you can request a certificate from your CA after purchasing the type you want. Once issued, you download the certificate text file, upload it to your server, and install it. Details of the installation vary. No matter the path and tool, the certificate is installed in a certificate store on the server where it is available for secure connections.
Managing one certificate on one server is not too difficult. When the number of servers across multiple cloud regions grows, renewing, installing, tracking, and debugging certificates becomes more complicated, increasing the risk of errors.
Managed SSL providers take the certificate management load off your staff. One example is content delivery network (CDN) services for edge delivery and security.
Using a service like StackPath CDN enables you to set up SSL for your domain with just a few steps and changes to your DNS, pointing your domain to StackPath. StackPath then handles all traffic coming to your domain and passes requests to your web server.
You can upload your SSL certificate or take advantage of the free dedicated certificate from StackPath using Let’s Encrypt. You can force HTTPS connections and select the TLS level, although TLS 1.2 is the current recommendation.
SSL certificates served from the edge take the load of serving certificates off of your server. Now, public web traffic hits the StackPath edge server and does not have to travel all the way to your server.
Your site’s requests are cached and potentially delivered from the CDN, not your server, protecting you from denial-of-service (DoS) attacks. The encryption and SSL certificates are also delivered from the edge and will not burden your servers.
You can write custom rules for directing traffic, customize caching, or even purge the cache with this tool. Besides easy control of CDN behavior, you have access to analytics to monitor traffic and see which requests are handled by the CDN or forwarded to your server.
Visit StackPath to learn more about EdgeSSL.
Securing web endpoints is critical to the safe operation of your business. Browsers, servers, and developer tools widely support SSL and TLS certificates, but managing these certificates can be time consuming and risky. Using a managed edge SSL provider makes it quick and easy to add and manage SSL in your web apps and services and offload public traffic from your servers.
If you’re ready for worry-free certificate management, StackPath customers get a free private SSL certificate using StackPath WAF, as well as a free private SSL certificate per site using our StackPath CDN. Visit the EdgeSSL page to learn more.
