Why are free DV certificates only valid for 3 months or 1 year?

　　Regarding the validity period of free DV certificates, many people's first reaction is that "vendors are stingy"—after all, paid certificates can be purchased for two or even three years, while free ones only offer three months or a year, clearly aiming to increase renewal frequency and improve user stickiness. However, if you delve into the baseline requirements of the CA/B Forum (a standards organization jointly established by certificate authorities and the browser industry), the logic of certificate lifecycle management, and the business model behind free certificates, you'll discover that behind the numbers "three months" and "one year" lies a rigorous security strategy and industry game logic, not just a simple business tactic.

　　DV certificates, or Domain Validation Certificates, have a fully automated verification logic with zero human intervention—the CA only needs to confirm your control of the domain name, either by resolving specific TXT records, placing a file with specified content in the website's root directory, or receiving a verification email in the administrator's email address; the entire process can be completed in seconds. This convenience brings a fatal problem: the certificate is completely decoupled from the real identity of the subject; it only proves "you can operate this domain name," never "who you are." In other words, if a malicious script briefly gains DNS resolution privileges on your server, it can automatically apply for a DV certificate for that domain for a man-in-the-middle attack, even though this privilege might only last a few minutes. If this certificate is valid for a year, it essentially gives the attacker a year's worth of "legitimate credentials." Even if you regain control of the domain afterward, the browser and client will still trust the abused certificate until it expires naturally. It is precisely because of this vulnerability in authentication that industry security experts have long advocated for shorter validity periods for DV certificates. Free DV certificates are precisely the preferred target for attackers to apply for in bulk, so vendors proactively compressing them to 90 days is essentially a compromise on security risk and a form of self-defense.

　　Now let's look at the actual offensive and defensive dynamics in operation. The longer the certificate's validity period, the longer the window for private key exposure, and the higher the probability of private key leakage—whether it's server intrusion, a developer's CI/CD pipeline leaking .key files, or an OpenSSL vulnerability leading to the capture of the private key in memory by a side-channel attack, the probability of these events increases exponentially over time. If a certificate has a one-year validity period, hackers have a full 12 months to use your private key to decrypt past TLS sessions or forge traffic. A three-month validity period means that even if a leak occurs, the attack window is reduced to a quarter, aligning with the industry's "minimize exposure" security principle. More importantly, free DV certificates have become a kind of "security testing ground" in the industry—when Let's Encrypt pioneered 90-day certificates in 2015, it explicitly stated that the design intention of this period was to "force automation," compelling website administrators to deploy ACME protocol for automatic renewal, which itself forces you to frequently verify domain control. The implicit benefit of this mechanism is that you need to confirm your continued administrative rights to the domain every three months. If the domain expires without renewal, the DNS is tampered with, or the email address is reclaimed, the certificate will automatically expire within three months, avoiding the awkward situation of "the certificate is still valid but the domain has changed hands." This "living control verification" is more practically secure than any static identity verification.

　　Some might ask: if 398 days is the hard limit, why do almost all paid OV/EV certificates issue the maximum of 13 months, while free DV certificates generally only offer 3 months? The core difference lies in the misalignment of "automation costs" and "manual verification costs." The issuance of paid certificates involves rigorous organizational identity verification—companies need to submit business licenses, verify contact persons by phone, and even obtain lawyer's letters of confirmation. The labor costs of this process can reach tens to hundreds of dollars. If repeated every three months, the verification fees alone would be astronomical. Therefore, paid certificates inevitably choose to "lock in users" for the maximum period allowed by regulations, reducing the operational burden of repeated verification. Free DV certificates are fully automated; a single API call completes domain ownership confirmation in seconds, and the marginal cost of renewal is close to zero. CA institutions face no technical obstacles in supporting longer validity periods. So why don't they simply offer 398-day certificates to appease users? Because the business model of free certificates dictates that it must control "trust costs"—CAs incur certain audit and compliance costs for each certificate issued. If free users were to use a single, annually valid certificate everywhere, the CA's liability risk would significantly increase. Shortening it to three months is equivalent to breaking down "long-term trust" into "short-term authorization." In the event of a security incident, the CA can use "change of domain control" as a reason to absolve itself of responsibility, a very clever design for hedging legal risks.

　　Another easily overlooked dimension is the revocation mechanism for root and intermediate certificates. Traditional CRLs (Certificate Revocation Lists) and OCSPs (Online Certificate Status Query) are extremely inefficient in actual deployments. Many clients' OCSP queries time out or are even ignored, preventing leaked certificates from being recalled in time. In this situation, shortening the validity period becomes the "dumbest but most effective" loss-mitigation method—rather than relying on an unreliable revocation mechanism, it's better to let the certificate expire quickly on its own. The National Institute of Standards and Technology (NIST) explicitly recommends in its SP 800-57 standard that the validity period of keys in high-risk scenarios should not exceed 90 days. This is precisely the standard that free DV certificates actively align with. When you choose a free certificate with only a three-month lifespan, you are passively practicing a "short-lived key" best practice, which is actually a plus in many enterprise security compliance systems.

　　Finally, returning to the regulatory level, the eIDAS regulation (the EU's Electronic Identification and Trust Services Regulation) and ISO 21188 have clear matching requirements for certificate validity and key length. Although they do not directly specify three months or thirteen months, they emphasize a core principle: certificate validity should be inversely proportional to key strength and hash algorithm strength. Currently, the commonly used RSA-2048 key and SHA-256 algorithm, in the absence of practical applications of quantum computing, have 398 days considered an "acceptable upper limit" by the industry. However, DV certificates, due to the lack of identity anchoring, naturally have a higher threat level in risk assessments than OV/EV certificates. Many Certificate Authorities (CAs) internal risk control models label DV certificates as "high-risk," automatically adjusting their issuance strategy from "maximum validity period" to "recommended validity period," which is typically 90 days in the industry. Therefore, when comparing why free DV certificates only offer three months or a year, you should look at it from a different perspective: it's not that free certificates are deliberately reducing your rights, but rather that paid certificates are forced to reach the legal limit due to commercial reasons, while free certificates have chosen a period closer to the essence of security—three months represents a "reasonable trust window for unauthenticated certificates under current technological conditions," while a year is the "regulatory cap." The difference between the two precisely reflects the era of internet security evolving from "trusting certificates" to "continuous verification." Next time you see a certificate expiration reminder, calmly run an automatic renewal script. Those few seconds of API interaction represent a silent security inquiry from the entire TLS trust system.