Ssl

Nss

Trust Flags

About trust flags of certificates in NSS database that can be modified by certutil

Managing Certificate Trust flags in NSS Database

We can modify certificate trust flags using certutil. But before we do so we must know more about these trust flags. Here are my notes about trust flags from Nelson Bolyard ‘s Brown bag:

There are three available trust categories for each certificate, expressed in this order: “SSL, email, object signing”. In each category position use zero or more of the following attribute codes c,C,p,PT,u,w. The attribute codes for the categories are separated by commas.

These trust flags are allow overrides, they tell NSS that it is ok touse certificates for this purpose even though they may not seem like it is. There are two categories : Validity override and trust overrides.

Flags that apply to CA Certificates

• c - its for validity override - It tells even though this certificate doesn't look like a CA certificate - In version 1 certificates like old root CA certificates (that predated X509 v3) its necessary to set this.
• C trusted CA flag implies c - This certificate should be treated like a CA certificate but also should be treated as root certificate we trust.By default roots are not trusted. We can take any certificate and mark it with a "C" so it will be treated as a root CA certificate. When NSS clients/server validates certificate chain we can stop right there. NSS will build chain to send out as far as it reaches a root CA i.e. when it sees “C” flag. So intermediate CA certificates should not have this trust
  flag “C”.

Flags that apply to end entity certificates like Server certificates or Client
certificates. certificates that are not CA certificates :

• p — valid peer flag — even though the certificate doesn’t look like apeer cert, treat it like a peer cert.
• P — Trusted Peer flag — implies p — This is a peer certificate & I want it take it at face value. I want u to trust this cert. Don’t even bother to look & see if is issued by the issuer that you know and we are going to trust this certificate just by itself and so in the world of self signed server certificates its sometimes necessary to set this trusted peer flag in the client so the client will trust the certificate when it comes from the server.
• T — special trust flag that is used in SSL Column only, it is used only on the server. It is not used on the client. It tells the server that this certificate is one whose name it should send out when it requests client authentication. When a server requests a client to authenticate itself with a cert, the server sends out a list of names of certificates that are issuers from whom it is willing to accept certificates. It figures out the names it should sent out because it looks for certificates with this “T” flag,those are the names it sends out to the remote client.

Flag that can not be set by certutil

• u — User flag — This is not a trust flag and this is not a flag that you can set with certutil, this is a dynamic flag it says that NSS has discovered that NSS has the private key associated with this cert. That’s essential for server certificate. If you are a server and you are trying to send out your server certificate and its chain you have to have the private key associated with this server cert. This is something to look for.

Originally published at blogs.oracle.com on July 8, 2009.