Color me very confused, but I can't distinguish a difference between vhost based
Host: header selection in the "http-01" case, and SNI identification
in the case of
"tls-sni-01". Am I missing something? Discussion pointers?

For protocol reasons, "dns-01" seems outside the scope of any mod_md solution.

On Fri, Jan 12, 2018 at 6:58 AM, Stefan Eissing
<> wrote:
> I try a high level, short summary of the current ACME "TLS-SNI" issue:
> 1. There are 3 basic ways to verify domain ownership:
>   a) "http-01" on port 80
>      requests /.well-known/acme-challenge/<SomeChallengeToken>
>      response: signed token as base64url
>   b) "tls-sni-01" on port 443
>      client hello with SNI for "<ChallengeToken>.acme.invalid"
>      serverhello with matching, self-signed certificate
>   c) "dns-01" where you provide a signed challenge at a
>      acme-challenge.your-domain TEXT entry underneath your
>      domain.
> a) and b) are supported by mod_md. Which method is actually used
> depends on
>   - what the ACME server offers, for each dns ownship check it
>     sends the list of available challenges
>  - what the local Apache instance can do, e.g. does it listen
>    on the ports required
> This week, Lets Encrypt got informed by a security researcher
> that challenge b) "tls-sni-01" can be exploited in several shared
> hosting environments where customer are allowed to upload self-signed
> certificates for domain names of their choice.
> Let's Encrypt then immediately disabled "tls-sni-01" and informed
> the people on various list and social media about it. Mitigations
> are currently discussed. There is a good chance that it might stay
> disabled in general, but kept available for already existing accounts.
> "Disabled" here means that when asked to verify, the LE ACME server
> will no longer offer "tls-sni-01" as challenge method. mod_md
> scans this and will use the alternative "http-01", if offered, and
> if local port 80 is listened to. If no usable challenge method is
> found, an ERROR is logged.
> This means that mod_md continues to work for people with port 80
> open and will ERROR for instances where only port 443 is available.
> There is no way around this.
> Other ACME clients can only work around this, when they open port
> 80 themselves and listen for challenges. Some do, some don't. If
> your firewall is blocking 80, none will succeed.
> Note, some clients need updates as they do not scan the list
> returned by the server. Some ACM enabled server say they do
> not care either but try randomly all methods they know, so eventually
> it will succeed. *shrug*
> So, our users, if they had the module, would have survived this
> quite well, I think. Which is no guarantuee for the future, but still...
> Cheers,
> Stefan
>> Am 12.01.2018 um 13:22 schrieb Eric Covener <>:
>> On Fri, Jan 12, 2018 at 6:32 AM, Steffen <> wrote:
>>> Now mod_md contains features which are not supported anymore !
>>> For SSL only config mod_md is not usable anymore, see
>>> Propose to change mod_md regarding above, now I vote -1.
>> What do you propose to be changed?  Most of us aren't following this
>> space very closely.

Reply via email to