Bug 2395904 - Regression in certificate trust with the c flag
Summary: Regression in certificate trust with the c flag
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: nss
Version: 42
Hardware: Unspecified
OS: Linux
high
medium
Target Milestone: ---
Assignee: Frantisek Krenzelok
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-09-16 18:51 UTC by Rob Crittenden
Modified: 2025-10-07 15:29 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2025-10-07 15:29:24 UTC
Type: ---
Embargoed:
fedora-admin-xmlrpc: mirror+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker FC-2266 0 None None None 2025-09-16 18:51:46 UTC

Description Rob Crittenden 2025-09-16 18:51:08 UTC
Using nss-3.115.1-1.fc42.x86_64 trying to set the "c" trust flag on a certificate is not stored.

$ certutil -N -d /tmp/nssdb --empty-password
$ certutil -A -d /tmp/nssdb -n test -t C,c,p -a -i ~/ca.crt
$ certutil -L -d /tmp/nssdb/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

test                                                         C,,p 

Using the previous version, nss-3.109.0-1.fc42.x86_64, works as expected.

<same steps to create the db, import cert, etc>
$ certutil -L -d /tmp/nssdb

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

test                                                         C,c,p

This regression was discovered by the certmonger unit tests and is preventing updating the package because the unit tests are run in the %check step. So it is a blocker in that regard.


Reproducible: Always

Steps to Reproduce:
Put a valid CA certificate into ~/ca.crt

1. mkdir /tmp/nssdb
2. certutil -N -d /tmp/nssdb --empty-password
3. certutil -A -d /tmp/nssdb -n test -t C,c,p -a -i ~/ca.crt
4. certutil -L -d /tmp/nssdb
Actual Results:
Missing c (valid ca) flag

Expected Results:
The c flag set

Comment 1 Frantisek Krenzelok 2025-09-17 15:24:05 UTC
Thanks for the report, looking into this.

Comment 2 Frantisek Krenzelok 2025-09-24 11:42:53 UTC
Upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1990444

I am having hard time finding the issue...

Comment 3 Bob Relyea 2025-10-06 23:21:54 UTC
yes, the 'c' flag has not been processed by NSS for decades. The new PKCS #11 TRUST attributes does not define the attribute. Rob, did this actually cause something to break?

Comment 4 Bob Relyea 2025-10-06 23:26:23 UTC
In RHEL, I'll probably continue to use the old TRUST attributes for softoken, while being able to accept the new ones, but for Fedora, you should update your certmonger test to not expect the attribute to be stored.

Comment 5 Rob Crittenden 2025-10-07 01:44:40 UTC
(In reply to Bob Relyea from comment #3)
> yes, the 'c' flag has not been processed by NSS for decades. The new PKCS
> #11 TRUST attributes does not define the attribute. Rob, did this actually
> cause something to break?

So certmonger has a test where it writes a certificate + trust out, then reads it back and validates that the trust that was stored matches expectations. This test was added in 2013. Why the original author chose to include the 'c' flag I have no idea but I think he was trying to be thorough.

My concern wasn't so much that this particular flag was being missed, it was whether something more serious was going on and this was most visible. I'm fine if the 'c' flag is no longer supported.

I've been using NSS (and precursor) since 1999 and I can't recall a time I used the 'c' flag :-)

Comment 6 Bob Relyea 2025-10-07 15:29:24 UTC
Yeah, it's deprecates now.


Note You need to log in before you can comment on or make changes to this bug.