Thursday Nov 11, 2010

What's new in NSS 3.12.\*- PKIX - Bridged CA, revocation flags and Policies

What's new in NSS 3.12.\* - PKIX - Bridge CA, revocation flags and Policies

Network Security Services (NSS) 3.12 has a new feature:

  • libpkix: an RFC 3280 Compliant Certificate Path Validation Library

Some terms

PKIX

"PKIX" refers to all these extensions and enhancements documented in RFC 5280. These may be grouped into three major categories:

  • Bridge CA
  • revocation flags
  • policies

CRL Distribution Points

Refer RRFC section 4.2.1.13. The CRL distribution points extension identifies how CRL information is obtained.

PKI

As per RFC 4158 Public Key Infrastructure (PKI) is the set of hardware, software, personnel, policy, and procedures used by a CA to issue and manage certificates.

cross-certificate

As per RFC 4158, cross-certificate is a certificate issued by one CA to another CA for the purpose of establishing a trust relationship between the two CAs.

As per RFC 5280, A cross-certificate is a certificate issued by one CA to another CA that contains a CA signature key used for issuing certificates.



PKI structures

Lets discuss the three PKI structures : Hierarchical, Mesh style structure, Bridge structure

Hierarchical PKI structure

In hierarchical PKI structure, a certificate chain starting with a Web Server "Server" certificate would lead to an "intermediate CA", then to a "root" CA whose certificate is present in the web browser.

It looks something like

     Root CA1

        |      

    Intermediate CA1

        |            

       EE1

So we can have only one possible certificate chain for any leaf certificate : EE1 -> Intermediate CA1 -> Root CA1.

Mesh style PKI structure

In a mesh style PKI, CA's authenticate each other and creates certificates for one other. CA1 certificate for CA2 and CA2 creates certificate for CA1. In case there are 'n' CAs the number of certificates will be n2

Example of Mesh style PKI

   CA1 ------ CA2

      \\            /

        CA3

As per RFC 4158, the CAs in this environment have peer relationships; they are neither superior nor subordinate to one another.

In a mesh, CAs in the PKI cross-certify. That is, each CA issues a certificate to, and is issued a certificate by, peer CAs in the PKI.  A mesh PKI that is fully cross-certified is called a full mesh. However, it is possible to architect and deploy a mesh PKI with a mixture of uni-directional and bi- directional cross-certifications (called a partial mesh).  Partial meshes may also include CAs that are not cross-certified with other CAs in the mesh.

Bridge PKI structure

In a bridged PKI, a certificate chain starting with a Web Server "Server" Certificate might lead to Intermediary Bridge CA certificate, then to possible two different trusted Anchors.

Example of Bridge PKI

         CA1                               CA2 

       |             \\                        /

       |                  \\                /

  ICA(keypair1)   Bridge CA  (keypair2- cert1 from CA1 and cert2 from CA2)
                                  |               

                                EE

As you can see "Bridge CA" has been issued certificate both by trust anchor "CA1" and trust anchor "CA2". Both these certificates have the same DN. So we can get two certificate chains for a single certificate: EE -> Bridge CA -> CA1 and EE -> Bridge CA -> CA2.

As per RFC 4158, each PKI only cross-certifies with one other CA (i.e., the Bridge CA), and the Bridge CA cross-certifies only once with each participating PKI.  As a result, the number of cross certified relationships in the bridged environment grows linearly with the number of PKIs whereas the number of cross-certified relationships in mesh architectures grows exponentially.


Bridge CA

Brige CA is a CA which has more than one certificates from different issuers. A single intermediate CA entity can have any number of certificates from different CAs. Each of these identities  all share the same DN.

As per RFC4158, A BrideCA is a nexus to establish trust paths among multiple PKIs. The Bridge CA cross-certifies with one CA in each participating PKI.

In NSS 3.11.\* certificate verification function were

  • CERT_VerifyCertNow
  • CERT_VerifyCert
  • CERT_VerifyCertificate
  • CERT_VerifyCertificateNow
  • CERT_VerifyCACertForUsage
In NSS 3.12.\* a new certificate verification function CERT_PKIXVerifyCert as added which should be used to replace above mentioned calls.

Scenario show casing the difference between old NSS call CERT_VerifyCertNow and the new PKIX call CERT_PKIXVerifyCert

I wrote a sample program(server.cpp) . It runs on a certificate nicknamed "EE" (generated by Bridge CA),  both the old NSS call CERT_VerifyCertNow and the corresponding new PKIX call CERT_PKIXVerifyCert.

I wrote a script run-tests.sh which creates CA1, CA2 and 2 certificates for Bridge CA and EE cert. Then it modifies trust flags of CA1 and CA2 and runs server program on it. 

When we set a C trust flag on a certificate - It means that this certificate should be treated like a CA certificate but also should be treated as root certificate we trust. When NSS clients/server validates certificate chain we can stop right there.

Because CA1 and CA2 root CA certificates are self-signed certificates, if we do not add "C" trust flags in them, we get SEC_ERROR_UNTRUSTED_ISSUER error.

When we remove "C" the trust flag of either of the CA certificates CA1 or CA2 and the test case starts failing, we know that the server program uses that chain. When we mark the trust flags of either of the CA certificates CA1 or CA2 as "C" and the test starts to pass so we know that the server program uses that chain.

You can see only ONE of CA1 or CA2 chain works in old CERT_VerifyCertNow() but in the new call CERT_PKIXVerifyCert() both the CA1 and CA2 chains work.

Look at the last few lines of output of the script run-tests.sh to confirm that.

$sh run-tests.sh
...
=====================================
Running tests with trust flags - CA2-trusted CA1-trusted
certutil ouput is
Certificate Nickname              Trust Attributes
CA1                               CTu,Cu,Cu
CA2                               CTu,Cu,Cu
Bridge                              u,u,u
Bridge                              u,u,u
EE                                  u,u,u
CERT_PKIXVerifyCert(EE) - PASSED.
CERT_VerifyCertNow(EE) - PASSED.
=====================================
Running tests with trust flags - CA2-not trusted CA1-trusted
certutil ouput is
Certificate Nickname              Trust Attributes
Bridge                                u,u,u
Bridge                                u,u,u
EE                                    u,u,u
CA1                                  Cu,u,u
CA2                                   u,u,u
CERT_PKIXVerifyCert(EE) - PASSED.
ERROR: CERT_VerifyCertNow(EE) - FAILED !! 
( as it uses chain EE-> Bridge ->CA2, CA2 is not trusted due to absence of flag "C")
      Error = -8172   SEC_ERROR_UNTRUSTED_ISSUER 
      Peer's certificate issuer has been marked as not trusted by the user.
=====================================
Running tests with trust flags - CA2-trusted CA1-not trusted
certutil ouput is
Certificate Nickname                Trust Attributes
Bridge                                  u,u,u
Bridge                                  u,u,u
EE                                      u,u,u
CA2                                    Cu,u,u
CA1                                     u,u,u
CERT_PKIXVerifyCert(EE) - PASSED.
CERT_VerifyCertNow(EE) - PASSED.
 (as it uses chain EE->Bridge -> CA2 and CA2 is trusted due to flag "C")
=====================================

 
  


PKIX and revocation flags

The function CERT_PKIXVerifyCert gives the server much greater control over how the certificate validation is done. For example, it allows the server to decide

  • what to do about revocation checking for leaf certificates or intermediate CA certs in a certificate chain.
  • whether to use CRLs or OCSP or both, and in which order of preference.
  • whether to use local CRLs or OCSP or fetch it from network or both.
  • whether to skip it, or attempt it but not require it, or to absolutely require it.
  • whether to ask it to attempt to fetch missing certificates from certificate chains, and/or to fetch CRLs, and/or to fetch OCSP responses.
  • whether to impose any certificate policy requirements on certificates.

CERT_PKIxVerifyCert takes an array of input parameters for tuning these. For details refer

http://mxr.mozilla.org/security/source/security/nss/lib/certdb/certt.h#887

http://mxr.mozilla.org/security/source/security/nss/lib/certdb/certt.h#1010


PKIX and Policies

Refer RFC520 section 4.2.1.4 for information about policies.

When verifying a certificate chain (using CERT_PKIXVerifyCert()) it is possible to pass as input, a given policy oid that must be met. The certification validation will fail if the requested policy is not in place.

It is also possible to request a list of all policies(OIDs) which were found to be valid.(a list of OIDs).

 
  


Thanx to Jyri and Nelson for helping me understand these concepts. 

References



Makefile to compile http://blogs.sun.com/meena/resource/server.cpp

SECURITY_DIR=/export2/NSS_3.12.8/
all:
    CC -g  -I$(SECURITY_DIR)/include -L$(SECURITY_DIR)/lib -lnspr4 -lnss3 server.cpp -o server

And then run http://blogs.sun.com/meena/resource/run-tests.sh.txt

Tuesday Nov 02, 2010

What's new in NSS 3.12.\* - Transport Layer Security (TLS) Session Resumption without Server-Side State

What's new in NSS 3.12.\* - Transport Layer Security (TLS) Session Resumption without Server-Side State

NSS 3.12.\* has this new feature "Transport Layer Security (TLS) Session Resumption without Server-Side State". It is not enabled by default.

It is defined in RFC5077 . This RFC defines mechanisms to resume a Transport Layer Security (TLS) session without requiring session-specific state at the TLS server. This mechanism is useful in the following situations:

  • servers that handle a large number of transactions from different users
  • servers that desire to cache sessions for a long time
  • ability to load balance requests across servers
  • embedded servers with little memory

Lets look at these two cases described in RFC

1. Full Handshake Issuing New Session Ticket

Client
Server
ClientHello
(empty SessionTicket extension)
---->






<----
ServerHello
(empty SessionTicket extension)
Certificate\*
ServerKeyExchange\*
CertificateRequest\*
ServerHelloDone
Certificate\*
ClientKeyExchange
CertificateVerify\*
[ChangeCipherSpec]
Finished



---->




<----
NewSessionTicket
[ChangeCipherSpec]
Finished
Application Data
<---> Application Data

2. Abbreviated Handshake Using New Session Ticket

Client
Server
ClientHello
(SessionTicket extension)

---->





<----
ServerHello
(empty SessionTicket extension)
NewSessionTicket
[ChangeCipherSpec]
 Finished
[ChangeCipherSpec]
Finished
---->
Application Data
<---> ApplicationData


I have used NSS 3.12.7 in this blog.

Observing Two Connections

Create a certificate

    $NSS_DIR/bin/certutil -N -d .
    $NSS_DIR/bin/certutil -S -n test -s "CN=test" -x -t "CT,CT,CT" -d .

For ease of use I will use the same certificate for selfserv and strsclnt. I have used -c z (SSL_RSA_WITH_NULL_SHA) NULL cipher to see what's happening as Jyri had used in one of his blogs. For client we use a tool in NSS "strsclnt" with options "-c 2" (2 connections or more) and "-u. Note that "-u" option means enable the session ticket extension.

In one window we run server

$NSS_DIR/bin/selfserv -p 8444 -d . -D -B -s -n test -u -c z

In another window we run the client strsclnt :

$NSS_DIR/bin/strsclnt -p 1924 -c 2 -o -d . -n test -u -2 test -C z
      strsclnt: -- SSL: Server Certificate Validated.
      strsclnt: 0 cache hits; 1 cache misses, 0 cache not reusable
                0 stateless resumes
      strsclnt: 1 cache hits; 1 cache misses, 0 cache not reusable
                1 stateless resumes
    

Here is the ssltap output for this :


$ssltap -l -p 1924 -s test:8444
Connection #1 [Tue Nov  2 20:03:16 2010]
Connected to test:8444
--> [
(75 bytes of 70)
SSLRecord { [Tue Nov  2 20:03:16 2010]
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 70 (0x46)
   handshake {
      type = 1 (client_hello)
      length = 66 (0x000042)
         ClientHelloV3 {
            client_version = {3, 1}
            random = {...}
            session ID = {
                length = 0
                contents = {...}
            }
            cipher_suites[2] = {
                (0x00ff) ????/????????/?????????/???
                (0x0002) SSL3/RSA/NULL/SHA
            }
            compression[1] = {
                (00) NULL
            }
            extensions[21] = {
              extension type server_name, length [13] = {
                   0: 00 0b 00 00  08 ...           | .....test
              }
              extension type session_ticket, length [0]
            }
         }
   }
}
]
<-- [
(526 bytes of 521)
SSLRecord { [Tue Nov  2 20:03:16 2010]
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 521 (0x209)
   handshake {
      type = 2 (server_hello)
      length = 85 (0x000055)
         ServerHello {
            server_version = {3, 1}
            random = {...}
            session ID = {
                length = 32
                contents = {...}
            }
            cipher_suite = (0x0002) SSL3/RSA/NULL/SHA
            compression method = (00) NULL
            extensions[13] = {
              extension type 65281, length [1] = {
                      0: 00     | .
              }
              extension type session_ticket, length [0]
              extension type server_name, length [0]
            }
         }
      type = 11 (certificate)
      length = 424 (0x0001a8)
         CertificateChain {
            chainlength = 421 (0x01a5)
            Certificate {
               size = 418 (0x01a2)
               data = { saved in file 'cert.001' }
            }
         }
      type = 14 (server_hello_done)
      length = 0 (0x000000)
   }
}
]
--> [
(186 bytes of 134, with 47 left over)
SSLRecord { [Tue Nov  2 20:03:16 2010]
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 134 (0x86)
   handshake {
      type = 16 (client_key_exchange)
      length = 130 (0x000082)
         ClientKeyExchange {
            message = {...}
         }
   }
}
(186 bytes of 1, with 41 left over)
SSLRecord { [Tue Nov  2 20:03:16 2010]
   type    = 20 (change_cipher_spec)
   version = { 3,1 }
   length  = 1 (0x1)
}
(186 bytes of 36)
SSLRecord { [Tue Nov  2 20:03:16 2010]
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 36 (0x24)
   handshake {
      type = 20 (finished)
      length = 12 (0x00000c)
         Finished {
            verify_data = {...}
         }
   }
      MAC = {...}
}
]
<-- [
(224 bytes of 172, with 47 left over)
SSLRecord { [Tue Nov  2 20:03:16 2010]
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 172 (0xac)
   handshake {
      type = 4 (new_session_ticket)
      length = 168 (0x0000a8)
         NewSessionTicket {
            ticket_lifetime_hint = Sat, 03-Jan-1970 00:00:00 GMT
            ticket = {
                length = 162
                contents = {...}
            }
         }
   }
}
(224 bytes of 1, with 41 left over)
SSLRecord { [Tue Nov  2 20:03:16 2010]
   type    = 20 (change_cipher_spec)
   version = { 3,1 }
   length  = 1 (0x1)
}
(224 bytes of 36)
SSLRecord { [Tue Nov  2 20:03:16 2010]
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 36 (0x24)
   handshake {
      type = 20 (finished)
      length = 12 (0x00000c)
         Finished {
            verify_data = {...}
         }
   }
      MAC = {...}
}
]
--> [
(46 bytes of 41)
SSLRecord { [Tue Nov  2 20:03:16 2010]
   type    = 23 (application_data)
   version = { 3,1 }
   length  = 41 (0x29)
   0: 47 45 54 20  2f 61 62 63  20 48 54 54  50 2f 31 2e  | GET /abc HTTP/1.
  10: 30 0d 0a 0d  0a                                     | 0....
      MAC = {...}
}
]
<-- [
(192 bytes of 160, with 27 left over)
SSLRecord { [Tue Nov  2 20:03:16 2010]
   type    = 23 (application_data)
   version = { 3,1 }
   length  = 160 (0xa0)
   0: 48 54 54 50  2f 31 2e 30  20 32 30 30  20 4f 4b 0d  | HTTP/1.0 200 OK.
  10: 0a 53 65 72  76 65 72 3a  20 47 65 6e  65 72 69 63  | .Server: Generic
  20: 20 57 65 62  20 53 65 72  76 65 72 0d  0a 44 61 74  |  Web Server..Dat
  30: 65 3a 20 54  75 65 2c 20  32 36 20 41  75 67 20 31  | e: Tue, 26 Aug 1
  40: 39 39 37 20  32 32 3a 31  30 3a 30 35  20 47 4d 54  | 997 22:10:05 GMT
  50: 0d 0a 43 6f  6e 74 65 6e  74 2d 74 79  70 65 3a 20  | ..Content-type: 
  60: 74 65 78 74  2f 70 6c 61  69 6e 0d 0a  0d 0a 47 45  | text/plain....GE
  70: 54 20 2f 61  62 63 20 48  54 54 50 2f  31 2e 30 0d  | T /abc HTTP/1.0.
  80: 0a 0d 0a 45  4f 46 0d 0a  0d 0a 0d 0a               | ...EOF......
      MAC = {...}
}
(192 bytes of 22)
SSLRecord { [Tue Nov  2 20:03:16 2010]
   type    = 21 (alert)
   version = { 3,1 }
   length  = 22 (0x16)
   warning: close_notify
      MAC = {...}
}
]
Read EOF on Server socket. [Tue Nov  2 20:03:16 2010]
Read EOF on Client socket. [Tue Nov  2 20:03:16 2010]
Connection 1 Complete [Tue Nov  2 20:03:16 2010]

You can see that the server sends the session ticket in the first connection. Hence connection 1 is same as "Full Handshake Issuing New Session Ticket" in the table above.

Connection #2 [Tue Nov  2 20:03:16 2010] 
Connected to test:8444
--> [
(269 bytes of 264)
SSLRecord { [Tue Nov  2 20:03:16 2010]
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 264 (0x108)
   handshake {
      type = 1 (client_hello)
      length = 260 (0x000104)
         ClientHelloV3 {
            client_version = {3, 1}
            random = {...}
            session ID = {
                length = 32
                contents = {...}
            }
            cipher_suites[2] = {
                (0x00ff) ????/????????/?????????/???
                (0x0002) SSL3/RSA/NULL/SHA
            }
            compression[1] = {
                (00) NULL
            }
            extensions[183] = {
              extension type server_name, length [13] = {
                 0: 00 0b 00 00  08 ...          | .....test
              }
              extension type session_ticket, length [162] = {
   0: 4e 53 53 21  27 9b e0 2e  14 46 9c 67  e0 31 b6 b9  | NSS!'....F.g.1..
  10: fd 97 31 0a  73 25 0f 70  de 84 89 ac  2b d9 d0 af  | ..1.s%.p....+...
  20: 00 60 4d 99  7c dd fc 0b  67 10 dd 61  66 55 55 88  | .`M.|...g..afUU.
  30: db 59 ce f8  46 95 6b b9  09 ad 7b 95  7c cb 6a dd  | .Y..F.k...{.|.j.
  40: 17 b6 31 43  df 26 13 6a  15 69 4a 3a  f2 9e 6c 43  | ..1C.&.j.iJ:..lC
  50: b3 5f 60 4e  fc e7 d1 dd  0d 97 d6 a6  cc c7 89 f7  | ._`N............
  60: a4 e4 17 54  23 0f 14 fc  e7 c7 5e 7f  5d 00 56 c4  | ...T#.....\^].V.
  70: e0 c3 3c cb  d1 48 3c 29  b1 26 89 d2  ac d4 2f 14  | ..<..H<).&..../.
  80: 99 f5 49 a5  87 2a a5 5b  ac c8 a4 df  d4 c4 f9 b8  | ..I..\*.[........
  90: 93 55 bf 2f  ff 9e 7d e3  0d e2 51 56  c2 30 66 92  | .U./..}...QV.0f.
  a0: d5 17                                               | ..  }
            }
         }
   }
}
]
<-- [
(133 bytes of 81, with 47 left over)
SSLRecord { [Tue Nov  2 20:03:16 2010]
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 81 (0x51)
   handshake {
      type = 2 (server_hello)
      length = 77 (0x00004d)
         ServerHello {
            server_version = {3, 1}
            random = {...}
            session ID = {
                length = 32
                contents = {...}
            }
            cipher_suite = (0x0002) SSL3/RSA/NULL/SHA
            compression method = (00) NULL
            extensions[5] = {
              extension type 65281, length [1] = {
                 0: 00          | .
              }
            }
         }
   }
}
(133 bytes of 1, with 41 left over)
SSLRecord { [Tue Nov  2 20:03:16 2010]
   type    = 20 (change_cipher_spec)
   version = { 3,1 }
   length  = 1 (0x1)
}
(133 bytes of 36)
SSLRecord { [Tue Nov  2 20:03:16 2010]
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 36 (0x24)
   handshake {
      type = 20 (finished)
      length = 12 (0x00000c)
         Finished {
            verify_data = {...}
         }
   }
      MAC = {...}
}
]
--> [
(93 bytes of 1, with 87 left over)
SSLRecord { [Tue Nov  2 20:03:16 2010]
   type    = 20 (change_cipher_spec)
   version = { 3,1 }
   length  = 1 (0x1)
}
(93 bytes of 36, with 46 left over)
SSLRecord { [Tue Nov  2 20:03:16 2010]
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 36 (0x24)
   handshake {
      type = 20 (finished)
      length = 12 (0x00000c)
         Finished {
            verify_data = {...}
         }
   }
      MAC = {...}
}
(93 bytes of 41)
SSLRecord { [Tue Nov  2 20:03:16 2010]
   type    = 23 (application_data)
   version = { 3,1 }
   length  = 41 (0x29)
   0: 47 45 54 20  2f 61 62 63  20 48 54 54  50 2f 31 2e  | GET /abc HTTP/1.
  10: 30 0d 0a 0d  0a                                     | 0....
      MAC = {...}
}
]
<-- [
(192 bytes of 160, with 27 left over)
SSLRecord { [Tue Nov  2 20:03:16 2010]
   type    = 23 (application_data)
   version = { 3,1 }
   length  = 160 (0xa0)
   0: 48 54 54 50  2f 31 2e 30  20 32 30 30  20 4f 4b 0d  | HTTP/1.0 200 OK.
  10: 0a 53 65 72  76 65 72 3a  20 47 65 6e  65 72 69 63  | .Server: Generic
  20: 20 57 65 62  20 53 65 72  76 65 72 0d  0a 44 61 74  |  Web Server..Dat
  30: 65 3a 20 54  75 65 2c 20  32 36 20 41  75 67 20 31  | e: Tue, 26 Aug 1
  40: 39 39 37 20  32 32 3a 31  30 3a 30 35  20 47 4d 54  | 997 22:10:05 GMT
  50: 0d 0a 43 6f  6e 74 65 6e  74 2d 74 79  70 65 3a 20  | ..Content-type: 
  60: 74 65 78 74  2f 70 6c 61  69 6e 0d 0a  0d 0a 47 45  | text/plain....GE
  70: 54 20 2f 61  62 63 20 48  54 54 50 2f  31 2e 30 0d  | T /abc HTTP/1.0.
  80: 0a 0d 0a 45  4f 46 0d 0a  0d 0a 0d 0a               | ...EOF......
      MAC = {...}
}
(192 bytes of 22)
SSLRecord { [Tue Nov  2 20:03:16 2010]
   type    = 21 (alert)
   version = { 3,1 }
   length  = 22 (0x16)
   warning: close_notify
      MAC = {...}
}
]
Read EOF on Server socket. [Tue Nov  2 20:03:16 2010]
Read EOF on Client socket. [Tue Nov  2 20:03:16 2010]
Connection 2 Complete [Tue Nov  2 20:03:16 2010]

In the second connection, the client has used the same ticket and that's why it doesn't have to go through the full handshake and is not resending its certificate chain etc. Connection 2 is same as "Abbreviated Handshake Using New Session Ticket" in the table above but only with one difference that the server doesn't send a new ticket.


When session ticket extension is enabled, session information is taken from the extension data. However, if the extension is not used, SSL layer obtains session info from the internal session cache. If the client comes with a valid session id, session is restarted with out key exchange.

NSS Code

If you look at selfserv.c http://mxr.mozilla.org/security/source/security/nss/cmd/selfserv/selfserv.c#1695,

it uses the call SSL_OptionSet(model_sock, SSL_ENABLE_SESSION_TICKETS, PR_TRUE);

Same is true for strsclnt http://mxr.mozilla.org/security/source/security/nss/cmd/strsclnt/strsclnt.c#1237

Reference

  • RFC5077 Transport Layer Security (TLS) Session Resumption without Server-Side State

Wednesday Jul 08, 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.

About

Meena Vyas

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today