SSL cert problems accessing dweb.link with IPNS about infra HOT 5 CLOSED

Awesome stuff, thanks all for making this work!

from infra.

Hi @eminence,

thanks for the report! I believe this is a known bug, but I can't find the ticket. I suspect if I say @lidel's name three times, he just might appear with some context. :)

The message from Firefox is especially confusing since it certainly looks like ipfs.io.ipns.dweb.link matches the wildcard *.ipns.dweb.link

One of the "fun" quirks of DNS is that wildcards only work for that 1 level and but not multiple levels (sub-subdomains). The wildcard cert we have for *.ipns.ipfs.io would be valid (but not functional) for just ipns or io, but not ipns.io. Note: browsers do not support a super-wildcard cert like *.*.ipns.ipfs.io or similar.

So the browser errors are to be expected given the domain we redirect to. That said, we shouldn't be redirecting to such a domain. It should be a <cid> of the ipns record (or somesuch).

It might make sense to move this to go-ipfs repo, but I'll hold off on moving for now.

from infra.

Ahh, I see. That is indeed a fun little quirk, though a bit disappointing. I guess in theory the redirection would be OK over http, but since dweb.link has HSTS, that's not relevant here. Turns out getting IPNS, HTTPS, and custom domains is a bit challanging!

Many thanks for the info

from infra.

If you mention me only once, it takes longer, but I will appear anyway! ;)

Indeed, it is unfortunate that DNSLink names trigger TLS error.
As @mburns noted, we can't have a certificate for more than a single wildcard level.

Potential solutions/workarounds are listed in ipfs/in-web-browsers#169:

• Personally I find (C) the most pragmatic
  • works with existing infrastructure, we would just add support for single-label-encoding to go-ipfs and that is all
  • TL;DR idea behind (C) is something like:
    https://dweb.link/ipns/my.v-long.example.com → https://my-v--long-example-com.ipns.dweb.link

Note:

• This is not a problem on local gateway at *.ipns.localhost because there is no TLS.
  • Sidenote: we don't need TLS because localhost addresses do not hit network and should be marked as Secure Contexts. This is already true in Chromium and will be the same in Firefox 84. We are working with Igalia to ensure that is indeed the behavior in all browsers and part of web platform tests (WPT) – recent updates can be found in ipfs/in-web-browsers#109 (comment)

from infra.

Thanks for appearing with some good info @lidel :) since this is a known issue, I'm happy to close this issue and move the discussion to the two in-web-browsers ticket you linked.

from infra.