W.r.t. http-acme — as far as I understand; the current 0.4 draft
(https://tools.ietf.org/html/draft-ietf-acme-acme-04) has the Well known fetch
going to port 80:
Section 7.2, page 47
3. Dereference the URI using an HTTP GET request.
This request MUST be sent to TCP port 80 on the server.
The new draft: (https://letsencrypt.github.io/acme-spec/ also numbered ‘’04”)
in section 7.1 ‘Simple HTTP’, does a 180 degree change on this ‘default’: to an
httpS default with an option to explicitly move it to HTTP with:
"tls": false / false
With the explanation that:
If this attribute is present and set to “false”, the server will
perform its validation check over unencrypted HTTP (on port 80) rather than
over HTTPS. Otherwise the check will be done over HTTPS, on port 443.
without the clarity of a MUST. And it then continues 3 paragraphs down with
solving* the bootstrap issue by
If using HTTPS, the ACME server MUST ignore the certificate provided by
the HTTPS server.
I am currently puzzling over an implementation that makes it as easy as
possible to bring up an HTTPS webserver if you do ‘nothing’ but flag the
VirtualHost config with something like 'letsencrypt on’ - and then defers to
sane ‘SSLLabs A+’ level SSl defaults.
What I’d like to understand is
- What is the value of doing the exchange over HTTPS (as this is made the
default as opposed to the current 80) when one does not check the certificate
nor retains the ACME Servers its view of that cert in the further exchange (or
uses the RSA key of the challenge to self sign) ?
- Would there be any good reason to not allow the specification of a port
number ?
The reason for the first question is that keeping the process simple is
desirable from an implementers point of view - as you want it relatively robust
because some of the backend server config processes need to hark back to
pre-chroot and pre-fork/pre-setuid() as to get secure persistence of state and
(private) keys (which you want be a social-internet citizen that does not willy
nilly overload the lets encrypt infra every startup).
The reason for the latter question is that it 1) allows for non-root > 1024
settings and 2) may be more ‘robust’ to allow the server to open a relatively
random high ephemeral port for a short time during startup that does not give a
false sense of having the actual virtual host yet up; or a HTTPS only
virtualhost shortly seeming to be misconfigured and appearing on port 80.
Thanks,
Dw.
* Well not ‘solving’ it - as the cert seen by the ACME server or the session
key negotiated are not mixed into the response as to allow the Client to verify
that there was no MITM during this exchange — as this is sort of deferred to
later - when you find out that the cert signed is not one you have a private
key for. Or by for exampling insisting that this certificate that is ‘ignored’
is in fact one self-signed by the same RSA key used in the token dance (which
would be probably easiest for implementors if HTTPS was a strong
default/guidance/best-practice).
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
