RFC: A way to use valid https with local hosts

Issuance Policy
1

Hi there,
I’d like to discuss the viability of a free service I’m contemplating.

The goal is to offer developers a way to use valid https for their projects locally, automatically.

Before you now yell ‘self-signed certs’ at me, please hear me out. :smile:

The problem with self-signed certificates is that they require manual work, are (somewhat) host dependent and cause e.g. the testing/ci environment to differ from production.

All of the previous attempts to solve that problem relied on the private keys made public and therefore being compromised (http://readme.localtest.me/#ssl, https://www.npmjs.com/package/localhost.daplie.me-certificates) - which (correctly) caused them to be revoked by the CAs.

How about the following (so I can finally put the domain ‘ssl.fun’ to good use):

  • ssl.fun allows the user to programmatically register a subdomain (e.g. example.com.ssl.fun)
  • It integrates with common acme clients and responds to the DNS-01 ownership challenge
  • by default all A records point to 127.0.0.1

As a result the user (target audience developers) are able to test things locally with a valid https certificate.

The users themselves do the certificate request directly and only they have access to the private key, hence the certificate is not compromised, which was the main issue with spiritual predecessors in the past :slight_smile:

I read the guidelines of common CAs (including LE) closely and there is nothing preventing a DNS record to point to 127.0.0.1

There are some implementation details here I skipped (e.g. after a subdomain is initially registered ownership is proven with signed requests, to prevent others from issuing certs for the same subdomain).

And of course the developer is still not allowed to distribute their certs/private key in client apps (e.g. spotify, blizzard, dropbox) as this again would compromise the certificate.

What do you think of this approach, any issues I overlooked?

I just cannot accept that we’re stuck with cumbersome self-signed certs for the next 20 years of local development, there’s too much collective developer time wasted here. :smile:

Cheers!

2

A counter-argument I thought about and a possible response:

the user does not have real ownership of the subdomain
I’m don’t think that holds true, as long as the subdomain provider (e.g. ssl.fun) acts in good faith.
As long as the service is preventing others from using the same subdomain it should meet the ownership requirements.

Otherwise domains from the likes of afraid.org or even freenom.com should be exempted from being able to have certificates issued. :slight_smile:

3

You are welcome to build that today, nothing needs to change in order to achieve it.

4

There’s currently a 20 certificates per domain limit from LE, hence I couldn’t build that service without “blessing” from LE. :slight_smile:

5

All you need to do is have your domain registered as a non-IANA Public Suffix: http://publicsuffix.org/ (which you can do for free).

This is exactly what afraid.org have done, they’re just missing a convenient way to do DNS-01 validation.

6

I tried that already :slight_smile: Unfortunately my request got rejected (as I assume it sounded a little fishy and as a ploy to maliciously bypass LE limits, which is definitely not my intention):

Hence this RFC to clarify if a service like this would be ok so I can request a limit increased directly from LE.

7

You can apply for a domain-based rate limit increase from Let’s Encrypt, but I guess it’s possible that they might also consider your service to be subversive :laughing: .

1 Like
8

Haha, it’s definitely shaking things up a little :smiley: But again, there’s no malicious intent from my side, I just want to make local ssl more fun :slight_smile:

I thought discussing the viability publicly would be a good prerequisite before requesting a rate-limit increase.

9

I resolved this problem by implementing IPv6 and using wildcard certificates. HE.com provides the IPv6 service, as my ISP does not. I can firewall off some servers so no external access.

10

That means you had e.g. local.domain.com pointing to your (local) IPv6? :slight_smile:

11

No, I use a public internet domain e.g. example.com. My IPv6 IP addresses are also public IPv6 internet addresses, which you can get via your ISP or he.com. Some of my servers have public and local access, particularly the one renewing Letsencrypt. Others are firewalled off to prevent public access. The names of all my servers are publicly available via DNS but not all accessible.

12

Hi @berstend

I wouldn’t use such a service. Reasons:

  • A lot of things are done online. I am using *.example.com, so test.example.com can be used.
  • Some things are done offline / local. But a simple host entry

127.0.0.1 sillyname.example.com

allows the use of the *.example.com - certificate local.

13

Good point, having local.domain.com or something similar point to localhost seems to be common practice. Actually my proposal would just simplify/automate this exact scenario. :slight_smile:

Personally I see some issues with this approach:
a) In order to get the example.com cert in the first place you need to put something online
b) modifying /etc/hosts is again machine specific and not really a portable solution
c) All of these steps require manual, human work

The idea behind this RFC / service idea is to automate these things for local projects that haven’t yet seen the light of day. :slight_smile:

14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.