Different forms of writing the same IPv6 address are considered different servers

[Mihara]

Consider an Yggdrasil network bare IP Gemini server, 200:804a:.....:bc7c:9ba9.

If I direct Lagrange to gemini://[200:804a:.....:bc7c:9ba9]/, it will correctly arrive to the same address as gemini://[200:804a:.....:bc7c:9BA9]/, (note the uppercase). However, it will consider both different servers and ask me to trust the same certificate again.

In both cases, it will also fail to identify that the certificate includes the correct IP address ("received a certificate for a different domain", etc) - not entirely sure why, but mkcert generates certificates which list IP addresses separately in Subject Alternate Names (DNS:xxxx.ygg, DNS: xxxx.ygg.at, IP Address:200:....:9BA9) which is probably the reason and probably should be supported.

Notably, altering the upper/lower case on a domain name will not cause Largange to misrecognize a server this way, the certificate remains trusted. But it will cause it to generate a different theme seed.

[skyjake]

I suppose IPv6 literals could be normalized to lowercase for internal handling.

I consider this a very low-priority issue, though, so let's see when/if it will be addressed.

[Mihara]

Normalizing is less of a problem than not accepting that the certificate contains a correct ipv6 hostname, though.

How does one generate a certificate that Lagrange will consider correct for a given bare IPv6, assuming no case shenanigans and the shortest possible form with collapsed zeroes?

[Mihara]

Amendment to the above: gg (part of gmid) has no problem reaching the same server at the bare IPv6 IP, even though otherwise it's even more meticulous about hostname matching the one given in the certificate than Lagrange, and will just drop the connection in case of mismatch. Lagrange, however, complains that the hostname doesn't match the one given in the certificate. (This is actually why I started experimenting with changing case and trying other forms of writing the IPv6 address in the first place.)

[Mihara]

Further messing around seems to indicate that Lagrange compares the IP to DNS alt names, but not IP alt names. I.e. adding one with DNS.5 = 200:804a:....:bc7c:9ba9 works, while the one listed in IP.1 = 200:804a:.....:bc7c:9ba9 (and rendered in uppercase by openssl when printing the certificate) does not match.