From reading Problems validating IPv6 against host running 6to4 - #11 by cpu it seems that issuance for sites with 6to4 addresses was banned. Unfortunately, I need to operate services on networks where the only publicly routable addresses available are 6to4, and just spent a long time trying to track down why I was getting the error "no valid IP addresses found". Up til now I've been running with self-signed certificates, but some clients will not accept that, and of course it's not providing any security against active attackers, so I'd really like to upgrade to using certificates signed by a CA.
I don't think there's any valid security argument against accepting 6to4, as any impact is limited only to sites whose AAAA records point to 6to4 addresses. Surely the alternative of not being able to obtain certificates at all, and using plain http or a self-signed certificate, is far worse.
Using dns-01 instead of http-01 is not really an option for me, as I use DNSSEC with a fully offline signing process, meaning there's no way for automated processes to add records. I would really welcome a DNSSEC-friendly validation process (e.g. issuance of a cert for any CSR with key matching the TLSA record, without further challenges needed) but that's outside the scope of the immediate problem here I think.
Could support for 6to4 addresses please be reinstated?
I'm curious: presumably you have a public-facing IPv4 address in order to use 6to4. Why not use that address directly in an A record?
One way to make dns-01 work for you: You could use CNAME or NS records to delegate _acme-challenge.example.com to a zone that can live-sign DNSSEC responses.
Because I only have one. In theory it might be possible to setup haproxy or similar to route diifferent hostnames in a way that would avoid the risk of letting one device request issuance of certs for another, but that imposes central management I don't want to be stuck with. Also it's great to have addresses that aren't subject to perpetual scanning of 0.0.0.0/0 (although it's likely Shodan and similar will pick up sparse v6 addresses from CT logs if they're not doing it already).
That's potentially an option, and one I might consider if I can't find another working solution, but it requires setting up a good bit more infrastructure to do it.
Don't you already have that issue now with 6to4 too? What prohibits the users of those other devices use the same 6to4 address?
Also, there are some other free SSL CA's providing free certificates through their ACME server, although I don't know if they'll accept 6to4 addresses.
@jsha, could you explain your thinking about the risks of these addresses these days?
It seems like @tialaramex was pointing out that the 6to4 provider acts like an ISP-except-not and that it might have many different "subscribers" and would be capable of causing misissuance—on its own initiative—for any one of them.
While this seems totally true and does seem like a legitimate source of misissuance risk, I wonder how different it is from other ISPs and intermediaries which also have this same power. For example, a backbone ISP which is the sole upstream route for a customer could also perform a routing attack to cause misissuance for that customer's domain, while the customer's own hosting provider could do the same. It seems like the issue @tialaramex was highlighting included the undefined relationship between the 6to4 provider and the end-subscriber, where with a hosting provider, for example, the relationship is better-defined by a contract. But on the other hand, you don't have any direct contraction relationship with lots of backbone ISPs that carry you traffic and can also choose to participate in attacks against you.
I feel like there are a lot of mysterious and informal Internet infrastructure providers like, say, DNS hosts, where the incentive and legal obligation structure is comparably bad to the 6to4 provider's. Let's Encrypt sees people who've hosted their (non-DNSSEC-signed) DNS records with all of these services
and they all have the capacity to cause misissuance, and to some extent we don't know what the incentives of most of them are. Would Let's Encrypt be interested in having a broader look at trusted Internet intermediaries in the issuance process as a whole?
I'm surprised at the mention of DNS hosts. That seems like a clear example where someone's DNS host is a service provider for them and so at least in theory has an obligation to provide correct and non-malicious service.
It's true that backbone providers are given a lot of trust - and in particular the ability to not just MITM traffic that passes through them, but also advertise BGP routes. But trusting them to do that is somewhat unavoidable. Trusting 6to4 providers is somewhat riskier, and also very avoidable. It seems like it is still not worthwhile to accept that risk, particularly given that the 6to4 anycast prefix is deprecated.
If you don't have access to a competent ISP that offers native IPv6 access, you're probably best off getting a Hurricane Electric tunnel or other VPN-like connection to a provider that does. It'd probably be more reliable than 6-to-4 is as well.
I agree risks are there, but they're far less than the risk of running plain http or self-signed certificates, and the risks only apply to someone who chooses to take them by pointing an AAAA record at a 6to4 address. As such I don't think it's a reasonable policy to ban their use.
Does LE's validator for dns-01 support the case where the auth nameserver is on 6to4? That would make it fairly easy to use dns-01 by delegating the _acme-challenge subdomain to a second address (among the nice big /48) on the device itself where a special acme-only nameserver is listening and doing live signing of responses.
Hurricane Electric also gives you a /48 if you request it (one click) and up to 5 tunnels with a standard account iirc which is an enormous amount of address space.
I've been issuing Let's Encrypt certificates with them for years now and highly recommend their tunnel if you can't get native IPv6.
