TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Intent to end OCSP service

415 点作者 soheilpro10 个月前

18 条评论

agwa10 个月前
After I created OCSP Watch[1], I regularly detected CAs returning an OCSP response of unknown or unauthorized for certificates found in CT logs, indicating that they had basically forgotten that they had issued a certificate. I find that rather troubling. Indeed, OCSP Watch is currently reporting several forgotten NETLOCK certificates. (The certificates from other CAs are recently issued and will probably have OCSP responses provisioned in the near future.)<p>CRLs can&#x27;t be used to detect this, because they only list revoked certificates rather than providing a definitive status for every issued certificate.<p>I do wish the root programs had merely removed the requirement to include an OCSP URL in certificates, but required OCSP URLs for every issuer to be disclosed in the CCADB. That would have solved the privacy problems and made OCSP responders much cheaper to operate, while continuing to provide transparency into the status of certificates.<p>[1] <a href="https:&#x2F;&#x2F;sslmate.com&#x2F;labs&#x2F;ocsp_watch&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sslmate.com&#x2F;labs&#x2F;ocsp_watch&#x2F;</a>
评论 #41048954 未加载
评论 #41048797 未加载
评论 #41050159 未加载
评论 #41049735 未加载
hlieberman10 个月前
Why not simply add the Must Staple restriction unconditionally to all certificates (aka &quot;status_request&quot;)?<p>That will eliminate privacy concerns -- no compliant TLS implementation should fetch a OCSP ticket given a stapled response -- while still allowing for broad non-browser support.
评论 #41048779 未加载
评论 #41047909 未加载
评论 #41048006 未加载
评论 #41047965 未加载
评论 #41048781 未加载
jrochkind110 个月前
letsencrypt is the nonprofit community-focused infrastruture that we imagined the internet would consist of 20 years ago. I love you letsencrypt.
datadrivenangel10 个月前
&quot;As soon as the Microsoft Root Program also makes OCSP optional, which we are optimistic will happen within the next six to twelve months, Let’s Encrypt intends to announce a specific and rapid timeline for shutting down our OCSP services. We hope to serve our last OCSP response between three and six months after that announcement. The best way to stay apprised of updates on these plans is to subscribe to our API Announcements category on Discourse.&quot;<p>Interesting to see Microsoft dragging here.
评论 #41048474 未加载
klysm10 个月前
Certificate management is an interesting problem along the intersection of human behavior and computer science that feels similar to BGP. In theory, it&#x27;s simple, but when met with reality things get messy really really fast.
kroeckx10 个月前
For the major browsers, this probably makes little difference, but for anything else, this will most likely result in not verifying the revocation status of certificates anymore or making things slower.<p>As far as I know, most browser vendors already download the CRLs, and then update the browsers based on what they downloaded. For instance firefox seems to be using CRLite. There is a lack of support for something like that in the non-major browsers and non-browsers. The alternative they have is to download the CRL instead of the OCSP reply, which is larger, probably making things slower. Or they could just not check the status, which is most likely what will happen.<p>CRLite changes the failure mode of the status check, it no longer just ignores error in downloading the status information.<p>We need better support for something like CRLite.
评论 #41070752 未加载
评论 #41059242 未加载
codegeek10 个月前
Can someone ELI5 what does this mean for people using LetsEncrypt today with servers like Nginx or Caddy ? Do we need to make any changes to adjust ?
评论 #41047849 未加载
评论 #41048206 未加载
c0balt10 个月前
Interesting, how does the support for CRLs in web servers look?<p>Afaik, NGINX and Apache only have OCSP stapling support.
评论 #41047516 未加载
评论 #41047538 未加载
remram10 个月前
So if I&#x27;m not using Chrome or Firefox, how do I check for revoked certificates? This just makes the web less open again.
评论 #41050224 未加载
trillic10 个月前
Are there any free or very inexpensive certificate providers which support ACME, DNS-01 challenges, and OCSP other than ZeroSSL?
评论 #41048177 未加载
notepad0x9010 个月前
CRLs don&#x27;t scale, that&#x27;s their problem and they take too long to update.<p>Why isn&#x27;t there a standard binary format for CRLs that is a cuckoo filter or a similar data structure? That way you don&#x27;t have to worry about a CRL ballooning to gigabytes and you can expect clients to fetch the latest binary blob frequently.
评论 #41051234 未加载
new23d10 个月前
We collected some data [1] on the viability of only CRLs as the future (phasing out OCSP) - motivated by Let&#x27;s Encrypt&#x27;s announcement today [2].<p>Data is on CRL availability, number of entries, expiry &amp; refresh times, etc. from various x509 leaf server SSL certificates.<p>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=41058138">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=41058138</a> [2] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=41046956">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=41046956</a>
arsome10 个月前
Disappointing to hear considering the limitations of CRLs - is there any intention to go forward with OCSP stapling or is that completely abandoned at this point?
评论 #41047549 未加载
Sohcahtoa8210 个月前
I&#x27;m curious how much of a factor this is. How often do certificates get revoked before expiration? I would think the only reason to revoke a certificate is if it was compromised.
评论 #41048270 未加载
评论 #41048279 未加载
7bit10 个月前
Have we gone full circle?<p>Wasn&#x27;t the point of OCSP to provide a low-latency and low-data alternative to CRLs, which might become massively huge?
newman31410 个月前
Does anyone have a ready to go hosts blocklist for OCSP hostnames? Else, I could make one...
评论 #41056332 未加载
eqvinox10 个月前
I… er… what?<p>First of all, privacy was one of the points of OCSP stapling.<p>Second, this breaks all non-http applications in the sense that they could previously work through OCSP stapling which would be communicated in-line. CRLs need to be fetched by the client, generally over HTTP.<p>Third, most non-browser TLS clients simply do not fetch CRLs, the implementation hurdle was too high.<p>… I&#x27;m left seriously befuddled by this decision by Let&#x27;s Encrypt [edit: or rather the CA&#x2F;B forum] :(
评论 #41048266 未加载
评论 #41071587 未加载
评论 #41047896 未加载
eduction10 个月前
It would be nice if one didn&#x27;t need to be a TLS expert to understand the post -- particularly since the whole point of Let&#x27;s Encrypt was to democratize TLS access.<p>I have no idea if this means my setup will break even after consulting the docs of my ACME client.<p>Can I still use ACME Tiny[1] with nginx? Any reason to think that will break? How can I tell if I&#x27;m using OCSP or CRL?<p>Totally incomprehensible blog post.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;diafygi&#x2F;acme-tiny">https:&#x2F;&#x2F;github.com&#x2F;diafygi&#x2F;acme-tiny</a>
评论 #41048161 未加载
评论 #41048165 未加载