Bug#945274: ca-certificates: Deal with multiple certificates per .crt file

[Sam Morris]

Control: tag -1 + patch

Here's a first draft at implementing this:

https://salsa.debian.org/debian/ca-certificates/merge_requests/3


-- 
Sam Morris 

Bug#945274: ca-certificates: Deal with multiple certificates per .crt file

[Sam Morris]

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