X

Blogs about Deep Learning, Machine Learning, AI, NLP, Security, Oracle Traffic Director,Oracle iPlanet WebServer

  • July 8, 2009

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 to
use 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 a
peer 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.

Join the discussion

Comments ( 4 )
  • guest Tuesday, August 18, 2009

    Your blog is referenced by Chromium folks at http://code.google.com/p/chromium/wiki/LinuxCertManagement

    Thats great!


  • Meena Tuesday, October 12, 2010

    I tested with NSS 3.12.8. 'C' flag has no effect on intermediate CA cert. The whole cert chain was sent out instead of the expected behavior stopping at the intermediate CA cert (when 'C' flag is set).

    Filed a bug in NSS for this https://bugzilla.mozilla.org/show_bug.cgi?id=603615


  • guest Wednesday, February 6, 2013

    Thanks for the blog,

    I am still not sure whats the minimum we need in the database? Any suggestions? Just issuers with "T,," enough or just the roots with "CT,," are enough or do we need both?

    Also if we add roots with CT, will it not open too open?

    Thanks

    M


  • guest Tuesday, July 30, 2013

    There are a number of links to this content at its old address - http://blogs.sun.com/meena/entry/notes_about_trust_flags, including the link from Chromium. It is hard to find this new entry, by searching "meena trust flags", for example. Maybe this comment will help the indexing. The documentation for certutil doesn't explain as much as this does - thanks for posting this.


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha