Add support for the Automatic Certificate Management Environment to warp

[werksjan]

Since Let's Encrypt will start it's public beta in early december, an ACME-enabled CA would be available. Adding support for the protocoll to warp in time, as does the Let's Encrypt Client with Apache, would be a good statement pro https.

I could imagine warp default to launching warp-tls alongside http and self-requesting an appropriate certificate from any free, trusted DV-CA as it sees fit (no certificate avaiable, certificate about to expire).

This could enable https working out-of-the-box.
At least a configuration flag for warp-tls would be great that could toggle this behavior.
The only problem I see at the moment is to let warp-tls know the intended domain names it should ask for certificates for.

[kazu-yamamoto]

I'm strongly interested in let's encrypt, too.

self-requesting an appropriate certificate from any free, trusted DV-CA as it sees fit

For this, how should we modify warp-tls?

[werksjan]

I have been thinking about that for a while.

1. This might be a question of modifying the default settings to hold appropriate, sensible default values that allow to use a afaik yet-to-be-done ACME client to do so.
   The downside would be that this cannot cover the domains the certificate should be valid for.
2. Another possible way could be to integrate a small WAI-App that allows user interaction as long as no certificates are found. (think: wordpress installation progress)
   The downside here is that this can introduce problems if anyone deployed such a configuration reachable from the outside because anyone could get certificates then.
3. The third way I can think of would be to use the beforementioned ACME client whenever no certificates are found, prompting the developer starting warp-tls w/o certificates for the needed information.
   This might cause problems w/ current use cases such as yesod devel.

Another problem might be certificate renewal and integration w/ HPKP. To be reliable and cause no additional problems, checking the status should be done regulary. For example on startup and then scheduling a thread to renew the certificate and modify the HPKP-Headers as indicated, which schedules another one for actual switching out of certificates.

[werksjan]

As Let's encrypt started it's open beta in the meanwhile, I'd like to bump this again. Probably a good time, too, to keep an eye on new hackage package releases may helping us out by implementing at least part of the features.

[kazu-yamamoto]

My current concern is SNI. If I understand correctly we need to issue two certificates for, say, example.com and www.example.com. The current SNI support by the tls library is poor(haskell-tls/hs-tls#103), I believe. We enhance SNI both in WarpTLS and tls.

[kazu-yamamoto]

Anyway, I will start to implement the support of let's encrypt with a single certificate.

[mithrandi]

I think the most natural way to perform the ACME challenge is the tls-sni-01 challenge type which is performed over the same port you would have to listen on to serve HTTPS anyway. However I'm not sure of what the state of SNI in warp-tls is.

I just finished implementing something similar in Python for the Twisted networking framework (https://github.com/mithrandi/txacme); I think this would be an excellent thing to have in the Warp ecosystem.

[kazu-yamamoto]

getClientSNI is now provided bytls.

[tolysz]

I am using https://github.com/lukas2511/dehydrated with the DNS challenge for keter bundles. I would need to add reload certificate on file change.