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

Reply via email to