problem Importing certificates in NSS db using Cert_importcerts -

[PeachUser]

I am implementing functionality  which needs to take trusted root
certs from user and use it to do SSl handshake.
I use CERT_ImportCert
I read a DER file get the data and length  , create  SECItem  and then
pass it to the CERt_importCerts.
 I am keeping  both the keepcerts and isCA flags true.
and I am also passing a nickname .
 But in the CertArray (return value) the cert does not seem to get the
nick name .
If I do certutil  -L , I do not see this cert there.
what am I doing wrong ? Pl. let me know. I have spent lot of days
debugging this but cant get anywhere.
Thanks in advance ..
Here is my code ...
 SECItem ** rawArray;
  CERTCertificate ** certArray = NULL;
for(U32 i=0; im_certs.size(); i++){

  BYTE *buf = m_certs.get(i);
  U32 len = m_lenArr.get(i);

  SECItem  certItem ;

certItem.data = buf;
certItem.len = len;
certItem.type = siDERCertBuffer;
  trustedCerts[i] = certItem;


}


PLAYEROUTPUT(( in Add trusted certs after getting certs in
trusted certs  -setServerRootCertificate\n));

rawArray = (SECItem **) PORT_Alloc(sizeof(SECItem *) *
(m_certs.size()));
PLAYEROUTPUT(( in Add trusted certs -allocating memory -
setServerRootCertificate\n ));
if(! rawArray) {
 PLAYEROUTPUT(( NO Raw Array \n));
}
for(U32 i =0 ; i  m_certs.size() ; i++ ){
rawArray[i] = trustedCerts[i];
}
PLAYEROUTPUT(( in Add trusted certs - raw array populated -
setServerRootCertificate\n));
char  nickname [] = UserRootCert;
SECStatus rv =
CERT_ImportCerts(CERT_GetDefaultCertDB(),certUsageSSLServer,m_certs.size(),rawArray,certArray,
PR_TRUE,PR_TRUE,nickname);
if(rv != SECSuccess ){
PLAYEROUTPUT(( unable to insert certificate in DB -
setServerRootCertificate\n ));
}
else if(certArray == NULL ){
PLAYEROUTPUT(( unable to insert certificate in DB certArray
is null -setServerRootCertificate\n ));
}
else if( certArray[0] ==NULL){
PLAYEROUTPUT(( unable to insert certificate in DB
certArray[0] is null -setServerRootCertificate\n ));
}

CERTCertTrust *trust = NULL;
trust = (CERTCertTrust *)PORT_ZAlloc(sizeof(CERTCertTrust));
chartrustsetting []= c,c,c;
rv = CERT_DecodeTrustString(trust, trustsetting);
if (rv) {
PLAYEROUTPUT((unable to decode trust string));

}

CERTCertificate *cert1 = NULL;

 for(U32 i=0; i 1; i++){
cert1 = certArray[i];
rv = CERT_ChangeCertTrust(CERT_GetDefaultCertDB(), cert1,
trust);
if (rv != SECSuccess) {
PLAYEROUTPUT((could not change trust on certificate));

}
}



-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

NSS linkage and FIPS-140 compliance for Firefox

[Brian Smith]

 [I cannot participate in any legal discussions now. Please don't ask 
me questions about legal stuff.]


We (Mozilla) are are exploring some approaches to statically link NSS 
into Firefox to reduce dynamic linkage overhead caused by the NSS shared 
libraries and to allow for whole-program optimization (and dead code 
removal) for NSS based on Firefox performance profiles. I am interested 
in what others think of this approach and what approach other client 
software developers are planning to take. I am also interested in 
knowing how I can help get reviews of the necessary patches in a short 
time frame. I am not an NSS reviewer but I can at least pre-review 
patches to save other reviewers time (as I did for the TLS 1.1/1.2 
patches) and I could give such reviews much higher priority if others 
respond in kind.


Changing the way that NSS (Softoken and FreeBL, in particular) is linked 
into Firefox means changing the strategy for FIPS 140 compliance of the 
browser, and FIPS 140 compliance is an important concern. But, the vast 
majority of our users--and all of our mobile users--run in normal 
(non-FIPS) mode and we need to optimize for that case so that people pay 
(performance-wise) for FIPS mode only when they enable FIPS mode--even 
if that would mean that the FIPS mode would have more overhead than it 
has now. The approach outlined below is very similar in spirit to the 
bypass mode added to NSS to improve the performance of Sun's NSS-based 
products. Basically, we just want NSS to be optimized for clients like 
Firefox as much as it is optimized for the server products that use it, 
like Nelson mentioned during our lunch meeting. I think this approach 
will cause minimal disruption to other products using NSS while still 
allowing us to make necessary performance improvements and size 
reductions in Firefox.


1. Create a supported configuration of NSPR+NSS (in the NSS CVS trunk) 
that that supports static linking with profile-guided optimization (PGO) 
and whole-program optimization (WPO). Wan-Teh has already written 
patches to do this for Chrome and those patches have been tweaked by 
others at Mozilla. But, we need reviewers for the patches after they are 
cleaned up. See [1] and [2].


2. Update the NSS source code (primarily in libssl, Softoken, and 
FreeBL) to allow us to exclude dead code sections from the build when 
the the compiler's WPO cannot remove them automatically (e.g. libssl's 
server-side code code when linked into Firefox, the bypass mode code, 
and anything in FreeBL/Softoken that isn't actually used by Firefox).


3. Decouple the release of the FIPS-validated Softoken from the release 
of the browser. For example, if we need to ship a version of Firefox 
that needs some crypto bits that are in a version of Softoken/FreeBL 
that hasn't yet been validated, then we will ship the release with the 
newer NSS and provide the FIPS-validated version afterwards. Put another 
way, FIPS mode issues won't block Firefox. (Because of Firefox Sync, we 
are now always going to have crypto features that won't work in FIPS mode.)


4. Provide a FIPS mode option in Firefox wherein the statically-linked 
Softoken and FreeBL are disabled in favor of the use of a 
dynamically-loaded FIPS-validated PKCS#11 module. If Softoken is the 
FIPS-validated module, then NSPR and NSS must support being loaded 
multiple times into the same process (once statically linked, and at 
least once dynamically linked).


5. Add the few missing bits to FreeBL that would be needed to have a 
100% bypass mode (no PKCS#11 usage) in the client part of libssl, and 
then remove most/all of the statically-linked copy of Softoken from 
Firefox in favor of using the FreeBL interface directly. We would still 
support the non-bypass mode specifically for FIPS mode. I have done some 
experiments with this and it seems like it doesn't require much 
additional code added to FreeBL; I can probably eliminate as much code 
as I add.


6. Remove the FIPS-validated Softoken from the default Firefox 
distribution, and distribute it as part of an add-on.


7. Use operating-system APIs for client authentication, so that client 
certificates and smart cards are stored and managed by the operating 
system's APIs and tools. I know there is a PKCS#11 interface to native 
OS interfaces in NSS already, but I think we can provide a better 
experience for users by just using the native APIs--and probably do so 
with little maintenance cost (in NSS) and notably less overhead. Note 
that this means we will never support client authentication with static 
ECDH/DH encryption keys; we will only support key exchange mechanisms 
where the client has to provide a signature.


8. On platforms where we use the system NSS shared libraries, allow a 
configuration where the system NSS libraries are used for client 
cert/smartcard support while the built-in static NSS is used for 
everything else.


Cheers,
Brian

[1]