mdhardeman

9 ms·

1. 61.▲
   by mdhardeman 9y ago

   I concur in full with your commentary here. LetsEncrypt, through thoughtful planning and action -- even when it was inconvenient for them -- has established themselves as a shining beacon of best practice. For better or worse, when you beco
2. 62.▲
   by mdhardeman 9y ago

   I think the only fix is to create TLS-SNI-03 in which the only dnsName component in the self-signed certificate is a well known child of the domain label to be validated. Validating www.abc.com, SNI and dnsName is well-known-acme-pki.www.ab
3. 63.▲
   by mdhardeman 9y ago

   If it's something like that, the fix would be to define a tls-sni-03 with a couple changes: The SNI name indication from the validation MUST be a child element desired certificate domain label. (If I want a cert for a.com, the SNI indi
4. 64.▲
   by mdhardeman 9y ago

   I can totally believe that may exist too. After all, for the CDN / Hosting company, what's the real risk? It wouldn't shock me if lots of infrastructure lets you board a new and novel host label that hasn't already been
5. 65.▲
   by mdhardeman 9y ago

   I just read the details of the tls-sni-01 challenge again. I can certainly see a problem. With respect to the final validation stage, where the validator is communicating with the TLS endpoint, all the information needed to satisfy the val