As a monitoring and observability company, we have a lot of monitoring built into our systems as well. We have the standard monitoring to make sure that systems are performing properly, data is flowing through our infrastructure, etc. At the same time, we have monitoring for any sudden changes to tests that our customers are running.
On September 29, 2021, at 19:21:40 UTC, we started to see a tsunami of alerts at Catchpoint. They originated from some of our web tests from our synthetic nodes, occurring when our Let’s Encrypt “R3” certificate expired. These types of incidents are pretty rare.
Docker is a popular open-source containerization platform and it frees your hands to build your applications in development and production. In this post, I'm going to walk you through how to build a production-grade HTTPs secured Nginx server with Docker, Docker Compose, Let’s Encrypt (its client certbot). Let’s Encrypt certificates last 90 days and will need to be renewed after the certificate expires. So I will also provide details to script the renewal in crontab in Docker container.
1. Basic Example
In development, we need a basic Nginx container without HTTPs to fast setup our local test environment. I use Nginx official docker image and wrap up all the stuff with docker-compose.
Beginning September 1, 2020, Apple’s Safari browser will no longer trust SSL/TLS certificates issued for longer than 398 days, which is the equivalent of one year plus the renewal grace period. Apple cited its “ongoing efforts to improve web security” in the announcement earlier this year. The change affects the full lineup of Apple platforms:
This change will affect only TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS. Additionally, this change will affect only TLS server certificates issued on or after September 1, 2020; any certificates issued prior to that date will not be affected by this change.
Apple will begin enforcing the change immediately, which means it will deny connections to TLS servers that don’t meet the new requirements. After Apple’s announcement, both Google and Mozilla contributors moved to propose their own implementations that cap certificate validity at 398 days.
All of the major certificate authorities are falling in line, changing their offerings to conform with the new one year limit. This includes CA market leader IdenTrust, which accounts for roughly 52% of SSL certificates. DigiCert, a CA that captures 20% of the market, published a dry note of compliance, emphasizing the burden it places on certificate users:
Why did Apple unilaterally decide to enforce a shorter certificate lifetime? Their spokesperson said it was to “protect users.” We know from prior CA/B Forum discussions that longer certificate lifetimes proved to be challenging in replacing certificates, in the case of a major security incident. Apple clearly wants to avoid an ecosystem that cannot quickly respond to major certificate-related threats. Short-lived certificates improve security because they reduce the window of exposure if a TLS certificate is compromised. They also help remediate normal operational churn within organizations by ensuring yearly updates to identity such as company names, addresses and active domains. As with any improvement, shortening of lifetimes should be balanced against the hardship required of certificate users to implement these changes.
The idea behind the change is that certificates with shorter life cycles are more secure, as compromised keys would expire on shorter timeframes. The new one-year expiration forces hosts and certificate providers to make automation a high priority. In fact, this is one of the reasons Let’s Encrypt’s free certificates already have a short 90-day life cycle. It was put in place years ago to encourage automation so that shorter lifetimes are no less convenient than longer ones.
Let’s Encrypt recommends subscribers renew every sixty days and may even consider recommending shorter lifetimes once automated renewal tools are more widely adopted. This may be happening sooner than anticipated now that Apple’s policy is forcing change across the industry.
Many WordPress users make use of Let’s Encrypt certificates using a plugin like WP Force SSL & HTTPS Redirect (100k+ active installs), SSL Zen (20k+ installs) or WP Encryption (20k+ installs). Some plugins have automatic renewal built in, but some offer it as part of a commercial upgrade. Others rely on hosts to perform renewals.
Although most website owners will not need to take action, the shorter certificate life cycle may can become a hassle without automated certificate management in place. It may also affect client billing with different options available from hosts and certificate authorities. If you manage websites for clients whose sites previously relied on certificates with longer life cycles, you will want to make sure to have some form of automated certificate management set up when the change goes into effect.
First, we are going to generate a wildcard SSL certificate for our domain, and then, we will see the process of integrating that certificate in engine yard. First, let’s get some insight about the terms we are going to use in this blog
What Is SSL and Why Is it Used?
SSL certificates are used to create an encrypted channel between the client and the server. Transmission of such data as credit card details, account login information, any other sensitive information has to be encrypted to prevent eavesdropping.
From field experience, I must affirm that one of the greatest and stable combinations I've seen is Java Application Servers + Reverse Proxies. Although some of the functionality is a clear overlap, I tend to put reverse proxies in front of application servers for the following reasons (please see this NGINX page for more details):
Load balancing: The reverse proxy acts as a traffic cop and could be used as an API gateway for clustered instances/backing services
Web acceleration: Most of our modern applications use SPA frameworks, hence it is worth caching all the JS/CSS/HTML files and freeing the application server from that responsibility
Security: Most HTTP requests could be intercepted by the reverse proxy before any attempt against the application server, increasing the opportunity to define rules
SSL Management: It is easier to install/manage/deploy OpenSSL certificates in Apache/NGINX compared to Java KeyStores. Besides this, Let's Encrypt officially supports NGINX with plugins.
Requirements
To demonstrate this functionality, this tutorial combines the following stack in a classic (non-Docker) way, though most of the concepts could be useful for Docker deployments:
