The advent of the World Wide Web, based on the HTTP (HyperText Transfer Protocol) protocol, introduced an incredible ability to connect information, but it did so by leaving a fundamental vulnerability: the lack of intrinsic security.
The traffic exchanged between a user and a server traveled in plaintext, a flaw that opened the door to a multitude of attacks. Malicious actors, using relatively simple tools, could intercept and read the entire conversation. Some will shudder recalling tools like Firesheep, which exploited this insecurity to make side-jacking trivial. This allowed the theft of active sessions from PCs connected to the same Wi-Fi network, granting access to social profiles or services as if the attacker were the legitimate user.
But the risks went far beyond simple interception: the lack of identity verification allowed attackers to impersonate a legitimate server (man-in-the-middle attacks) with the goal of stealing sensitive credentials, distributing malware, or committing fraud.
Faced with such a scenario, the need to protect communications and guarantee the authenticity of the parties involved strongly emerged. It was essential to ensure that the website the user was interacting with was actually the declared one and that the communication was incomprehensible to prying eyes. The solution to this dual problem was the evolution of HTTP into the HTTPS (HTTP Secure) protocol, achieved through the adoption and extension of the X.509 digital certificate system. These certificates, issued by trusted third-party organizations called Certification Authorities (CAs), play a crucial role.
Digital certificates fulfill two central and complementary functions for the security of web communications. The first function consists of enabling communication encryption, typically through protocols like SSL/TLS, which is an essential step to ensure the confidentiality and integrity of the data exchanged between parties.
In parallel, certificates are fundamental for validation and the fight against impersonation. This occurs because the issuance of a certificate by a Certification Authority (CA) is subject to the verification of domain ownership by the applicant. This mechanism ensures that the user's browser, by trusting the CA, obtains the necessary proof to validate that the server it is interacting with is actually who it claims to be, thereby preventing fraud attempts or man-in-the-middle attacks.
The introduction of this mechanism marked a turning point for web security.
However, the mass adoption of HTTPS was not immediate. For years, many websites(particularly personal blogs, small artisan sites, or less "critical" portals) continued to operate on insecure HTTP.
The reasons were often economic and logistical: certificates, although not prohibitively expensive (around ten euros a year or slightly more), still represented a fixed expense that was not always perceived as indispensable. Consequently, unprotected connections were frequently used, or, in an attempt to save money, self-signed certificates were employed. The latter, while guaranteeing encryption, were not issued by a recognized CA. As a result, browsers considered them untrusted, forcing users to manually confirm a security exception. This created a sub-optimal user experience and, above all, sent an ambiguous signal regarding security.
In the realm of home banking and e-commerce, however, maximum reliability is required. For a period of time, Extended Validation (EV) certificates were used in an attempt to further improve the certainty of being connected to the right site. This type of certificate could only be obtained through the verification of company documentation and involved a high cost, limiting its use to entities with specific needs. In return, users with this certificate saw the company name on a green background in the browser bar alongside the URL. We say "saw" in the past tense because this option was removed. It proved largely ineffective in protecting users, as certification authorities often failed to conduct truly in-depth checks.
The epochal turning point in the landscape of web security and certificate management arrived in 2016 with the public launch of Let's Encrypt.
This initiative, promoted by prominent organizations such as the Electronic Frontier Foundation (EFF), the Mozilla Foundation, and Cisco Systems, introduced a revolutionary concept: a fully automated certification authority (CA) that offers free X.509 certificates.
The impact of Let's Encrypt was immediately perceived as extremely positive, particularly by system engineers and server administrators.
The keystone was the introduction of tools like certbot, a software client that automates the entire lifecycle of the certificate. After a single initial configuration on their web servers, which could include setting up domain challenges like HTTP-01 or DNS-01 for domain ownership verification, administrators could finally eliminate the worry associated with renewals.
This change not only drastically reduced operational costs and the probability of service interruptions due to expired certificates, but it also contributed significantly to the global increase in HTTPS adoption, pushing the web towards a higher baseline level of security. The automation provided by Let's Encrypt and certbot transformed a manual, repetitive, and error-prone task into a process managed in the background, allowing system engineers to focus on higher value-added activities. The adoption of certificates on the web was further accelerated by the introduction of the same mechanism on the Cloudflare CDN. The latter made it possible to add encryption between the edge and the user's device via the "Flexible" configuration. Although not the most secure option, it offers security benefits for the end user without requiring server-side configurations, making it particularly useful for hosting providers that had not yet integrated Let's Encrypt.
With this absolute proliferation of certificates, especially those distributed through automated systems, a radical change arrived from the most popular browsers regarding how they communicate a website's reliability to the user. A website using a certificate is no longer merely considered "secure"; rather, sites without HTTPS are now deemed downright "dangerous", displaying risk warnings and banners to the user before connection.
Another disruptive novelty brought about by this new paradigm is the drastic reduction in the maximum lifespan of an issuable certificate. It began in 2015 by fixing the duration at three years, dropping to two in 2018, and finally to just one in 2020 to stimulate a more frequent rotation of keys.
The widespread diffusion of certificates, particularly those issued automatically, triggered an epochal shift in how browsers communicate a website's reliability to users. Today, the use of a certificate is no longer the distinguishing feature of a "secure" site; conversely, the lack of HTTPS makes sites "dangerous", pushing browsers to display warnings and banners about risks before establishing a connection.
Today, we are in a phase of further change. Authorities and browsers are pushing for even shorter durations to force the adoption of automation; in the future, the maximum duration of certificates will shrink even further. Here is what is expected for the coming years: the limit will drop to 200 days by March 15, 2026, to 100 days by March 15, 2027, and the maximum duration will be only 47 days by March 15, 2029. The goal is to make certificates "disposable". If a certificate lasts only a few weeks, a hacker who steals its key has very little time to exploit it. Furthermore, if a vulnerability is discovered in an encryption algorithm, the entire web can migrate to a new one in less than two months simply by waiting for the natural renewal of certificates.
| Date | Maximum Certificate Lifespan | Technical Verification |
|---|---|---|
| 2015 | 3 years | Capped at 39 months |
| 2018 | 2 years | Capped at 825 days |
| 2020 | 1 year | Capped at 398 days by Apple/Google |
| March 15, 2026 | 200 days | Phase 1 of the new CA/B mandate |
| March 15, 2027 | 100 days | Phase 2 of the new CA/B mandate |
| March 15, 2029 | 47 days | Phase 3 of the new CA/B mandate |
The adoption of an automated system for the renewal and management of digital certificates is no longer a simple 'commodity' or a choice of convenience, but a mandatory operational and security constraint for any organization. In the current cybersecurity landscape, where certificate expiration is increasingly brief (short-term certificates, or short-lived certificates), manually installing a certificate or relying on manual processes for its renewal now constitutes a significant technical debt.
The transition to a short-lived certificates policy should not be seen as a bureaucratic burden for IT, but as a catalyst for indispensable infrastructural modernization. The goal of the Certification Authorities is clear: they want to reduce the risk in the event that security keys are compromised, and they also want to accelerate the adoption of more robust cryptographic standards. This, however, makes it impossible to manage the entire process manually.
In modern container-based architectures, where services are dynamically created, deleted, and scaled, automating the certificate lifecycle (i.e., issuance, renewal, distribution, and revocation) is not just a best practice, but a fundamental requirement to ensure compliance and service continuity. Platforms that manage large-scale workloads, such as Kubernetes, need integrated tools to manage identity and cryptography. In this context, solutions like Cert Manager become essential. Integrated on Kubernetes, Cert Manager automates communication with Certification Authorities (such as Let's Encrypt or internal CAs), ensuring that each service (Pod, Ingress, or Route) has a valid certificate that is automatically renewed. This eliminates the possibility of service interruptions due to unexpected expirations.
For traditional systems or hybrid infrastructures that do not use Kubernetes-native platforms, automation can be managed through Configuration Management tools like Ansible. In this scenario, Ansible acts as an orchestrator, deploying and configuring the Certbot utility on individual operating systems (web servers, load balancers, etc.). Using configuration files called playbooks, Ansible can ensure that Certbot is installed and configured correctly, execute Certbot to obtain and renew certificates from CAs like Let's Encrypt, distribute the obtained certificates to the correct services (for example, by configuring Nginx or Apache), and, finally, restart or reload the services to apply the new certificates. This method ensures that even older or non-containerized servers can benefit from the security offered by short-term certificates without requiring human intervention for each renewal.
The adoption of short-term certificates forces organizations to definitively abandon the era of manual renewals. Investing in automation tools, whether it is Cert Manager on Kubernetes or orchestrating Certbot via Ansible, is not an expense, but a net gain in terms of security, operational efficiency, and the reduction of so-called technical debt. In this way, what seemed like a "nuisance" turns into a real opportunity to improve the digital infrastructure.