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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Let's Encrypt is Trusted

1260 点作者 coffeecheque超过 9 年前

42 条评论

lorddoig超过 9 年前
Being told that you now trust someone with your secrets via a news website is a pleasingly succinct display of everything that's wrong with the CA model.
评论 #10418776 未加载
评论 #10417674 未加载
评论 #10418251 未加载
评论 #10418760 未加载
评论 #10417726 未加载
joshmoz超过 9 年前
See a Let&#x27;s Encrypt cert in action:<p><a href="https:&#x2F;&#x2F;helloworld.letsencrypt.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;helloworld.letsencrypt.org&#x2F;</a><p>Nice work team!
评论 #10417314 未加载
评论 #10417752 未加载
评论 #10417312 未加载
toast0超过 9 年前
It seems odd to me that the intermediates were cross signed instead of the having the root be cross signed.<p>With a cross signed root, clients with only the IdenTrust root will validate the cert, and clients with only the LetsEncrypt root can validate the cert.<p>With a cross signed intermediate, the server has to guess which root the client has and serve the correct path, there&#x27;s a TLS extension to indicate roots the client supports, but nothing actually uses it, so I don&#x27;t know how the server is going to guess (other than to assume no one has the LetsEncrypt root, since it&#x27;s new).<p>[1] but some clients are dumb and won&#x27;t validate successfully when they reach a root they know :&#x2F; Most browsers will though.
评论 #10417498 未加载
jakejake超过 9 年前
Can anyone who knows more than me say - is this the beginning of the end of the SSL cert selling business? Is there still value to buying an expensive cert from another vendor?
评论 #10417495 未加载
评论 #10417391 未加载
评论 #10417365 未加载
评论 #10417673 未加载
评论 #10417400 未加载
评论 #10417350 未加载
bracewel超过 9 年前
ISRG, the org behind Let&#x27;s Encrypt, is hiring! -- <a href="https:&#x2F;&#x2F;letsencrypt.org&#x2F;jobs&#x2F;" rel="nofollow">https:&#x2F;&#x2F;letsencrypt.org&#x2F;jobs&#x2F;</a>
throwaway7767超过 9 年前
Can someone who&#x27;s tried the client confirm if it&#x27;s possible to get a key&#x2F;cert out of it without having it mess with my configuration files?<p>I&#x27;d like a manual mode, as years of sysadmin work have made me extremely skeptical of tools that try to automatically modify config files.
评论 #10418244 未加载
评论 #10420141 未加载
评论 #10418238 未加载
评论 #10418316 未加载
zmmmmm超过 9 年前
Yay!<p>Honestly, it is amazing to me that someone like Google or Amazon did not do this as free service a long time ago. But having an independent entity like this do it is far better.
评论 #10417534 未加载
axx超过 9 年前
The big question:<p>Does this mean we can now all use Let&#x27;s Encrypt to generate new certificates without people running into problems?
评论 #10418826 未加载
评论 #10418872 未加载
评论 #10418811 未加载
评论 #10418830 未加载
icelancer超过 9 年前
Huge win for them - will help push SSL&#x2F;TLS on everything. Can&#x27;t overstate how important this is for the web. Now to get the word out to everyone!<p>edit: initially said SSH. I blame the plane wifi
评论 #10417345 未加载
steve19超过 9 年前
&quot;We’re pleased to announce that we’ve received cross-signatures from IdenTrust&quot;<p>How is this beneficial for IdenTrust?
评论 #10417334 未加载
评论 #10417438 未加载
评论 #10417433 未加载
teabee89超过 9 年前
Are they planning on not relying on a 3rd party root CA and instead, ask all browsers and OS vendors to include LetsEncrypt CA? IOW, is this [trusting IdenTrust] a first step, or is this the original goal?
评论 #10419769 未加载
评论 #10419973 未加载
scott_karana超过 9 年前
&gt; and we’re excited to be one big step closer to bringing secure connections to every corner of the Web.<p>What steps are left now? :-)
评论 #10417319 未加载
评论 #10418188 未加载
bracewel超过 9 年前
A quick look at all the certificates Let&#x27;s Encrypt has issued so far can be found using Comodo&#x27;s CT based crt.sh tool.<p><a href="https:&#x2F;&#x2F;crt.sh&#x2F;?Identity=%25&amp;iCAID=7395" rel="nofollow">https:&#x2F;&#x2F;crt.sh&#x2F;?Identity=%25&amp;iCAID=7395</a>
评论 #10417537 未加载
wyldfire超过 9 年前
Delicious irony: my employer&#x27;s web proxy supplies their own certificate in place of the real one for <a href="https:&#x2F;&#x2F;letsencrypt.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;letsencrypt.org&#x2F;</a>.<p>Though, to be honest they do this for &gt;90% of https sites, in my experience.
peterwwillis超过 9 年前
Remember that you only need one of the hundreds of CAs (650 at my last count) to generate you a cert to essentially compromise a site&#x27;s connection security. Free certs mean more sites will use TLS, which means there will be more targets, which means more incentive to start attacking the weakest CAs and&#x2F;or their verification practices.<p>But this is kind of a good thing, because after enough attacks on the old model, people will ask for an improvement or replacement of the model.
评论 #10418144 未加载
johncolanduoni超过 9 年前
It just <i>had</i> to be right after I renewed my SSL cert, didn&#x27;t it? :P
评论 #10417781 未加载
评论 #10417748 未加载
评论 #10418631 未加载
jonah超过 9 年前
Chrome says they don&#x27;t supply Certificate Transparency information. Is this something they should be doing?
评论 #10417372 未加载
josteink超过 9 年前
From a comment on a similar reddit-thread[1]:<p>&gt; So thus beings the transition. EV certs are going to be the only ones that get the &quot;green&quot; chrome in browsers anymore. Sites using standard SSL are going to get the normal no-lock&#x2F;white treatment. And sites without SSL will get the caution symbol&#x2F;yellow treatment.<p>I don&#x27;t like it, but I suspect this is where we&#x27;re heading.<p>[1] <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;linux&#x2F;comments&#x2F;3pg37u&#x2F;lets_encrypt_is_trusted&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;linux&#x2F;comments&#x2F;3pg37u&#x2F;lets_encrypt_...</a>
评论 #10418145 未加载
评论 #10418058 未加载
nodesocket超过 9 年前
Am I missing where I can signup? Love to try them.
评论 #10417510 未加载
评论 #10417514 未加载
评论 #10417538 未加载
arkad超过 9 年前
This entry has 443 points how and I don&#x27;t want to upvote to spoil it...
cddotdotslash超过 9 年前
Is there an easy way to pull out the cert and load it into an AWS ELB without running the client on the server it will eventually protect? I&#x27;m not a big fan of using software that auto changes my config files, plus you can&#x27;t actually run scripts on ELBs.
评论 #10418411 未加载
mholt超过 9 年前
Congratulations LE team!<p>Final Star Wars VII trailer and LE gets cross-signed. Best. Day. Ever.
评论 #10418177 未加载
ausjke超过 9 年前
What does this mean to a new user? Can I now get a ssl certificate? will it be cheaper, or even free? I saw they have a beta-program for the certificate but don&#x27;t know what it exactly does.
gergles超过 9 年前
I really dislike the fact that a CA is able to bless a new CA completely independently. Does this cause anyone else the slightest amount of anxiety, or am I just being paranoid?
评论 #10419344 未加载
评论 #10419277 未加载
评论 #10419285 未加载
okigan超过 9 年前
Could somebody clarify: LetsEncrypt allows anybody to create certificate for any domain, so would not that allow anybody to create MITM certificate for any such domain?
评论 #10417381 未加载
评论 #10417373 未加载
评论 #10417379 未加载
评论 #10417371 未加载
vbezhenar超过 9 年前
Is there some web interface to sign my certificate, similar to startssl? I don&#x27;t really want to run new program in my server just to generate certificate.
评论 #10418179 未加载
cm2187超过 9 年前
Has anyone seen anything re IIS integration?<p>[EDIT] I have seen this: <a href="https:&#x2F;&#x2F;github.com&#x2F;ebekker&#x2F;letsencrypt-win" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ebekker&#x2F;letsencrypt-win</a><p>But ideally we would want Microsoft to add a checkbox in the UI of IIS Manager, which when creating a https binding offers to use let&#x27;s encrypt instead of an installed certificate.
dSnapApjw超过 9 年前
I like that statement &quot;community trust&quot;...much the same I have come to trust most of the wisdoms on this site. I for one-learn, and greater, I learn from each of you the value of clarity. So trust as David Abshire says, &quot;Is the coin of the realm, the glue, the oil, (alternative energy-) ingredient.&quot;txs, dSnapAp. SFCA.
andrewrothman超过 9 年前
I can&#x27;t wait for Let&#x27;s Encrypt to finally start signing certificates. The future of encrypted communications is among us, and it&#x27;s going to be huge.<p>Will definitely use this as soon as they open their doors to me.
vinay_ys超过 9 年前
In a mobile only world where your critical business runs only via mobile app do CA based SSLs even matter? Why not use your own CA with your own certificates and don&#x27;t have to trust any CA?
评论 #10420269 未加载
franciscop超过 9 年前
Yes, finally. I&#x27;ve been awaiting this moment from the first announcement. Happy they made it (:
devit超过 9 年前
The next step should be to stop trusting any other CA, and have Let&#x27;s Encrypt support EV certificates by working with other CAs and still requiring Let&#x27;s Encrypt DV verification.<p>This way, Let&#x27;s Encrypt in particular would need to be breached for a successful attack, while right now it&#x27;s enough to breach either Let&#x27;s Encrypt or any other CA.
dadrian超过 9 年前
Congratulations jdkasten!
SimeVidas超过 9 年前
So… we’re all still waiting for the client, right?
评论 #10417401 未加载
jamminn超过 9 年前
So, it&#x27;s still all about trust then? I thought Let&#x27;s Encrypt would go beyond trust.
评论 #10419417 未加载
tychuz超过 9 年前
I&#x27;m all for native desktop and mobile applications, but in this case I&#x27;d actually love a web app - enter your domain, get certificate.<p>Downloading a tool, reading man page, works out of the box only with apache&#x2F;nginx - ehhh, seems like a lot of work, considering some comments touting &#x27;user friendliness&#x27; compared to StartSSL.
评论 #10418555 未加载
评论 #10418576 未加载
balabaster超过 9 年前
Er... you&#x27;re trusted by a CA that&#x27;s owned by a company that resides in Austin Texas...<p>Texas hasn&#x27;t exactly got a glowing reputation in the software industry due to its mountain of intellectual property lawsuits filed by patent trolls... er, sorry, I mean non-practicing entities<p>Excuse me while I reserve some skepticism about just how trusted your security certificates should be.
评论 #10419187 未加载
评论 #10419204 未加载
1K2bCjh1aH超过 9 年前
.&#x2F;letsencrypt-auto Updating letsencrypt and virtual environment dependencies.....Command &quot;python setup.py egg_info&quot; failed with error code 1 in &#x2F;tmp&#x2F;pip-build-KgdEvk&#x2F;ConfigArgParse
评论 #10418115 未加载
signaler超过 9 年前
This will still require early stage overhead for many people switching over &#x2F; &#x27;going dark all the things&#x27;. Even though Let&#x27;s Encrypt&#x27;s goal is to make the process of encrypting the Transport Layer seamless, ubiquitous and non-commercial.<p>Take for example my setup. It sits on a private NGINX server, and is proxied through a public facing CDN. Trying to simply &#x27;switch on&#x27; TLS involves absorbing academic style tutorials from multiple disparate sources, and requires me to have a background in DevOps and that I have at least tried some technical task like this before. In layman&#x27;s terms: Unnecessary Early Stage Overhead.<p>Now give Let&#x27;s Encrypt a few more years and it will be a lot more seamless; possibly the default. It could possibly be &#x27;baked in&#x27; to things like Softaculous, and cPanel, which are brilliant drivers for the success of web software. Digital Ocean staff are probably already working on a droplet with LetsEncrypt baked in...
评论 #10418583 未加载
NateDad超过 9 年前
Why python for the client software if you obviously already have Go experience in-house? Using python means you have to run all this virtual-env crap in a bash script, apt-get install a bunch of crap for setup and not support Windows. Seems like using a (nearly) dependency-free Go application for the client as well would have been a no brainer. Was it just a case of having more access to python devs, or were there other technical reasons? Anyone know? I bet this has been asked before, but not I&#x27;m turning anything up with google.
评论 #10417378 未加载
评论 #10417710 未加载
评论 #10417530 未加载
评论 #10417452 未加载
评论 #10417948 未加载
UserRights超过 9 年前
The headline is wrong and not very clever for such a project.<p>The project was able to get a CA to sign their keys, this is what happened. Using the word &quot;trust&quot; is simply wrong and might be interpreted as a too simple kind of propaganda after we learned a lot about the untrustable nature of a hierarchical certification infrastructure.<p>Another, even bigger trust-breaking elephant in the room is the fact that this project is USA based - as long as US government and agencies are insisting on practices we know from authoritarian and anti-democratic states like e.g. China or Saudi-Arabia there is no way any US based project can use the word &quot;trust&quot; for their product description - it might be recognized as a simple lie by informed people.<p>Questions to the project leaders:<p>* you must obey US laws and therefore offer MITM access to every Let&#x27;s-Encrypt &quot;trusted&quot; network stream - why aren&#x27;t you educating your users about this serious limitation of your product?<p>* why don&#x27;t you rebase your project to a country where a government policy exists that is allowing companies to build trustable security based products?
评论 #10420410 未加载
评论 #10419094 未加载
评论 #10419338 未加载
评论 #10418926 未加载
mangeletti超过 9 年前
I truly appreciate the hard work Let&#x27;s Encrypt is doing.<p>However, this is not free.<p>In return for getting an SSL certificate, your users will need to trust an organization to protect the secrets they share with you and vice versa. This organization has no economic incentive to do good for you or to do harm to you.<p>What happens when this organization is compelled by the TLA to give up the lucky charms, and there is no team of attorneys to fight back, and no billions at stake, and there is a gag order? And, given the rate at which a &quot;free&quot; SSL certificate will proliferate, these will be some valuable lucky charms.<p>This is not FUD. This is simply recognizing that &quot;free&quot; SSL certificates don&#x27;t really address the issues that arise from centralized authority in a decentralized economy.
评论 #10417810 未加载
评论 #10417791 未加载
评论 #10417820 未加载
评论 #10417808 未加载
评论 #10417799 未加载
评论 #10418479 未加载