> 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...