> 20170717 was the previous version in testing (20180409 introduced the > `openssl rehash` usage and was kept from testing for an important bug). > > 20170717 used the perl c_rehash utility. If you need it, here it is! > > http://snapshot.debian.org/package/ca-certificates/20170717/#ca-certificates_20170717 > > <http://snapshot.debian.org/package/ca-certificates/20170717/#ca-certificates_20170717> >
Thanks, that site is a keeper. :) So installing ca-certificates (20170717) with the latest openssl (1.1.1a-1), does produce the hashes in /etc/ssl/certs when doing an ARM 32bit build via QEMU. I used the following dockerfile to make the test image: FROM arm32v7/debian:buster-slim ENV DEBIAN_FRONTEND noninteractive COPY ca-certificates_20170717_all.deb /tmp/ca-certificates_20170717_all.deb RUN apt-get update && \ apt-get install -y openssl && \ dpkg -i /tmp/ca-certificates_20170717_all.deb && \ apt-get install -y curl CMD [ "curl", "-sSL", "https://www.google.com"] A container from it ran fine, pulling back Google. One interesting thing is that the 382 syscalls were still present in the build, so that may be a red herring: ... Preparing to unpack .../ca-certificates_20170717_all.deb ... Unpacking ca-certificates (20170717) ... Setting up ca-certificates (20170717) ... Updating certificates in /etc/ssl/certs... qemu: Unsupported syscall: 382 148 added, 0 removed; done. Processing triggers for ca-certificates (20170717) ... Updating certificates in /etc/ssl/certs... qemu: Unsupported syscall: 382 0 added, 0 removed; done. ... The only other thing I noticed (which certainly may not be related) is that a a few of the CA cert filename must have some crazy UTF8 characters that get encoded (“NetLock_Arany”, “RKTRUST_Elektronik_Sertifika_Hizmet_Sa”, “k_Sertifika_Hizmet_Sa”). Just seemed odd, and potentially something that could trip things up. Thanks again...