The author removed the old-school "intermediate" certificate from their HTTPS site configuration. While this certificate was previously included to support older clients, modern clients no longer need it and its inclusion adds complexity, potential points of failure, and very slightly increases page load times. The author argues that maintaining compatibility with extremely outdated systems isn't worth the added hassle and potential security risks, especially considering the negligible real-world user impact. They conclude that simplifying the certificate chain improves security and performance while only affecting a minuscule, practically nonexistent portion of users.
In a blog post titled "Why I no longer have an old-school cert on my HTTPS site," author Rachel Kroll details her reasoning for transitioning away from using a personally generated SSL certificate on her website, rachelbythebay.com. She elaborates on the historical context of her initial decision to self-sign her certificate, emphasizing a period in the early 2000s when obtaining certificates from Certificate Authorities (CAs) was a considerably more expensive and complex undertaking. She describes this period as a time when HTTPS adoption was far less prevalent and self-signing was a viable, albeit less convenient, alternative for individuals and smaller websites.
Kroll explains that the primary motivation behind this practice was to encrypt the transmission of her SSH keys, which she frequently accessed remotely. The broader security implications of HTTPS for general website browsing were less of a concern at the time due to the nature of her site's content and the lower overall risk associated with website vulnerabilities in that era. Furthermore, she notes that widespread browser warnings regarding self-signed certificates were not yet the norm.
However, the landscape of internet security has significantly evolved. Certificate acquisition through initiatives like Let's Encrypt has become dramatically simplified and free, removing the financial and logistical barriers that once existed. Concurrently, web browsers have become increasingly stringent in their handling of self-signed certificates, often presenting prominent warning messages that can deter users and create a negative perception of a website’s security. Kroll highlights the user experience implications of these warnings, emphasizing the potential for confusion and frustration for visitors who encounter them.
Ultimately, the combination of free and readily available certificates from CAs like Let's Encrypt, coupled with the negative user experience associated with browser warnings for self-signed certificates, prompted Kroll to abandon her long-standing practice of self-signing. She concludes by advocating for the use of CA-issued certificates, portraying it as the more user-friendly and secure approach in the modern internet environment. This decision, she explains, aligns with the current best practices for web security and provides a more seamless and trustworthy experience for visitors to her website.
Summary of Comments ( 363 )
https://news.ycombinator.com/item?id=44071690
HN commenters largely agree with the author's decision to drop support for legacy SSL/TLS versions. Many share anecdotes of dealing with similar compatibility issues, particularly with older embedded devices and niche software. Some discuss the balance between security and accessibility, acknowledging that dropping older protocols can cause breakage but ultimately increases security for the majority of users. Several commenters offer technical insights, discussing specific vulnerabilities in older TLS versions and the benefits of modern cipher suites. One commenter questions the author's choice of TLS 1.3 as a minimum, suggesting 1.2 as a more compatible, yet still reasonably secure, option. Another thread discusses the challenges of maintaining legacy systems and the pressure to upgrade, even when resources are limited. A few users mention specific tools and techniques for testing and debugging TLS compatibility issues.
The Hacker News post "Why I no longer have an old-school cert on my HTTPS site" (linking to an article explaining the author's decision to move away from self-signed certificates) generated a moderate amount of discussion, with several commenters sharing their perspectives and experiences.
A key theme in the comments is the practicality and user experience surrounding self-signed certificates. One commenter highlights the annoyance of constantly having to click through security warnings, particularly on mobile devices, where managing exceptions can be cumbersome. This sentiment is echoed by others who emphasize the poor user experience associated with self-signed certificates, especially for users less technically inclined.
Several commenters discuss alternative approaches to achieving similar levels of privacy and security without the drawbacks of self-signed certificates. One suggestion involves using a private CA within a closed network or family, offering a balance between control and ease of use. Another commenter suggests using a free service like Let's Encrypt, which automates the process of obtaining and renewing publicly trusted certificates, eliminating the hassle of self-signing. The benefits of using Let's Encrypt are further emphasized in another comment, highlighting its simplicity and widespread adoption.
The discussion also touches upon the technical aspects of certificate management. One commenter points out the challenge of maintaining and distributing the root certificate for self-signed setups, particularly when dealing with multiple devices and users. Another commenter delves into the specific issue of hostname verification with self-signed certificates, suggesting a workaround involving subject alternative names. This technical detail reinforces the complexities that can arise when managing self-signed certificates compared to publicly trusted ones.
The overall sentiment in the comments leans towards favoring publicly trusted certificates or private CAs over self-signed certificates, primarily due to the improved user experience and ease of management. While acknowledging potential use cases for self-signed certificates in specific controlled environments, the commenters generally highlight the inconveniences and complexities associated with them for broader use cases, particularly in publicly accessible websites.