That would be horrible… If you contact a server foo.example.org it should respond with the cert for it, not with a cert for bar.example.com. That is what SNI is all about after all (as your client connects to an IP and SNI is telling the server which hostname it wanted to connect to, so the server can respond with the right cert).
I somehow doubt a highlevel interface like libcurl even exposes such a detail. The bugreport you reference is speculating about all sorts of things, so one of them might be it. I would personally consider a bug in libcurl-gnutls most likely (note that this is not always the library behind curl. It seems to be in newer releases, older releases use libcurl (the openssl variant)). As an additional datapoint: On Debian stretch the command "/usr/lib/apt /apt-helper download-file 'https://deb.nodesource.com/gpgkey/nodesource.gpg.key' 'nodesource.gpg'" works just fine, so in newer versions that seems resolved. Anyway, this report is a mixture between a feature request we will not be implement and a bug we don't have – as such marked as invalid in apt as you are better of finding the real culprit and report a new bug against that. P.S.: apt doesn't need https for integrity. Given the sorry state of CAs (compare e.g. StartSSL/WoSign) that wouldn't really be secure… There are other reasons you might want https even in case of apt, but blank statements aren't making anyone more secure – they just make them feel secure. ** Changed in: apt (Ubuntu) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1551464 Title: apt-get sources should support TLS SNI (server name) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1551464/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
