Per discussion with cfu, it's unclear the impact of removing the trust flags of the external CA certificate to PKI in general. It may work under certain scenarios for IPA, but it may break other things in PKI. This will have to be deferred pending full investigation and testing.

In any case, IPA may disable the self-tests to bypass the current requirement, but the PKI behavior cannot be guaranteed.

If there is an issue with verification here, its likely not in the PKI layer, but rather within NSS.

Specifically, when we perform the self test on the local subsystem certificates, we call the JSS function - 

CryptoManager cm;
cm.isCertValid(nickname, true, cu)

which basically calls the NSS function:

rv = verifyCertificateNow(env, self, nickString, checkSig, required_certificateUsage, &currUsage);

This function verifies the specified usage for the subsystem certificate as well as the trust relationship for the chain.  If there is a bug here, then the bug is in NSS, rather than in PKI.

The bug description indicates that ",," should be sufficient.  Just offhand, I would think that "c,," would be required, where "c" is "valid CA".  Did you try this?

I don't understand the bug report.

What is it that doesn't "start"?

Could you please provide more details, ideally with example certificates?

Ade, I assume you are veryfying the certificate for the "SSL CA" usage, right? NSS does (surprisingly to me) indeed require the "C,," flag on *any* of the certificates higher in the CA chain:

# certutil -d /var/lib/pki/pki-tomcat/alias -L

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

ocspSigningCert cert-pki-ca                                  u,u,u
subsystemCert cert-pki-ca                                    u,u,u
CA - Example Organization                                    ,,   
CA - Example Organization #2                                 ,,  
caSigningCert cert-pki-ca                                    CTu,Cu,Cu
Server-Cert cert-pki-ca                                      u,u,u
auditSigningCert cert-pki-ca                                 u,u,Pu
# certutil -d /var/lib/pki/pki-tomcat/alias -O -n 'caSigningCert cert-pki-ca'
"CA - Example Organization #2" [CN=CA,O=Example Organization]

  "CA - Example Organization" [CN=CA,O=Subsidiary Example Organization]

    "caSigningCert cert-pki-ca" [CN=Certificate Authority,O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM]

# certutil -d /var/lib/pki/pki-tomcat/alias -V -n 'caSigningCert cert-pki-ca' -u L
certutil: certificate is invalid: Peer's certificate issuer has been marked as not trusted by the user.
# certutil -d /var/lib/pki/pki-tomcat/alias -M -n 'CA - Example Organization' -t C,,
# certutil -d /var/lib/pki/pki-tomcat/alias -V -n 'caSigningCert cert-pki-ca' -u L
certutil: certificate is valid
# certutil -d /var/lib/pki/pki-tomcat/alias -M -n 'CA - Example Organization' -t ,,
# certutil -d /var/lib/pki/pki-tomcat/alias -M -n 'CA - Example Organization #2' -t C,,
# certutil -d /var/lib/pki/pki-tomcat/alias -V -n 'caSigningCert cert-pki-ca' -u L
certutil: certificate is valid


Further observations:
* no extra flags are needed for "Any CA" and "Verify CA" usages,
* there is no visible difference between ",," and "c,,",
* unsetting the flag does not have any effect on validity of the server certificate.


Kai, the pki-tomcatd service does not start because of a self-test done on its CA signing certificate, see above.

Why is the extra flag necessary?

Yes we are verifying for "SSL CA" of the signing cert.

You can see which parameters we are checking for in CS.cfg.  For example,

ca.cert.signing.certusage=SSLCA

I cannot help you without the certificates.

Please provide the full set of certificates for me to look at.

You may extract the public part of certificates using commands like:
  certutil -d /var/lib/pki/pki-tomcat/alias -L -n 'NICKNAME' -a > output-file

Repeat the above command multiple times, by replacing NICKNAME with the respective names, and using a different output-file each time.

Attach all files to this bug.
Thanks

In addition, please provide the package versions of installed nspr and nss packages, which you can obtain by executing the following command:
  rpm -q nspr nss nss-softokn nss-util

Per Bug Triage of 05/03/2016: RHEL 7.4

NOTE: This bug may need to be moved to the NSS component, time will tell.

Closing with insufficient_data.

If it is desired to re-open this bug, please provide a reproducer without pki (i.e. nss commands only).

We have the following situation. An external CA signes our subsidiary CA
certificate. We use this subCA to issue a server certificate. If we mark the
subCA as a trusted CA (CT,,), then the server certificate is valid. This is the
expected behaviour.

The problem is when we test whether the subCA certificate itself is a valid
certificate to use as a CA. This check produces the following error:

certificate is invalid: Peer's certificate issuer has been marked as not
trusted by the user.

This happens because the external CA has no trust flags set. However, since the
subCA has been marked as a trusted CA, it should be irrelevant whether the
external CA is marked as trusted.

I'm attaching the certificates (no password) to reproduce this issue.

# mkdir nssdb
# certutil -d nssdb -N
# pk12util -d nssdb -i subca.p12
# pk12util -d nssdb -i server.p12
# certutil -d nssdb -M -n ca1/subca -t CT,,
# certutil -d nssdb -L
Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

ca1                                                          ,,   
ca1/subca                                                    CTu,u,u
ca1/subca/server                                             u,u,u

# certutil -d nssdb -V -n ca1/subca/server -u V                       
certutil: certificate is valid
# certutil -d nssdb -V -n ca1/subca -u L
certutil: certificate is invalid: Peer's certificate issuer has been marked as
not trusted by the user.
# certutil -d nssdb -M -n ca1 -t C,,
# certutil -d nssdb -V -n ca1/subca -u L
certutil: certificate is valid

As examples were provided, moving this bug to NSS.

So, why don't you simply mark ca1 as trusted?

You're saying, if you do, everything works.

Why do you report it as a problem, that you have to do that?

If your process operates with an intermediate CA issued by ca1, you're obviously  trusting ca1.

The suggested fix is to mark the external CA, that you're obviously trusting, as trusted.

(In reply to Jan Cholasta from comment #0)
> 
> When the CA is signed by an external CA, the external CA certificate is
> required to have at least "C,," (SSL server CA) trust flags for the CA
> certificate self-test to pass. However, this is not necessary, as the
> external CA certificate needs to be trusted only to issue CA certificates,
> i.e. ",," trust flags are sufficient.

So you're saying:

- you have your own software
- your software performs a test
- the result of the test is irrelevant for the operation of your software

If true, then why don't you remove the unnecessary selftest?

I wonder if there's a misunderstanding.

Why do you believe that ",," is sufficient to issue a certificate?

Of course, for the action of signing a certificate, nobody cares about trust flags. The key is used for signing, and you're done.

The point of trust flags is, whether certificates can be accepted as trusted or not.

If your software wants to check, if your own (intermediate) CA certificate is valid, then no, it isn't sufficient for the external issueing CA to have trust flags ",,".

Because ",," means "we don't trust it".

If you want your software to be able to verify, that the intermediate CA certificate you've been by external ca1 is valid for issueing SSL CA certs, then you must declare that external ca1 as trusted for that, which is, mark it as C,,

No activity in 4 months, closing as NOTABUG as I had suggested.