In this article, we will review the purpose of SSL certificates, explain how they work, and what SSL options StackPath provides.
What is SSL
Secure Sockets Layer (SSL) is a protocol for securing communication on the Internet. SSL provides a way for enterprises to encrypt data before sending it to users, preventing third parties from reading that data while it’s in transit.
The SSL protocol does this by making sure that any data transferred between users and sites, or between two systems, remains impossible to read. SSL uses encryption algorithms to scramble data in transit, preventing hackers from reading private information as it is sent over the connection. This information could be anything sensitive or personal which can include credit card numbers and other financial information, names and addresses.
Why use SSL
The SSL protocol is used by the large majority of online businesses to protect their customers, ensuring their online transactions, personal information, and passwords remain confidential. All web browsers have the ability to interact with secured sites so long as the site's certificate is issued by a trusted CA. To assure all connections to your website are secure, the HTTPS protocol must be enforced. HTTPS (HTTP over SSL or HTTP Secure) is the use of Secure Socket Layer or Transport Layer Security as a sublayer under regular HTTP application layering. HTTPS encrypts and decrypts user page requests as well as the pages that are returned by the Web server.
Differentiating HTTPS (left) from HTTP (right) in the browser bar
How SSL Works
When a browser attempts to access a website that is secured by SSL, the browser and the web server establish an SSL connection using a process called an “SSL Handshake”. Note that the SSL Handshake does not share its private key, and happens almost instantaneously.
Essentially, three keys are used to set up the SSL connection: the public, private, and session keys. The public key is used to encrypt the session key, while the private key is used to decrypt the session key. Anything encrypted with the public key can only be decrypted with the private key and vice versa.
Because encrypting and decrypting with private and public key takes a lot of processing power, they are only used during the SSL Handshake to create a symmetric session key. After the secure connection is made, the session key is used to encrypt all transmitted data.
SSL request and server response process
What is an SSL Certificate
An SSL certificate is a data file that digitally binds a cryptographic key to an organization's details, and is necessary to create an SSL connection. In order to obtain an SSL certificate:
- a key pair (containing your public and private key) must be generated. These keys are used to authenticate, secure and manage secure connections. The public and private keys are created together as a pair when you create your CSR.
- a Certificate Signing Request must be generated. A CSR is a block of encoded text that is usually generated on the server where the certificate will be installed. The CSR contains the necessary details required to apply for a certificate such as the organization name, domain name, and country. The public key is inserted to the CSR and sent to the Certificate Authority (CA).
- Following successful authentication of all details, you will be issued an SSL certificate, which is matched to your private key.
What is the SSL Certificate Chain
There are two types of Certificate Authorities: Root CAs and Intermediate CAs. The Intermediate CA supplies the necessary chaining to a trusted root in an SSL connection and acts as a link for trust. The usage of an intermediate certificate thus provides an added level of security as the CA does not need to issue certificates directly from the CA root certificate.
In order for your SSL certificate to be trusted, that certificate must have been issued by a CA that is included in the trusted store of your browser. If the certificate was not issued by a trusted CA, your web browser will check to see if the certificate of the CA that issued it was issued by a trusted CA, and will continue until either a trusted CA is found (at which point a secure connection will be established) or until no trusted CA can be found (in which case an error will be displayed). The list of SSL certificates, from the root certificate to the end-user certificate, represents the SSL certificate chain.
The structure of the SSL certificate chain
Obtaining an SSL Certificate
StackPath customers can receive a free, private SSL certificate for each CDN or WAF site they create on the StackPath platform, ensuring their end users’ traffic is encrypted from the web browser to the content or web application. This certificate is ideal when using a full site integration with StackPath’s CDN and will ensure the security of your data between the Origin server and the CDN. This certificate can be requested within the portal or via API call. Please note, this certificate is used to secure connections to the CDN and cannot be downloaded for use on other services.
SSL Certificates from your Web Host
Many web hosts today offer SSL certificates for free as part of their packages, in order to maintain competitiveness in the market. It is the easiest way to get an SSL certificate and you usually can use their support in case you need a helping hand. A web host-provided SSL certificate can be uploaded to secure any data passed between the CDN and the end user.
If your needs aren’t met solely by the EdgeSSL certificate or provided by your web host, you can source an SSL certificate of your choosing and administer it yourself.
Security Tips When Implementing or Using an SSL Connection
- Don’t share your private key in plaintext. If your private key is exposed to anyone unintended, your encryption is compromised and therefore untrustworthy.
- Look for the green padlock in the address bar. This is the easiest way to check whether HTTPS is enforced on the page you’re viewing.
- Ensure your certificates include the subdomains you’ll be using. This will prevent site visitors from getting certificate errors.
- Disable support for weak ciphers. Almost all web servers support 128-bit or 256-bit encryption ciphers, but many also support weaker encryption ciphers that can be exploited by hackers.