The template you've neglected to fill is there for a reason.

1. What exact command did you execute?
2. What wass the full output of it?
3. Perhaps most importantly, what did you expect to get on, I hypothesize, querying an expiration date of a hundred certificates at once?

1...

openssl x509 -dates -in /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt

2...

notBefore=Jul  1 11:23:33 2014 GMT
notAfter=Jul  1 09:23:33 2024 GMT
-----BEGIN CERTIFICATE-----
MIIDyzCCArOgAwIBAgIDFE3kMA0GCSqGSIb3DQEBBQUAMIGLMQswCQYDVQQGEwJB
VDFIMEYGA1UECgw/QS1UcnVzdCBHZXMuIGYuIFNpY2hlcmhlaXRzc3lzdGVtZSBp
bSBlbGVrdHIuIERhdGVudmVya2VociBHbWJIMRgwFgYDVQQLDA9BLVRydXN0LVF1
YWwtMDIxGDAWBgNVBAMMD0EtVHJ1c3QtUXVhbC0wMjAeFw0xNDA3MDExMTIzMzNa
Fw0yNDA3MDEwOTIzMzNaMIGLMQswCQYDVQQGEwJBVDFIMEYGA1UECgw/QS1UcnVz
dCBHZXMuIGYuIFNpY2hlcmhlaXRzc3lzdGVtZSBpbSBlbGVrdHIuIERhdGVudmVy
a2VociBHbWJIMRgwFgYDVQQLDA9BLVRydXN0LVF1YWwtMDIxGDAWBgNVBAMMD0Et
VHJ1c3QtUXVhbC0wMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJaR
q9eOsFm4Ab20Hq2Z/aH86gyWa48uSUjY6eQkguHYuszr3gdcSMYZggFHQgnhfLmf
ro/27l5rqKhWiDhWs+b+yZ1PNDhRPJy+86ycHMg9XJqErveULBSyZDdgjhSwOyrN
ibUir/fkf+4sKzP5jjytTKJXD/uCxY4fAd9TjMEVpN3umpIS0ijpYhclYDHvzzGU
833z5Dwhq5D8bc9jp8YSAHFJ1xzIoO1jmn3jjyjdYPnY5harJtHQL73nDQnfbtTs
5ThT9GQLulrMgLU4WeyAWWWEMWpfVZFMJOUkmoOEer6A8e5fIAeqdxdsC+JVqpZ4
CAKel/Arrlj1gFA//jsCAwEAAaM2MDQwDwYDVR0TAQH/BAUwAwEB/zARBgNVHQ4E
CgQIQj0rJKbBRc4wDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBh
MfOINQm4XpzF6DmkOmb/ArSXHf5LObqFmIMooNr2TkyzrUTK/NE+mdrm15Rfdts7
kZVq/ICfQSFeaPvWaAVq4plH/26OjvMTVv7DfgfPBUxDWqlCuDnDnPAVQ+yo/o5i
BA5uUlMbp5znbDtlxwF/5gWqcn/hKxSUCP1uiOPIlKfeVvsRmBcJAdoixTM/Ic10
pavJMGOI20onArvQZAUEbXQLA8cs8naxfF6Bo36U9nk6wn7q8VPXhViekByd17F6
9A+ah0Iqw4SPf9BqNRIe1YxxjDhCmjWt3aoyE3ZFBuGjW+r2ipb/vGU1+2oyy2Fd
2dMmiMQ7gGhWX9X6gWLd
-----END CERTIFICATE-----

3a...

A cert that is not expired (or as of the time I posted this originally - about to)

3b...

Sadly not 100, but you are 6% right...
In this case 6 that match "find /etc/pki -name *.crt"

Recently & in the past new certs cause problems that should not be as bad as they
seem to get, so coordination is desperately required...

See also https://bugzilla.redhat.com/show_bug.cgi?id=1850512

Regarding problems with Evolution when certs change.

I also now note that many certs (owned by some packages) have their file
date changed but the cert remains the same.

Why modify the file date?

This message is a reminder that Fedora Linux 40 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '40'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 40 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Am I likely to get answers to the above questions?

At FC42 the following applies in my case,

EXPIRED /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
Jul  1 09:23:33 2024 GMT

Certificate: /etc/pki/ca-trust/extracted/pem/directory-hash/Baltimore_CyberTrust_Root.pem Expires: May 12 23:59:00 2025 GMT 

EXPIRED /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem
Jul  1 09:23:33 2024 GMT

EXPIRED /etc/pki/tls/certs/ca-bundle.trust.crt
Jul  1 09:23:33 2024 GMT

I'd like to understand how these are maintained in Fedora...

Hey John,

In fedora as well as redhat we update the ca-certificates annually(June/July) unless, of course, there is immediate need to perform the update sooner(CVE, introduction of new CA).

We strictly follow what Mozilla does, so for instance with the Baltimore certificate, it hasn't been removed yet by mozilla[1] and even if it was we wouldn't be updating ca-certificates just for that, there is no need as the date blocks any usage of the certificate.

As for the code signing certificates such as the "A-Trust-Qual-02" you have provided, we once more follow what Microsoft does and I think they keep expired certificates for some reason on purpose there but not sure(I can check if you want).

Expired certificates don't pose any thread, and we always check if the expired certificates is "being replaced", fortunately most of the CAs do that way in advance, so a 1 year gap between the updates is not an issue as there is a replacement already for quiet some time(e.g. 5years).

> I also now note that many certs (owned by some packages) have their file date changed but the cert remains the same. Why modify the file date?
I don't follow here, what do you mean by owned by some packages like ca-certificates modify certificate files of other packages?

> Recently & in the past new certs cause problems that should not be as bad as they seem to get, so coordination is desperately required... See also https://bugzilla.redhat.com/show_bug.cgi?id=1850512
Thanks for pointing this out I wasn't aware of this since taking over ca-certificates.
Do you suspect the expired certificates playing any role in the aforementioned bug?


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1961848

OK, thanks for that...

Where I said,
        I also now note that many certs (owned by some packages) have their
        file date changed but the cert remains the same.
        Why modify the file date?

I now realise these are dated by their extraction from the rpm on individual
machines. ie. all certs are redistributed in the rpm when one changes.
Otherwise it seems that the dates on files in the pki tree change randomly
depending on the rpm builder.

Obviously (or perhaps not ;-) it would be useful to try to keep file dates consistent
with their original deployment, unless of course the file content really did change
in which case it should match that.
That would mean encouraging all/any cert rpm creators follow a "standard" that makes
that happen, don't know how hard that would be, herding cats perhaps? ;-)

Where you ask,
        Do you suspect the expired certificates playing any role in the aforementioned bug?

I think that what happens is that certain underlying certs change & packages like Evolution don't
necessarily reload the cert appropriately. In that case it's the cert used to communicate
with a mail server, but it obviously affects things like google drive etc., in Fedora/RedHat.

The question is who should make an effort to remedy that?
Certainly each package that uses any cert should check that it has not changed before using it
(because it will break!) which adds a bit of overhead & probably security & race conditions that
might be hard to mitigate.
Maybe a critical cert change should include a log entry (that will turn up in logwatch for
those who care) that suggests restarts for packages that depend on certain certs, at least as
a minimum.
Might be hard logic to create but might save some angst for those who get caught by these things
& who don't understand why it's happening.

I've now asked in

        https://bugzilla.redhat.com/show_bug.cgi?id=1850512

if my last comment made it into FC42 for Evolution. Sadly I can't up that bug to FC42 ;-)


Where I say package above I mean program like Evolution et.al..

Thanks for clearing that up.

> Obviously (or perhaps not ;-) it would be useful to try to keep file dates consistent with their original deployment, unless of course the file content really did change in which case it should match that.

Would be nice but unless this fixes something like https://bugzilla.redhat.com/show_bug.cgi?id=1850512 or there is a real impact, then I think it wouldn't be worth the effort.

> The question is who should make an effort to remedy that?

This has to be investigated further but I think this has to be fixed by the library or p11-kit(less likely). Ca-certificates could potentially accommodate but i don't think that it is possible to fix it entirely there.

Let me know if you have any further questions, otherwise I will close the bug.

Nothing else, unless you know how to increase my login timeout on this bugzilla system...

Thanks for your help

> Nothing else, unless you know how to increase my login timeout on this bugzilla system...

Wish I did..

Actually what commands are used to create the rpm(s) for the pki tree?

It should be a simple matter of making appropriate changes to those.

Could you please elaborate I am afraid I don't follow at all.

I understand the certs are distributed in an rpm (for fedora).

An rpm is created (it is actually a cpio archive with "rpm headers") with
certain characteristics ie. potentially preserved time/date on files etc.

If they are being created to have a time/date related to when they are extracted,
that means every machine is likely to have different dates/times on every cert file.
That seems not right to me especially for a cert file.

Many other RPMs preserve the dates/times on the files in the package, so it's often
possible to see which files have been changed in a package between versions if you
do a "stat".

This should be happening with the cert files surely, ie. mine has the same file date as yours.
Not the date/time they were installed on my machine & yours which will be different.

In cpio it's [--preserve-modification-time]

In tar it's "-p"

In rsync it's "--perms, -p"

What is it in creating an rpm? (& subsequently unpacking it?)
I don't know, specifically, but it seems to require a complex suite of build instructions &
there's a big manual (I don't intend reading - KISS) for it!

So can we please have consistent permission (it already is) & date/time specs in the rpm build
files for the certs package?

Thanks! for the clarification.

It is good to note that certificates are mostly distributed in bundles except for openssl directory hash format which is a cert per file. So if we implement this then, still, any custom modification to the root store e.g. adding a company root certificate will result in the date change. and there will be no way to tell what changed unless you diff the original bundle with the updated one.

The final certificates(files/bundles) are generated using update-ca-trust script which is part of ca-certificates, this is invoked during installation or called if you make modifications add/block a certificate.., this means that we would either need to modify p11-kit(the extraction tool in update-ca-trust) as that is the tool used to extract the actual certificates(which I doubt would be easy) or
in update-ca-trust, store all the dates for all the files, diff for changes and if the file wasn't affected revert the date using touch or something. maybe something else

I think the better alternative approach for checking changes is to look at the version of ca-certificate on the system and look at the change-log which contains all the changes made from the previous version.This way you also see the actual name of the certificate not a pem encoded one.

example of changelog:
- Update to CKBI 2.54 from NSS 3.79
-    Removing:
-     # Certificate "GlobalSign Root CA - R2"
-     # Certificate "DST Root CA X3"
-     # Certificate "Explicitly Distrusted DigiNotar PKIoverheid G2"
-    Adding:
-     # Certificate "Autoridad de Certificacion Firmaprofesional CIF A62634068"
-     # Certificate "vTrus ECC Root CA"
-     # Certificate "vTrus Root CA"
-     # Certificate "ISRG Root X2"
-     # Certificate "HiPKI Root CA - G1"
-     # Certificate "Telia Root CA v2"
-     # Certificate "D-TRUST BR Root CA 1 2020"
-     # Certificate "D-TRUST EV Root CA 1 2020"
-     # Certificate "CAEDICOM Root"
-     # Certificate "I.CA Root CA/RSA"
...

I am not at all against the change to keep the times consistent, unfortunately if this is just a good to have(my opinion, feel free to change my mind), then it might take some time for me to get to it.

OK, I guess there is no rush, I just thought it would be a simple change to a build flag when
packaging the certs for Fedora.