> > This removes the "tls" error. I do not think this is appropriate, as http-01 > can redirect to https://, and such validation can hit TLS errors.
Good point. I didn't consider HTTP-01 :80 -> :443. Restored in https://github.com/ietf-wg-acme/acme/pull/390/commits/3441d4435a6e8454fa68749231d801ec4f894bbc Thanks Ilari, - Daniel / cpu On Fri, Jan 12, 2018 at 1:23 PM, Ilari Liusvaara <[email protected]> wrote: > On Fri, Jan 12, 2018 at 12:45:55PM -0500, Daniel McCarney wrote: > > Hello folks, > > > > As I'm sure many of you are aware by now, recent developments[0] [1] [2] > > have identified real-world server/hosting configurations that violate the > > assumptions of TLS-SNI-01 as well as its currently specified replacement, > > TLS-SNI-02. > > > > In light of these issues and the feasibility of addressing them across > the > > entire Internet it seems prudent that the ACME specification remove this > > challenge type pending the development of a better alternative > > (TLS-SNI-03?). I've submitted https://github.com/ietf-wg- > acme/acme/pull/390 > > to make this change. > > > What are the thoughts of the other WG participants? > > This removes the "tls" error. I do not think this is appropriate, as > http-01 can redirect to https://, and such validation can hit TLS > errors. I think separating TLS failures and TCP failures is useful for > debugging. > > Example of TLS failure is that somewhat common misconfiguration where > port 443 is not using TLS: That is _not_ a connection error, the error > happens inside TLS. Saying it is a connection error is misleading. > > > Other than that, I agree that we can't block on TLS-SNI-03, or > whatever -> Punt it to future draft (work on which should start soon > after getting acme-acme through IESG). > > > -Ilari >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
