Re: [Acme] Why "HTTP verification"

[Martin Thomson <[e-mail]>]

On 2 December 2014 at 11:15, Peter Bowen <[e-mail]> wrote:
> The primary case where I see a problem is when the site already has a
> trusted certificate and wants to use ACME to get a new certificate.
> They are unlikely to want to replace their working certificate with a
> self-signed certificate.  So the proof would need to happen at the
> HTTP layer, not the TLS layer.


I think that we can do better than this.  That's why I opened
<https://github.com/letsencrypt/acme-spec/issues/26>.

The protocol requires proof of possession for establishing a request
for a certificate.  Requiring a self-signed certificate means that you
can only use the simpleHttps (I don't see an HTTP variant here), for
completely new installations.  Presumably renewals can be protected by
periodic checks to see that the site remains valid, but it does little
for a new key.

I think that as long as there is some way to generate POP for the key
that a certificate is being issued for, it makes little sense to
require that the HTTPS connection is served with that key.  I
understand why the proposal has that, but it makes it impossible to
renew.

The SNI verification at least allows the server some information it
can used to select a self-signed certificate, and this could use ALPN
for the same thing, but that seems like overkill.  I think that I
would like to be able to have a check like this for key rollovers as
well as the initial setup, so I think that a different design is
appropriate.