#1107629 ca-certificates: Provide separate package for email certificates

Package:
ca-certificates
Source:
ca-certificates
Submitter:
Peter Wienemann
Date:
2025-07-23 18:59:01 UTC
Severity:
normal
#1107629#5
Date:
2025-06-10 20:58:28 UTC
From:
To:
Dear Maintainer,

to fix #721976 the ca-certificates package has dropped email certificates.
As a result signature verification of signed mails using S/MIME fails in
some cases, e. g. for certificates derived from the "HARICA Client RSA Root
CA 2021" root certificate. This e. g. affects checks like

openssl smime -verify -in signedmail.eml > /dev/null

but also more common use cases like the signature verification in the
SOGo web mail client [0] are affected.

To avoid re-introducing the issue giving rise to #721976 I suggest to
introduce a new separate binary package for email certificates (maybe
something along the lines of [1]).

Best regards

Peter

[0] https://tracker.debian.org/pkg/sogo
[1] https://bugs.debian.org/721976#35
#1107629#10
Date:
2025-07-22 19:13:41 UTC
From:
To:
Julien and I met at DebConf25 to discuss how to proceed with this bug.
The following is a short summary of this meeting:

1. Creating a separate package containing email certificates (both
email-only and email+server CA certificates) seems suitable provided
they are stored in a separate trust store to avoid re-introducing #721976.

2. What needs to be clarified is how to make software using
ca-certificates (like e. g. openssl) aware of this. I. e. they have to
use the server CA trust store when validating server certificates and
the email CA trust store when dealing with mails.
#1107629#15
Date:
2025-07-23 09:52:01 UTC
From:
To:
Dear OpenSSL maintainers,

I would like to tap on your expertise trying to address #1107629, in
particular item 2 mentioned in [0]. Is there an easy way to make openssl
aware of two separate root CA trust stores and teach it to use the
suitable one for each use case?

Other suggestions to fix #1107629 are welcome, too - in particular if
they are more straightforward. :-)

Best regards

Peter

[0] https://bugs.debian.org/1107629#10
#1107629#20
Date:
2025-07-23 18:49:48 UTC
From:
To:
The other option is that we ship a trust store with trust settings. Someone is making it more useful upstream at https://github.com/openssl/openssl/pull/27965

That would be an OpenSSL only solution. We could ship them in a separate directory, and have OpenSSL default to that.

Shipping it in a separate directory per type would require that all software using smime sets the path correctly. Shipping the trust settings with the certificate requires the software to say for what purpose they are using it, which most probably don't.

Maybe we should try to do both.

Kurt