-
-
Notifications
You must be signed in to change notification settings - Fork 601
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: localhost.letsencrypt.org dev certs #137
Comments
Providing a mechanism by which In the mindset of "moving the web forward", it would be more helpful to less experienced developers to encourage them to use a workflow that will have consistent security policies and not issue certs to For the sake of lowering the barrier to entry for secure local development, there should ideally be a few publicly whitelisted domains such as localhost.letsencrypt-demo.org localhost.example.com and localhost.example.net. I also like the idea that the domain owner would have a mechanism by which to whitelist domains ad-hoc, but... but maybe that gets complicated. |
@coolaj86: Good point about developing on |
Does the bolder server currently support issuing certs to |
Note that a public CA must not issue valid certs to |
How does one appeal that? And is there any reasoning stated? What is "Internal Name" defined anywhere? Unfortunately the PDF was generated with a tool that treats each word as a different line, so it's not possible to search for "internal name" only "internal" or "name", at least not in Chrome. I can't imagine why I shouldn't be able to purchase an HTTPS cert for a machine that is only used between peers on a VPN (and not on the internet at large). I don't want to have to go around trying to convince normal users to install a manufacturer issued root CA to their browsers to use and access such devices in their homes, cars, boats, etc. |
Found it:
Looks like it is intended to apply to I don't see why that should be applied to |
Okay, I got some clarification on the matter and it makes sense: https://cabforum.org/pipermail/public/2015-June/005673.html Here's the gist of what's wrong: Some devices are misconfigured such that some network requests for localhost actually hit the local DNS. Not just in theory, but in practice - it has been seen in the wild. A router could have a DNS resolution for Most people have probably see this behavior at some time or other - where you start typing in something into an omnibar and for some strange reason it resolves to the router or to a device with the name of the search term instead of performing a google search. Example: Carrie's iMac has been renamed to 'cookie', you join Carrie's home network and start to search for 'cookie' to get some recipes and instead it takes you to the Web Sharing service's Public folder on her iMac. |
Why is this closed? I read the email from the previous post and still think that pointing localhost.letsencrypt.org to 127.0.0.1 and creating SSL cert for localhost.letsencrypt.org (ideally generated by letsencrypt and downloadable somewhere) should be OK. Or am I wrong? |
In order for an arbitrary developer to use the type of certificate you propose, the Subscriber who requested it would have to publish not only the certificate, but also the private key. That would be a violation of the Subscriber Agreement and we would be forced to revoke the certificate. Besides the policy issues, it would be a bad idea to encourage developers to connect to an HTTPS origin for which the private key is publicly available. As I said above, the issue of HTTPS-based localhost development is eminently fixable by using a locally-trusted certificate. The ecosystem does need better tooling to make generation and installation of such certificates easier (I wrote a script to do it at a past job), but that's out of scope for Boulder. So this is a Won't Fix. |
My point was rather that if the cert and the private key was generated and published by Let's Encrypt itself, there would be no Subscriber Agreement violation. My usecase is the following:
If you want to take the discussion elsewhere or you don't want to discuss this topic further, please let me know. I understand that this issue is a WontFix and I don't want to reopen it. I also hate offtopic posts on Github, but this seemed like a best place to me to discuss this issue and is still a little bit on-topic I guess. |
For continuing discussion from letsencrypt/acme-spec#117
The text was updated successfully, but these errors were encountered: