Starting September 13, 2024, the maximum lifetime for publicly trusted TLS certificates will be reduced to 398 days (effectively 47 days due to calculation specifics). This change, driven by the CA/Browser Forum, aims to improve security by limiting the impact of compromised certificates and encouraging more frequent certificate renewals, promoting better certificate hygiene and faster adoption of security improvements. While automation is key to managing this shorter lifespan, the industry shift will require organizations to adapt their certificate lifecycle processes.
This blog post explores how a Certificate Authority (CA) could maliciously issue a certificate with a valid signature but an impossibly distant expiration date, far beyond the CA's own validity period. This "fake future" certificate wouldn't trigger typical browser warnings because the signature checks out. However, by comparing the certificate's notAfter date with Signed Certificate Timestamps (SCTs) from publicly auditable logs, inconsistencies can be detected. These SCTs provide proof of inclusion in a log at a specific time, effectively acting as a timestamp for when the certificate was issued. If the SCT is newer than the CA's validity period but the certificate claims an older issuance date within that validity period, it indicates potential foul play. The post further demonstrates how this discrepancy can be checked programmatically using open-source tools.
Hacker News users discuss the practicality and implications of the blog post's method for detecting malicious Sub-CAs. Several commenters point out the difficulty of implementing this at scale due to the computational cost and potential performance impact of checking every certificate against a large CRL set. Others express concerns about the feasibility of maintaining an up-to-date list of suspect CAs, given their dynamic nature. Some question the overall effectiveness, arguing that sophisticated attackers could circumvent such checks. A few users suggest alternative approaches like using DNSSEC and DANE, or relying on operating system trust stores. The overall sentiment leans toward acknowledging the validity of the author's points while remaining skeptical of the proposed solution's real-world applicability.
Firefox now fully enforces Certificate Transparency (CT) logging for all TLS certificates, significantly bolstering web security. This means that all newly issued website certificates must be publicly logged in approved CT logs for Firefox to trust them. This measure prevents malicious actors from secretly issuing fraudulent certificates for popular websites, as such certificates would not appear in the public logs and thus be rejected by Firefox. This enhances user privacy and security by making it considerably harder for attackers to perform man-in-the-middle attacks. Firefox’s complete enforcement of CT marks a major milestone for internet security, setting a strong precedent for other browsers to follow.
HN commenters generally praise Mozilla for implementing Certificate Transparency (CT) enforcement in Firefox, viewing it as a significant boost to web security. Some express concern about the potential for increased centralization and the impact on smaller Certificate Authorities (CAs). A few suggest that CT logs themselves are a single point of failure and advocate for further decentralization. There's also discussion around the practical implications of CT enforcement, such as the risk of legitimate websites being temporarily inaccessible due to log issues, and the need for robust monitoring and alerting systems. One compelling comment highlights the significant decrease in mis-issued certificates since the introduction of CT, emphasizing its positive impact. Another points out the potential for domain fronting abuse being impacted by CT enforcement.
Summary of Comments ( 85 )
https://news.ycombinator.com/item?id=43693900
Hacker News users generally express frustration and skepticism towards the reduced TLS certificate lifespan. Many commenters believe this change primarily benefits certificate authorities (CAs) financially, forcing more frequent purchases. Some argue the security benefits are minimal and outweighed by the increased operational burden on system administrators, particularly those managing numerous servers or complex infrastructures. Several users suggest automation is crucial to cope with shorter lifespans and highlight existing tools like certbot. Concerns are also raised about the potential for increased outages due to expired certificates and the impact on smaller organizations or individual users. A few commenters point out potential benefits like faster revocation of compromised certificates and quicker adoption of new cryptographic standards, but these are largely overshadowed by the negative sentiment surrounding the increased administrative overhead.
The Hacker News post titled "TLS Certificate Lifetimes Will Officially Reduce to 47 Days" generated a significant discussion with various perspectives on the implications of shorter certificate lifetimes.
Several commenters expressed concerns about the increased operational burden associated with more frequent certificate renewals. One commenter highlighted the potential for increased outages due to expired certificates, especially for smaller organizations or those with less automated systems. They argued that while automation is possible, it's not always straightforward and can introduce new points of failure. Another commenter echoed this sentiment, pointing out the difficulty in maintaining certificates for a large number of internal services. This commenter specifically noted the challenge of convincing management to invest in automation tools.
The discussion also touched upon the security benefits and trade-offs of shorter certificate lifetimes. Some commenters acknowledged the improved security posture resulting from reduced exposure window for compromised certificates. However, they also questioned whether the added complexity and potential for outages outweigh these benefits. One commenter suggested that Let's Encrypt's 90-day lifetime had already struck a reasonable balance between security and manageability. Another commenter questioned the actual impact on security, arguing that most certificate-related incidents are not due to long-lived certificates, but rather misconfigurations or other vulnerabilities.
The topic of automation and tooling was central to the discussion. Several commenters advocated for robust automation as a necessary solution to manage shorter certificate lifetimes. They mentioned specific tools and services, such as certbot and ACME clients, that can facilitate automated renewals. One commenter suggested that organizations struggling with certificate management should consider managed solutions or cloud providers that handle certificate lifecycle automatically. There was also a discussion about the importance of proper monitoring and alerting systems to prevent outages due to expired certificates.
Some commenters expressed skepticism about the motivations behind the push for shorter lifetimes. They speculated that certificate authorities (CAs) might be financially incentivized to promote more frequent renewals. One commenter jokingly remarked that CAs are "creating job security for themselves" by increasing the administrative burden on their customers.
Finally, a few commenters offered practical advice and tips for managing certificates, such as using a centralized certificate management system and leveraging monitoring tools to track certificate expiry dates. One commenter also highlighted the importance of planning for certificate renewals well in advance to avoid last-minute scrambling and potential outages.