Jeffrey Stedfast wrote:
> How can I add a certificate into the permanant cert db assuming it's in > the CERT_Certificate data type? > > Trying to do something similar to what is done in certutil.c, I get the > following: > > undefined reference to `CERT_MakeCANickname' > undefined reference to `CERT_AddTempCertToPerm' > undefined reference to `CERT_NewTempCertificate' These functions are internal functions, and are disappearing in 3.4. > > Since I have come accross a similar problem previously (when implementing > an S/MIME plug-in) and was told that the functions had been deprecated, I > assume this is the case again? Try the function > > Trying to help myself before bothering you all, I looked through headers > and found functions that might do what I want (or at least the function > names suggest the action I want) although I forget the function names > now, but that's irrelavent I suppose. The problem that I had with these > functions is that they required DER encoded SECItems (iirc). So I guess > my ultimate question here (assming that the above symbols are indeed no > longer supported interfaces) is: "how do I convert a single > CERT_Certificate into a DER encoded SECItem?" CERT_Certificate *cert; &cert->derCert is a DER encoded SECItem. If you have a raw cert, read from a file or off the network, you can turn it into a SECItem by: SECItem item; item.data = derCertBuffer; item.len = derCertLen; > > Also, if there is some verbose documentation on this, where can I find > it? I suspect I will have further questions sometime down the line... Sigh, unfortunately many of our NSS API's were ad-hoc API's built to make Communicator or Netscape servers happy. We've really only stablized the SSL API's. We've spent some time defining the new API's we want to go to, but it's going to take a multi-step process to get there. What we are trying to do right now is elliminate those API's that will not be easy to emulate in our new world. We really wanted to have these new API's up and running before we went to Shared Library based versions of NSS, but the need to go to Shared Libraries outstripped out time to finish the new API's. Anyway the reason we haven't spent time documenting the old stuff is we are hoping to be ready with the new stuff soon. bob > > Thanks, > > Jeff >
