"Generic" support

[JetForMe]

"Generic" support

[jdkasten]

Yes, our plan is to offer it both ways. We will offer a generic variant (authentication without the configuration) and also offer configuration without the authentication (Perhaps the user already received a cert through another means like an OV or EV cert and they would like to quickly configure their server with HSTS, OCSP Stapling ect. )

Yes, we actually currently offer manual naming. Just tack on the name as the final argument which is shown in the second example in the demo video (https://www.youtube.com/watch?v=Gas_sSB-5SU)
Edit: clarification about the manual naming option

[JetForMe]

Awesome, thanks! Please get the "real" CA set up, I'm eager to use this! :-)

On Nov 18, 2014, at 13:37 , James Kasten [email protected] wrote:

Yes, our plan is to offer it both ways. We will offer a generic variant (authentication without the configuration) and also offer configuration without the authentication (Perhaps the user already received a cert through another means like an OV or EV cert and they would like to quickly configure their server with HSTS, OCSP Stapling ect. )

Yes, we actually currently offer manual renaming. Just tack on the name as the final option which is shown in the second example in the demo video (https://www.youtube.com/watch?v=Gas_sSB-5SU)

—
Reply to this email directly or view it on GitHub.

Rick Mann
[email protected]

[schoen]

Just to be clear, a generic version would definitely require some way to prove control of the domain, which might require running a server process of some sort temporarily to complete the domain validation process. For example, we might want to spawn an Apache process (or something else) for a minute to complete the validation process and then export the certificate.

[JetForMe]

Huh, really? Because I don't currently need to run a server in order to get certs from InstantSSL.

[jdkasten]

They are using email domain validation. We hope we do not have to support such a validation mechanism because we believe it is weaker than our existing validation mechanisms and it increases the attack surface of our project. Our domain validation mechanisms require a demonstration of arbitrary control over the process running at the protected ports. I believe we can provide this for the generic case with other processes as @schoen stated, (probably not as large as Apache... that was just an easy to understand example)

[JetForMe]

If I'm running my Resin server on the port, will that work? Must it run on 443, or can it run on 80? Does it have to provide a specific response to requests?

[schoen]

According to the currently-proposed validation method, it does have to provide a specific response on port 443, and that has to be at the TLS level, not at the HTTP level. It might be easier to start up a separate process of some sort ephemerally to handle the proof than to change the Resin code to support this (just as a matter of total programming effort, not because the technique for doing this is secret or anything).

The Let's Encrypt CA might also decide to support some combination of other validation methods, but that's a policy question that will have to be addressed sometime between now and when the CA starts issuing certs. For the currently-proposed main validation approach, you do have to be able to do some stuff at the TLS level which requires (at least) reconfiguring the web server in a specified way. As James says, the idea is to provide a stronger level of assurance than some existing validation methods that are in wide use today, while still offering a method that can be done entirely automatically, without human intervention.

[JetForMe]

I'm clearly misunderstanding something, since I would have thought I'd need a cert in place to support a TLS connection in the first place. Seems a bit of chicken-and-egg.

It would be great if the lets-encrypt program would handle that automatically (i.e. the port 443 server should be built-in), and just require running it with su privileges. That way, I don't have to install apache (or any other server) on the box.

[schoen]

The verification process uses a TLS connection on port 443 as part of proving control of the domain even if there is no publicly-trusted cert yet. Instead of checking that the TLS listener presents a publicly-trust cert, the verifier checks that it presents certain information that the verifier challenged it to present as part of the ACME protocol.

We're discussing making a generic ACME client that does listen on port 443 on its own, and then we won't have to depend on any particular web server or set of web servers in order to complete the verification process.

[jdkasten]

Sorry, let me try to clarify. You are right... everything will be built in. You can still just run a single program with su privileges and it will work. It may require that you give it the name of your existing webserver so that it can properly interoperate, but it will still be close to the interaction you saw in the demo video.