Package: ca-certificates
Version: 20190110
Severity: normal
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
When joining a machine to a FreeIPA domain, the domain's trusted
certificates are placed in
</usr/local/share/ca-certificates/ipa-ca.crt> for integration with
ca-certificates.
If multiple certificates exist in FreeIPA's trust store, they will all
be written to this file.
This prevents OpenSSL clients from trusting *any* certificate within the
file:
# openssl rehash /etc/ssl/certs
rehash: warning: skipping ipa-ca.pem,it does not contain exactly one
certificate or CRL
ca-certificates does not document whether it intends to cope with such
an input file.
If not then it should print a warning when update-ca-certificates is
run, and ignore the input file entirely (to prevent inconsistency with
whether a CA is trusted depending on whether the client uses the jumbo
/etc/ssl/certs/ca-certificates.crt file, or whether it uses the OpenSSL
hash symlinks). Assuming this is the case, I filed #924590, which is
<https://pagure.io/freeipa/issue/8106> upstream.
Alternatively, ca-certificates could take it upon itself to split an
input file containing more than one certificate into several files
containing one certificate in, say, /var/lib/ca-certificates, and then
symlink _those_ into /etc/ssl/certs rather than the original file; in
which case the freeipa-client bug can be closed without further action.
If you were going to do that then there is an edge case to consider:
FreeIPA let's you have multiple certificates for the same authority
(i.e., Subject DN) within the trust store. This happens if, for
instance, a CA's certificate was re-issued to extend its validity
period. This will cause collisions when 'openssl rehash' hashes the CAs
Subject DN in order to create its symlinks. update-ca-certificates would
have to notice this collision, and correctly choose the certificate with
the latest notAfter date && with a notBefore date in the past? the exact
logic is up for debate).
I've marked this bug as blocking the freeipa-client bug because the
decision of whether multiple certificates within a single file
determines whether changes have to be made in freeipa-client or not.
I'm happy to send a patch implementing either behaviour, if you can tell
me which one you want.
- -- System Information:
Debian Release: 10.2
APT prefers stable-updates
APT policy: (550, 'stable-updates'), (550, 'stable-debug'), (550, 'stable'),
(530, 'testing-debug'), (530, 'testing'), (520, 'unstable-debug'), (520,
'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64
Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages ca-certificates depends on:
ii debconf [debconf-2.0] 1.5.71
ii openssl 1.1.1d-0+deb10u2
ca-certificates recommends no packages.
ca-certificates suggests no packages.
- -- debconf information excluded
-----BEGIN PGP SIGNATURE-----
iQJGBAEBCAAwFiEEyqqqGsppqDqJKxhV0gtCAlzaJ7kFAl3XpdASHHNhbUByb2Jv
dHMub3JnLnVrAAoJENILQgJc2ie5Uv4P/RyRQouGS0X+HlR8Ay2SIX9arCHk9HOm
aVEM/O6hH3qxDU7b1FK1PnWVZarAaTUxFLHKFVwtDs5GapV6wBoyMCCD6pX+VzdM
db32tGbEz8Z4N3oYoka1Wy4NZE4c4VSUo/n4SWDAu0hrFXtWFJ1DUNuiAUBFQIWX
nckrEJFfCJolQOcTbkLjA5VcugP/60nUEYRGEdMgOXMPeJRvo13+nitOEgsVC7OW
imvZ5Ni9k/Lvo6uREVofRG0Is+WsP1UGOhh/B0XoIrVXf5UP83GDgudH9KvCTiDL
8BwgeEgdtliEpSXBcG8V3N0VR/1xrH2AXhL+xIt9MVjMkRtotn2CYumIdGKX6eDm
phe1Q3JRMAOeFQnPRTduxbqtYpNCSas1oWEOed4Y4ahq9zflJt97HgNgCeNPzdrW
WW5tWhE90fDwAc4R4VAmiPFpu1X6hH3Fk9C+9i7kFoQ6tPJMn6O1z1sRraAJZlJs
n6S5VXsJwHVQ0I0gwmxAOMEzXf17Lqlsx44pxn/ZTw+9vz8VjHtVJBXWfaRQByuJ
AJlHwI95zQdy97eCXy5yO9FlSDNM2vKxPmgXjQ1kk75OYOPFuxljTCbWoseDHlNc
VXuMzzuKQm9Pd2L73ig41imB9SLk1kfjUw3uxIaMR7EW7TwfykvYTS8XY63tTGyB
A+G3oA03R0WA
=1LeL
-----END PGP SIGNATURE-----
