SSL certificate problems with packages.ros.org?

While trying to help someone on ROS Answers with something related to downloading from packages.ros.org, I ran into certificate issues trying to use wget. The following is returned by wget when I ask it to download a .deb:

user@machine:/tmp$ wget -4 https://packages.ros.org/ros2/ubuntu/pool/main/p/python3-rospkg-modules/python3-rospkg-modules_1.2.8-1_all.deb
--2020-06-24 20:46:31--  https://packages.ros.org/ros2/ubuntu/pool/main/p/python3-rospkg-modules/python3-rospkg-modules_1.2.8-1_all.deb
Resolving packages.ros.org (packages.ros.org)... 64.50.233.100, 140.211.166.134, 64.50.236.52
Connecting to packages.ros.org (packages.ros.org)|64.50.233.100|:443... connected.
ERROR: no certificate subject alternative name matches
	requested host name ‘packages.ros.org’.
To connect to packages.ros.org insecurely, use `--no-check-certificate'.

I’ve explicitly asked wget to use IPv4 here, as I first thought the issue was with it trying to resolve IPv6 hostnames and not using the correct certificate.

Using sslabs.com gives a similar warning (here): Certificate name mismatch.

I’ve checked to make sure the machine I’m testing this on is not missing any updates to ca-certificates and related packages. Other machines give me the same result.

Browsers also complain about the hostname mismatch.


Edit: I know https is not commonly used to download packages, and obviously http:// doesn’t have these problems.

I’d recommend avoiding https for packages.ros.org. That domain is a CNAME for OSUOSL’s FTP mirrors and the certificate is theirs.

edit: unintentional double negative.

So this would be a wontfix (or a cantfix)?

Yes I think wontfix is appropriate. I’m sure there is a technical solution but I do not think the time, effort, and logistical overhead are worth taking at the moment.

AFAIK, the official recommendation is not to use https for APT repositories, because it makes local caching, mirroring etc. much harder. Protection against MITM attacks happens on the APT protocol level by checking the package signatures against the APT key. This is not perfect: there was this Remote Code Execution attack last year that exploited a bug in apt-get by inserting unexpected stuff into the protocol stream, and this would have been prevented by https. But that’s the way it is right now.