Are you currently experiencing an attack?

Are you currently experiencing an attack?

SSL Management and the Cloud

SSL encryption is a vital part of the Internet today. But for many traditional sites, SSL management is performed by the hosting providers. As organizations migrate to cloud, SSL management becomes an issue that many executives need to understand better.

As users and customers interact with web applications, they provide PII (Personally Identifiable Information). The applications need to protect this data, and SSL is necessary for shielding it while in transit. A failure to do this properly can result in legal consequences and fines. Fortunately, this task has become much easier than it used to be, and the technology for securing this data has become widely available and inexpensive. Further, the cloud makes SSL management straightforward.

What is SSL?

SSL stands for Secure Socket Layer: a protocol for authenticating and encrypting communication across a network. SSL is an older technology, and has been superseded by TLS (Transport Layer Security). However, it is still common to refer to SSL (as this article will do), even when TLS is actually being used.

Websites are typically served via HTTP (Hypertext Transfer Protocol) on port 80. Sites secured with SSL are served over HTTPS (S for “Secure”) on port 443.

SSL creates a secure “tunnel” between a web application and its user. Data is encrypted on the user’s device, passes across the Internet, and is not decrypted until it reaches the destination web application. The same is true in the opposite direction when the web application passes data back to the user. This process keeps the data private; even though the traffic travels through the public Internet, it cannot be spied upon or intercepted by a third party.

Modern Internet commerce would not be practical if it were not for the trust that SSL provides. For example, SSL enables a website user to enter sensitive information (such as a credit card number) into a web application, and be confident that this information won’t be stolen or intercepted while in transit.

Along with enhanced security, there are other reasons for site owners to implement SSL. For example, Google ranks HTTPS pages higher in its search results. Sites secured with SSL get a free SEO boost, which can be crucial for increasing page views and site visits. Furthermore, many browsers (such as Chrome) warn users when they visit sites that are served without SSL. Thus, these sites are less likely to receive traffic, and even when users arrive, the sites will have a higher bounce rate and probably a lower conversion rate as well.

In addition to this, SSL now has a relatively low cost of implementation. All things considered, there are very few reasons today for site owners to decide against implementing SSL.

How Does SSL Work For a Traditional Website?

Let’s discuss a basic, hypothetical infrastructure that might be used to run a “traditional” website. For simplicity’s sake, assume that the site is a classic LAMP (Linux, Apache HTTP server, MySQL, and PHP) stack, such as a WordPress blog, and that it is contained entirely within a single host. The domain name for the site will likely reside within a typical registrar, such as Namecheap.

When a user interacts with the site (usually through a web browser, or perhaps via a mobile application—referred to generally below as the “client”), the following process occurs:

  1. Initial connection: The client makes a DNS query and obtains the web server’s IP address. The client then initiates a TCP connection with the destination server.
  2. Handshakes: The client initiates the handshake process, sending a “hello” message to the server. The server responds with a message that contains, among other things, its SSL certificate. The certificate contains information about the owner of the domain, and a public encryption key.
  3. Certificate Verification: The client contacts the certificate authority (CA) that issued the SSL certificate, verifying that the client is interacting with a server belonging to the expected domain owner, and not an imposter.
  4. Session Keys: The client and server generate matching session keys, using data from the previously exchanged messages. If these do not match, the session will be terminated.
  5. Ready and Symmetric Encryption: If there is a match, both the client and server send a “finished” message encrypted with the session key. This signals that the handshake is complete, and a secure symmetric encryption link is established for use during the session.

Since this hypothetical site is hosted entirely on one server, the management and security of the site is quite simple. The Apache software handles all inbound web traffic, as well as SSL configuration and termination. Database connections occur on the same host and do not traverse public networks.


Despite this relative simplicity of implementing SSL, there are some downsides. Managing and renewing the SSL certificate is a manual process. Terminating SSL traffic imposes a resource cost on web servers, even before any actual traffic is served. If the amount of traffic to a site exceeds the resource capabilities of the underlying host, it can be very difficult to scale or expand without a significant increase in cost as well as a negative impact on user experience until you can alleviate load issues.

Modern sites and web apps that wish to avoid these issues typically embrace two key design methodologies: distributed systems and cloud computing.

How Does SSL Work in the Cloud?

For starters, the SSL part isn’t all that different—it just takes place somewhere else. The “somewhere else” part highlights the key difference from our previous example: The various components of the system are distributed across both systems and geographic regions. Let’s revisit our hypothetical site architecture, except that now we’re going to migrate it to a distributed, cloud-hosted infrastructure.

You still have to register the domain name; however, most cloud providers provide their own DNS management system, which allows registration as well as additional features to ease the management of larger-scale deployments.

Since this is a geographically distributed system, the site will need to be able to handle requests from different parts of the world. On the frontend, a global CDN will handle serving static content that benefits from close geolocation. A global load balancer will handle routing requests to site infrastructure located closest to the requesting user. Tracing the path of hypothetical user traffic, a request is routed to the appropriate regional infrastructure, typically identical in design to sibling infrastructure in other global regions.

Each of these regions contains a reverse proxy that manages traffic for the actual site infrastructure. The site infrastructure itself might be individual nodes or a one-to-many, many-to-one, or many-to-many arrangement of frontend, backend, and database nodes. The key piece of this design, in the context of SSL, is the reverse proxy server.

What Is a Reverse Proxy?

A reverse proxy is a specialized server that intercepts client-request traffic bound for a web server. With a reverse proxy in place, clients never actually communicate directly with the actual web hosts behind any given site–they are only aware of the reverse proxy itself.

Since the reverse proxy is handling client traffic before it ever reaches the actual backend hosts, it can provide several benefits:

  • Load balancing: The proxy can route traffic to a pool of backend hosts, ensuring no one host is overburdened with traffic. Additional hosts can be added to the pool easily, allowing the site to scale to meet increased traffic demands.
  • Web security: A web security platform such as Reblaze acts as a reverse proxy, receiving incoming traffic and blocking malicious requests. (Reblaze includes DDoS protection, a next-gen WAF, advanced bot mitigation, API security, and more.) This prevents threat actors from reaching the backend network.
  • SSL Management/Termination: The entirety of SSL logistics can be offloaded to a reverse proxy, including the resource-intensive encryption/decryption cycle, as well as the administrative management of the SSL certificates.

As companies and sites grow, they may potentially use several SSL certificates. Some types of web applications (especially those with many subdomains) require dozens or even hundreds of them. Managing and monitoring a variety of certificates can be a challenging technical hurdle. Allowing even one certificate to expire might result in thousands of users receiving a dire security warning from their browser, as well as a newfound skepticism of your ability to protect their critical data.

Managing SSL Certificates for a Traditional Site

Think back to the example of the classic, single-host site. Manually managing the SSL certificate for even a single site is often a tedious, error-prone process, involving multiple steps that usually require knowledge of the command line. If you extrapolate that process out to multiple sites or certificates, it quickly becomes unmanageable.

True, it’s easier to generate certificates than it used to be. For example, the Let’s Encrypt service has alleviated the burden for site owners somewhat. Nevertheless, it still requires manual configuration on an individual host.

Managing SSL Certificates on the Cloud

Organizations which migrate to cloud receive a variety of benefits, from cloud-native architecture to the ability to use DevOps and (even better) DevSecOps.

SSL management becomes easier too, although the underlying structure is a little different. (Here, instead of SSL encryption being used between the client and server, it occurs between the client and the reverse proxy. If the reverse proxy runs within the same cloud structure as the backend server, HTTP traffic might be used between them instead of HTTPS, to save the extra overhead of encryption/decryption.)

Reverse proxy solutions often include SSL management capabilities, enabling you to renew and manage certificates with the push of a button. Some solutions will even renew them for you automatically.

Automatic Certificate Renewal

One of the most common failures in managing SSL certificates is in their renewal and expiration. If site owners have to repeatedly engage in a tedious, time-consuming process to renew their certificates, they are likely to put it off. Monitoring certificate expiration often amounts to entering an appointment in a calendar and hoping it’s not missed.

Reblaze offers built-in certificate management, ensuring that site owners and administrators can manage their SSL posture effectively in a fraction of the time. With its Let’s Encrypt integration, Reblaze can monitor and automatically renew certificates before they expire.

Choosing a Certificate Authority

SSL certificates can be obtained from any reputable CA. First, a choice must be made between Let’s Encrypt and a traditional, paid CA. There are two primary issues that must be considered.

The first is validation levels. Let’s Encrypt provides DV (Domain Validation). Domain validation is an automated, technical check that verifies that the owner controls the domain, either by email or by asking the requestor to add a unique piece of data to their site.

Most paid CAs offer the additional validation levels of OV (Organization Validation) and EV (Extended Validation). OV will verify the organization, while EV includes additional verification about the organization from a third party (such as a Certified Public Accountant).

Which level of validation is necessary for an organization? OV and EV certificates are certainly more prestigious, and some browsers will reflect them differently in their displays. However, there is not much additional practical difference. In the future, OV and EV might be necessary for compliance with standards such as PCI, but at the current time, DV is sufficient.

The second issue arises from the CA’s warranty and support. If a certificate authority were ever compromised in some way, and a malicious entity gained access to its master keys, any site secured with its certificates would potentially become vulnerable to traffic interception and PII theft. Many paid CAs offer warranties against this, while Let’s Encrypt (which is a free service) does not. However, the presence or absence of such a warranty arguably does not change the likelihood of compromise. And if such a compromise did occur, affected sites could quickly get new certificates issued from a different CA anyway.

Management and Provisioning of Certificates

With the management features offered by a platform such as Reblaze, the tedium of manual administration is replaced with a UI that vastly simplifies the entire process.

Reblaze imports existing certificates (all you need to do is provide a PF file), or can generate new ones for free using Let’s Encrypt. The certificate is immediately available and ready for provisioning. You can assign the certificate to a load balancer, and then assign it to a specific application. If there is an existing certificate already attached, you’re provided with a push-button option to replace it. And as certificates expire, Reblaze can renew them automatically.

Many of the above capabilities are found within other web security solutions as well. However, Reblaze offers a key difference: it treats certificates differently than most other security solutions.

Saving Money on Large Numbers of Certificates

It’s not unusual for some companies (especially SaaS platforms) to have dozens or even hundreds of certificates to manage. Unfortunately, most security solutions treat each SSL certificate as a separate “site,” and they charge their customers on a per-site basis. Thus, these solutions can be extremely expensive.

Contrary to this, Reblaze does not treat certificates as sites. A certificate is merely a certificate. For customers with tens or hundreds of certificates to manage, Reblaze’s monthly pricing can be one or two orders of magnitude less than its competitors’.

When multiplied over multiple sites, certificates, and regions, the time (and potentially money) saved by using Reblaze for SSL management is significant.


The modern internet is a robust ecosystem of information exchange, as well as a vast marketplace for a variety of goods and services. It is more critical than ever to ensure that those exchanges of information and transactions are properly secured and protected.

The good news is that SSL, which was once costly and difficult, has become inexpensive and straightforward, especially for organizations which move to cloud.

Get your price quote

Fill out your email below, and we will send you a price quote tailored to your needs

This website uses cookies to ensure you get the best experience on our website.