On Sun, 30 May 2021 19:55:42 +0200, Theo Buehler <t...@theobuehler.org> wrote:
> On Sun, May 30, 2021 at 01:43:54PM -0400, Daniel Jakots wrote: > > On Sun, 30 May 2021 17:45:22 +0200, Theo Buehler > > <t...@theobuehler.org> wrote: > > > > > Unsure. If people really think this is useful and necessary, I > > > can be convinced. It's easy enough to do. And you're right, curl > > > strips the trailing dot after resolving a host name for SNI and > > > HTTP host header. > > > > Given the current error message makes it hard to understand what the > > problem is, I think it's nicer to fix the user error like curl(1) > > does. > > What I do not quite see is why you would want or expect to be able to > have a trailing dot there. None of nc's examples have it and in > ftp/curl it seems even weirder. I think what happened is I was fucking around with my certificates file, and they're named like example.com.pem. I wanted to check something so I double-clicked on the string and pasted it, and then removed only "pem". I left the trailing dot both out of laziness and because I didn't expect it to break things. I recently learned that you can include the DNS name trailing dot in a url even if it looks weird. But I just tested some more and for instance: https://datatracker.ietf.org./doc/html/rfc6066#section-3 # works https://openbsd.org./ # doesn't work with Error code: SSL_ERROR_ILLEGAL_PARAMETER_ALERT $ nc -zvc datatracker.ietf.org. 443 Connection to datatracker.ietf.org. (4.31.198.44) 443 port [tcp/https] succeeded! nc: tls handshake failed (name `datatracker.ietf.org.' not present in server certificate) (and adding -Tnoname makes it work) so I guess LibreSSL is stricter than OpenSSL?
