A public cert for localdev.letsencryrpt.org

Server
1

Have you thought about making a public certificate at localdev.letsencrypt.org for people to use on their local machines?

Users could then download the cert from somewhere and update their /etc/hosts to have

127.0.0.1    localdev.letsencrypt.org

The issue right now is in order to get a certificate users need (1) a machine that is on the real internet and they need (2) a personal domain.

For real web developers that's not a problem but lots of devs are just experimenting with HTML/JavaScript etc. Browsers are deprecating features unless served over HTTPS. This makes it hard for many newbies and hobbiests to get started

  1. A machine on the real internet

    For many students this is not a real option. Their school is unlikely to punch a hole through the network's firewall or NAT etc. Even if they're at home reconfiguring their router to allow this is arguably an advanced step. If they've got siblings or roommates or whatever it that makes it even more of an advanced step. They could get an external server (AWS, Google Cloud, Digital Ocean) but that costs $$ (yea I know cheap but when you're student even $ is prohibitive, if you're a child forget it).

  2. A registered domain

    This is also $ and advanced to setup for a newbie / student

Having a public cert localdev.letsencryrpt.org that's updated every 30 or 60 days would allow people to at least have a way to test servers locally on that domain with a minimal amount of fuss.

Note: localdev.letsencrypt.org would not actually be a real site. While everyone would have access to the private key what does it matter? It's one unused domain. In fact just put up a page if you want that says

If you're seeing this page maybe you meant to add

127.0.0.1    localdev.letsencrypt.org

to your /etc/hosts file?

Is this a good idea or bad idea? Why or why not?

One other idea would be to allow people to make up domains at letsencrypt.org. Example

 someuserdecidedsubdomain.free.letsencrypt.org

Some website / API would let people get a cert any subdomain they make up. That would allow them to not have to have a machine on the public internet NOR register a domain and let them use that domain for testing publically and even sharing. For example if they wanted to run their server internally and let other clients on their lan access the server through HTTPS.

I thought about creating that service as a public service but it seems like it would be better for letsencrypt to do it? Maybe I can implement it (I'm a noob myself though) and letsencrypt might be willing to take it over?

In any case why is this a good or bad idea?

2

I don't think this would be allowed by CA/B Baseline Requirements. Section 9.6.3 states:

The Subscriber or Terms of Use Agreement MUST contain provisions imposing on the Applicant itself (or made by the Applicant on behalf of its principal or agent under a subcontractor or hosting service
relationship) the following obligations and warranties:
[...]
2. Protection of Private Key: An obligation and warranty by the Applicant to take all reasonable
measures to maintain sole control of, keep confidential, and properly protect at all times the Private
Key that corresponds to the Public Key to be included in the requested Certificate(s) (and any
associated activation data or device, e.g. password or token);

There's also a provision that would force Let's Encrypt to revoke any certificate for which they're aware of a private key compromise:

The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:
3. The CA obtains evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise or no longer complies with the requirements of Sections 6.1.5 and 6.1.6;

Aside from any possible security implications (which I haven't really thought through yet), I think this is just something that's not permitted.

With regards to your point about browser features being limited to https://, it should be noted that the way W3C is currently defining secure contexts includes an exception for localhost and 127.0.0.0/8:

  • If origin’s host component is or falls within "localhost." [RFC6761], return "Potentially Trustworthy".
  • If origin’s host component matches one of the CIDR notations 127.0.0.0/8 or ::1/128 [RFC4632], return "Potentially Trustworthy".

I actually thought about this a while ago and it seems like a good idea. Something like a combination of a DynDNS provider with automated certificate issuance via dns-01. I think it could be quite useful for IOT devices, or pretty much anything you'd self-host in your home that would benefit from TLS. Not sure if it has to come from Let's Encrypt (scope creep is a concern), but would love to see this happen!

2 Likes
3

You can get free registered domain on http://www.freenom.com for the following TLDs: .tk, .ml, .ga, .cf, .gq

4

@pfg,

  • Localhost doesn’t help a student.

    They’re making a page, they want to test on iPhone, iPad, Android Phone, Win Phone. They server from their laptop. Their devices are not connecting to localhost

  • dyndns doesn’t help.

    A student can’t configure the university’s network to allow external devices to get back to their computer

@Nit

  • free domains don’t help

    A student can’t get the university to configure the net to allow this free domain to get to the student’s machine

5

What does that means ?

You point records of your domain to anything you want, any university has nothing to say about that. And you can always use the dns-01 challenge to get certificates just by updating some TXT dns records.

6

Besides, “a student” who wants to test some pages on some dev-server can perfectly use a self-signed certificate and/or a certificate issued by his/hers own self-signed root certificate. If everything is local only, why should one want a Let’s Encrypt certificate?

7

Thanks to @pfg for the detailed writeup for why we can’t do this.

On a personal note, I’ve had need for exactly this in the past. When I was working on HTTPS deployment at Twitter, I needed a way to access a locally development app, but over HTTPS. I also needed a way to make that the default access method on every developer’s machine, so that someone who accidentally coded a mixed-content bug would notice before it hit production.

What I wound up doing was writing a shell script that would generate a self-signed certificate for localhost, and automatically add it to the trust store on Mac OS. This took a little time to get right, but once I did it, it was easy to make part of our dev setup process.

I think a better way to solve the “HTTPS on localhost” problem would be to write up a set of shell scripts like that for each major platform, and provide them in a form that’s easy to reuse.

In the long run, an even better solution would be to convince OS vendors to automatically generate such a locally-trusted certificate as part of the OS, so that no additional work is needed.

1 Like
8

Self-signed certificates are perfectly acceptable for any development use-case. Installation of a certificate in your device's trust store is as simple as sending the certificate via mail (iOS) or downloading and opening the certificate (Android). "public private keys" are a non-starter because of Baseline Requirements as far as I can tell.

Sorry, should have been more clear here. This was related to your last paragraph - what I was talking about was building a DynDNS service that integrates with Let's Encrypt and provides certificates via dns-01. This could go a long way when it comes to deploying IoT devices (and other self-hosted systems) with SSL. I'm thinking of something like the solution Plex is using for SSL, but more flexible so that it would work with any service.

9

If that's the issue with DynDNS, then how should it work with localdev.letsencrypt.org on mobile phones in university?

You can also just use a self-signed certificate and add an exception to your browser the first time you access the page.

I even thought about adding something like that to my ACME client to ease these things.

10

This works great in Firefox, but for Chrome, the exception is only remembered for the duration of the browser session, and the URL bar shows a crossed-out red HTTPS. Since the goal is for developers to notice when they have mixed content, it's important that in Chrome the URL bar looks normal unless there's a problem.

11

Ok, I’m going to post the steps I did to use a self-signed cert. So far it seems to work

  1. Install OpenSSL

  2. Install node.js

  3. Install http-server by typing

    npm -g install http-server     // you probably need `sudo` in front of that

  4. Make the certs

    I got these instructions from here

     # make directories to work from
 mkdir -p server/ all/
 
 # Create your very own Root Certificate Authority
 openssl genrsa \
   -out all/my-private-root-ca.key.pem \
   2048
 
 # Self-sign your Root Certificate Authority
 # Since this is private, the details can be as bogus as you like
 openssl req \
   -x509 \
   -new \
   -nodes \
   -key all/my-private-root-ca.key.pem \
   -days 1024 \
   -out all/my-private-root-ca.crt.pem \
   -subj "/C=US/ST=Utah/L=Provo/O=ACME Signing Authority Inc/CN=example.com"
 
 # Create a Device Certificate for each domain,
 # such as example.com, *.example.com, awesome.example.com
 # NOTE: You MUST match CN to the domain name or ip address you want to use
 openssl genrsa \
   -out all/my-server.key.pem \
   2048
 
 # Create a request from your Device, which your Root CA will sign
 openssl req -new \
   -key all/my-server.key.pem \
   -out all/my-server.csr.pem \
   -subj "/C=US/ST=Utah/L=Provo/O=ACME Tech Inc/CN=local.ldsconnect.org"
 
 # Sign the request from Device with your Root CA
 openssl x509 \
   -req -in all/my-server.csr.pem \
   -CA all/my-private-root-ca.crt.pem \
   -CAkey all/my-private-root-ca.key.pem \
   -CAcreateserial \
   -out all/my-server.crt.pem \
   -days 500
 
 # Put things in their proper place
 rsync -a all/my-server.{key,crt}.pem server/
 rsync -a all/my-private-root-ca.crt.pem server/

Now you can serve any tree over https with

http-server --ssl --cert server/my-server.crt.pem --key server/my-server.key.pem path/to/folder/to/serve

Now go to https://localhost:8080 or https://<ipaddress>:8080

If you want to serve on 443 then add -p 443. You’ll probably need sudo in front to do that since 443 is restricted

Tested with streaming audio and video and it seemed to work. Still need to test Android Chrome

I’m guessing the instructions above would work on OSX and Linux (only tested on OSX). Maybe with the new bash in Windows stuff it would also work on Windows 10 as is.

3 Likes
12

Excellent script, thanks for sharing! On OS X, you can also automatically add the root cert to your trust store, to make it especially smooth: http://apple.stackexchange.com/a/80625.

Also note that you’ll want to protect the key to your personal root cert well - put it on a USB drive that you keep someplace safe, or delete it when you’re done.

1 Like
13

Ugh!

So self-signed certs are not a solution for me in any way shape or form. They don’t work in Safari (iOS or OSX) for websockets period unless the user installs the root cert on their phone. That’s not an acceptable requirement for people using my system.

I really need unlimited wildcard certs for subdomains. One cert per installation

PS: they do work for HTTPS but not for WSS (secure websockets)

1 Like
14

I think this post is a bit off-topic. The first post in this thread was specifically about certificates for localhost, to be used by local developers. I recognize that you have another use case: the many subdomains of happyfuntimes you use for game jams. But I think that conversation belongs on the other thread.

15

Sorry, I was looking at this as possible solution to that.

Also I wish I could have a serious conversation with you as a representative of LE about this topic. As in sit down face to face or video conference or something more official. I feel like I’m blowing air the wind on these forums.

I need a solution. Free and open source projects in general need solutions. Browsers are banning features on http and requiring https. Letsencrypt was part of their excuse that there would be no problems because there would be free certs. Well, that’s not the case. My free open source project is effectively dead without this being solved. Since letsencrypt was claimed to be the solution here I am asking for solutions. So far I don’t feel like I’ve made any headway in getting any kind of even acknowledgement that innovation and opportunities for open source projects are effectively being stifled by these 2 positions (1) that https is required and (2) that letsencrypt’s policies are not enough to deal with the new https requirements.

1 Like
16

Claimed by whom? I.e.: why must Let's Encrypt fix your problem when they aren't the cause?

17

Why shouldn't letsencrypt be the solution? What is the point of letsencrypt?

From one of their blog posts

TLS is no longer the exception, nor should it be. That’s why we built Let’s Encrypt. We want TLS to be the default method for communication on the Web. It should just be a fundamental part of the fabric, like TCP or HTTP. When this happens, having a certificate will become an existential issue, rather than a value add, and content policing mistakes will be particularly costly

Fine, if letsencrypt wants to make TLS the default method for communication give us wildcards and unlimited certs.

18

I don’t think it’s reasonable to ask for unlimited anything from a free service.

I understand your frustration, but you’ll have to look at this from both sides: Let’s Encrypt needs to be able to ensure that they can provide an acceptable service level for all users. Removing rate limits might allow you to solve your particular problem, but at the same time it could mean that Let’s Encrypt won’t be able to keep up with the load and become unable to provide a service for everyone else.

Getting feedback about use-cases which aren’t really a good fit for Let’s Encrypt at this time is important, but you’ll also have to understand that a) solving this in a way that scales both in terms of server load and human resources that need to be dedicated to maintaining rate limit exceptions isn’t something that can be done in a day and b) other things are important too, and might be more urgent.

It’s not that your feedback hasn’t been heard (there have been many public statements with regards to rate limits), but it’ll take some more time and thought.

19

Ah, no, the decision that we’ll encrypt everything starts with the Browser Vendors (well arguably it starts with people like me, but the Browser Vendors are the functioning actors here), they’re also best-placed to talk to you about what general solutions could or should exist since you want to run stuff in their browsers and they want to provide browsers to your users.

Let’s Encrypt is one reaction to that decision, not the cause.

20

The bigger problem is HTTPS is a bureaucracy. You have to have money and power to participate. Letsencypt seemed like the one possible hope to get around needing that money and power to buy your way into HTTPS but sadly, by design, they’re ending up like just another dictator sitting on their power throne. They solve the money issue but not the power.

Yes I know that’s not fair but they are effectively one of the kings handing out permission to use the internet. They only allow what they dane to allow which is so far limiting certain people’s abilities to participate.

Why not allow registering domains for unlimited certs and then monitoring for abuse? Why not allow wildcards? Or why not allow applying for them? Instead you have to appeal to some other king (ca) to please let you do your thing on the internet :frowning: