The Case for Serving Multiple HTTPS (SSL) Certificates Regionally

DZone 's Guide to

The Case for Serving Multiple HTTPS (SSL) Certificates Regionally

The case for serving different HTTPS (SSL) certificates based on regions for companies hosting web applications in multiple regions.

· Security Zone ·
Free Resource


In this new world of cloud computing, more and more companies are going global.

Regardless of whether a company is built solely in the cloud or hosting their application in their own data centers, we see (and predict) a surge of applications deployed to multiple regions for reasons such as to decrease latency, cater to a targeted audience, compliance requirements, and so on.

Companies also, often deploy their application in only one region, use CDN and caching to serve globally, and terminate their SSL usually in a load balancer or even before load balancer in some cloud infrastructure.

As a general rule of thumb, these web applications only expose their endpoints over HTTPS for transport layer security. Most of these web applications use a single SSL certificate issued by the Certifying Authority for their domain name.


While this is a widely accepted practice,  the problem arises (or may arise in the near future) when their SSL security is compromised. 

While there are a plethora of reasons we can look into, to identify how SSL security can be compromised (or hypothetically at least), let us assume, in this case, that a malicious hacker is somehow able to hack the private key which is stored securely at the SSL terminator in a vault or key-store. 


In that case, hackers can easily craft man-in-the-middle (MITM) attacks to decrypt the bi-directional flow of data packets over HTTPS for a large number of users in that region. This does not only have the potential to bring the business of the company down but their users will be hugely affected. We are not going to get into the details of how destructive the compromise can be for a business even if there is less than 0.0001% chance of happening.


As a mitigation mechanism, what could work in the near-term is to use different SSL certificates for different regions or even sub-regions. So for example, if SSL security in one of the regions gets compromised, then the transport integrity of other regions is not affected. 

Disaster Recovery

Because the domain name is globally the same, traffic of the affected region can be routed to other regions by a simple configuration in the routing services (like AWS Route 53), although that will increase latency, but will at least give the business some time to breathe while they plan for the disaster recovery of the compromised region by replacing the installed key-pair and increase its protection.

Therefore, as a result, by using different SSL key-pairs for different regions or for different SSL terminators, you are isolating(at least from a networking standpoint) a compromised portion of the network from unaffected parts.

Future Considerations

In the longer-term, I would propose not only using different SSL key-pairs per region but also using multiple key-pairs per region and rotating them often. This will mitigate the risks at a much greater scale but to establish this practice, more support is needed from the community.

Useful Links


Hussain G.

cloud security, disaster recovery, https, network security, security, ssl

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}