The recent @letsencrypt shutdown of TLS-SNI-01 validation (due to idiotic hosting providers) is very disappointing. It was by far the most convenient, hands-off, universal validation mechanism. https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188 …
-
Show this thread
-
Replying to @marcan42 @letsencrypt
Is there any way to make a tls-sni-03 that doesn’t suffer from the same issue? I’m thinking not. The DNS just doesn’t give you the information to distinguish between the site owner and anyone on the same server - except through what it serves for the domain itself.
2 replies 0 retweets 1 like -
(but of course you don’t want to have to swap out the site’s cert entirely.)
1 reply 0 retweets 0 likes -
Idea: Allow using a SRV record to specify a different host/port which the CA will then verify with http-01. That way you don’t need dynamic DNS. Drawback: some consumer DNS hosts might not let you create SRV records…?
1 reply 0 retweets 0 likes -
Replying to @comex @letsencrypt
That sounds reasonable. Another option discussed on m.d.s.p is to use TLS NPN (e.g. 'acme') as an assertion that the server is secure. This requires code changes though.
1 reply 0 retweets 0 likes -
Replying to @marcan42 @letsencrypt
Silly idea: a method where the server tells you what IP address it’ll be verifying from, and you add an iptables rule based on source IP
1 reply 0 retweets 0 likes
I think part of the rationale for not publishing validation IP addresses and potentially having them be unpredictable is to hinder e.g. BGP attacks to partially hijack the routing of a given IP.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.