On Tue, May 15, 2018 at 2:37 AM Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Tue, May 15, 2018 at 01:20:14AM +0000, Richard Barnes wrote: > > [ Adding the mailing list ] > > > > > S 6.6. > > > > | > > | | > > > > | serverInternal | The server experienced an > > internal | > > > > | | > > error | > > > > | > > | | > > > > | tls | The server received a TLS error > > during | > > > > | | > > validation | > > > > > > Can you expand on what this means? Suppose instead I got a 500 during > > > validation? > > > > [[ EDIT - 272c754 ]] > > > > I think this goes back to when the TLS-SNI challenge. It's no longer > > relevant here, so I've removed it. The new TLS-based challenge can > re-add > > it if they need it. > > This is incorrect. It is neeed by HTTP-01 already, because that can > redirect to https://, which then tries to set up TLS, which can fail > even when the TCP connection succeeded. And given flakyness of > validation in general, one does not want misleading errors to make > things even harder. > Good point. I've backed out this change in my working copy. --Richard > > One of the more creative ones I have heard about is misconfigured > servers that interpret the TLS ClientHello as malformed HTTP request > and sends back HTTP 400 Bad Request, which the TLS client then tries > to parse as ServerHello and obviously chokes. This issue is apparently > not that rare, in fact, Let's Encrypt specifically checks for TLS > ServerHellos that look like HTTP replies. > > > -Ilari >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
