Let’s Encrypt में आज 90 मिनट तक त्रुटि दर अधिक रही

आउटेज का प्रभाव और स्थिति-पृष्ठ की शब्दावली

• घटना upstream नेटवर्किंग के कारण लगभग 90 मिनट तक issuance errors बढ़ने की अवधि थी, न कि पूरे दिन का आउटेज।
• Let’s Encrypt के कर्मचारी (व्यक्तिगत रूप से पोस्ट करते हुए) कहते हैं कि अधिकांश अनुरोध फिर भी सफल रहे; कुछ उपयोगकर्ताओं ने उस विंडो के दौरान बार-बार 400/500 और शून्य सफल renewals की रिपोर्ट की।
• “Degraded Performance” को लेकर भ्रम था: कुछ लोगों ने इसे लगभग पूर्ण विफलता के रूप में पढ़ा; दूसरों का कहना है कि status-page की भाषा अक्सर गंभीर समस्याओं को कम करके दिखाती है।
• “Active Incident” के दौरान status banner का हरा होना भ्रामक बताया गया, खासकर मोबाइल पर जहाँ विस्तृत status text स्क्रीन से बाहर रहता है।

छोटी certificate lifetimes बनाम revocation

• हमेशा और छोटी lifetimes की माँग पर बहस (90 दिन → 45 दिन → यहाँ तक कि कुछ दिन)।
• एक पक्ष: छोटी lifetimes चोरी हुई keys से होने वाले नुकसान को सीमित करती हैं और CRLs को छोटा करती हैं; expiry मॉडल का मूल हिस्सा है।
• दूसरा पक्ष: अधिक frequent renewals CA uptime और infrastructure fragility पर निर्भरता बढ़ाती हैं; revocation को ठीक किया जाना चाहिए।
• आज revocation को व्यापक रूप से broken माना जाता है, हालांकि कुछ का तर्क है कि नए mechanisms (जैसे Firefox में CRLite) इसे काफी हद तक हल करते हैं, बशर्ते vendor adoption व्यापक हो।

Operational hygiene और automation

• कई लोग ज़ोर देते हैं कि clients को expiry से काफी पहले renew करना चाहिए (जैसे 90 दिनों में 60वें दिन) और retries/backoff के साथ, ताकि छोटी outages गैर-मुद्दा बन जाएँ।
• उन setups की आलोचना की गई जो renewal केवल expiry के बहुत करीब करने की कोशिश करते हैं; इसकी तुलना ऐसे passport से की गई जो तकनीकी रूप से वैध है लेकिन expiration के पास व्यावहारिक रूप से अनुपयोगी हो जाता है।

विकल्प और centralization risk

• कुछ लोग Let’s Encrypt को वेब के बड़े हिस्से के लिए de facto single point of failure मानते हैं; दूसरे तर्क देते हैं कि ZeroSSL, Google Trust Services आदि जैसे alternative CAs मौजूद हैं।
• संकट में practical switchover पर सवाल उठता है: built-in failover की कमी, दूसरे CAs पर संभावित load spikes, और एक key के लिए multiple certs serve करने की जटिलता।
• व्यापक आलोचनाएँ web PKI model और US-based CAs पर निर्भरता को निशाना बनाती हैं; प्रस्तावों में DNS-published self-signed keys या network intermediaries पर अधिक कड़े regulation शामिल हैं।

Expired certificates को browsers कैसे संभालें

• इस पर असहमति है कि browsers को अभी-अभी expired certs के लिए errors नरम करने चाहिए या नहीं।
• कुछ का तर्क है कि कड़े failures उचित automation के लिए ज़रूरी हैं और सुरक्षा में ढिलाई से बचाते हैं; दूसरों का मानना है कि सूक्ष्म, समय-आधारित warnings उपयोगिता सुधार सकती हैं बिना बड़े जोखिम के।