> ...I think I know where it comes from : text encoding. > Apparently, addbuiltin's output in certdata.txt is not how it should be. > So I had to do a 'unix2dos certdata.txt' followed by 'dos2unix > certdata.txt' to get everything right. > Apparently there were some ^M characters at the end of each string in > certdata.c (thus the strangeness of the content of DLL regarding the > entry of my certificate).
I examined your files: http://snotling.free.fr/certdata.txt and http://snotling.free.fr/certdata.c
Both files had only unix-style line endings (ending with only \n) rather than with windows-style line endings (ending with \r\n). That is quite unusual for files checked out and generated on a windows system.
Your .c file contained \r characters before the closing quotes in the generated strings, as it might if you processed a file with windows-style line endings on a unix machine's perl interpreter. However the certdata.txt file did not have any lines with unusual line endings. Did you perhaps check the certdata.txt out on a unix/linux system, and then copy it to windows? Or are the files on the web server perhaps not exact binary copies of the original file that had the problem?
I tried to duplicate your results on my windows box, and everything worked OK for me. No troubles with line endings. All lines had windows-style line endings. The .c file did not have any unexpected \r characters before the trailing quotes in strings, as it did in yours.
Do you use cygwin? Did you build addbuiltin with gcc? or with MSVC? or ? Does your processing environment expect Windows text files to have unix style line endings?
If you'd like to pursue it, and can regenerate the certdata.txt file that produced the .c file on your web site, please zip that .txt file up and email it to me.
> And now my cert is recognized and correct in nssckbi.dll.
> By the way, do you know how I could pull a mozilla/security/dbm for a > certain Mozilla release ? (it is absent from Mozilla's tarball and > required to build tools like addbuiltin). I can do a 'cvs co > mozilla/security/dbm' but I don't know if it's a good idea in case I > work on Mozilla 1.2 or 1.4.1 for example (so using an older DBM).
When building the NSS tools, you should pull and build the version of DBM with which NSS is certified. Follow the NSS 3.9 build instructions which should specify the cvs tags to pull DBM.
> I've also tried to specify entries in prefs.js for CRL updates, like :
>
> user_pref("security.crl.autoupdate.dayCnt.my_ca.", "1");
> user_pref("security.crl.autoupdate.enable.my_ca", true);
> user_pref("security.crl.autoupdate.freqCnt.my_ca", "1");
> user_pref("security.crl.autoupdate.nextInstant.my_ca", "11/05/2004
> 16:11:00");
> user_pref("security.crl.autoupdate.timingType.my_ca", 2);
> user_pref("security.crl.autoupdate.url.my_ca",
> "http://server/my_ca-crl.der";);
>
> But Mozilla doesn't seem to use it if it hasn't been previously imported
> *by hand* by the user. I got something like :
>
> user_pref("security.crl.autoupdate.errors", "Importing CRL to local
> Database : error ffffe009");
>
> I suppose it must be because my CRL is not in cert.db8 or a related file.Could be. That error code is SEC_ERROR_BAD_DER.
> Thanks everybody for your help.
Let's not declare victory until we solve the issue about the nickname with odd characters. Please see my posting about that here: news://news.mozilla.org:119/[EMAIL PROTECTED]
/Nelson
_______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
