Damiano ALBANI wrote:
> ...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.
Well, I didn't grab the source by CVS, I decompressed the official source tarball using Cygwin's tar and gunzip.
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?
Yes, I use Cygwin and compile with MS Virtual C++ Toolkit 2003 (the free one).
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.
I've just checked, after I use addbultin, the added part, at the bottom of certdata.txt, has ^M characters at the end of each line. That's why only *my* certificate wasn't recognized in the DLL.
It may be MS compiler's printf() which transforms \n in \r\n ?
You can have a look at <http://snotling.free.fr/certdata.tgz>.
> 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.
In NSS 3.9 build howto, it's stated to pull mozilla/security/dbm with DBM_1_61_RTM tag. But I suppose that a Mozilla release depends on a specific version of NSS, which in turn depends on a specific version of DBM ?
So how can I know this cascade of dependencies ? So that for any version of Mozilla I take, I get the right DBM version and thus, build the correct addbuiltin ?
> 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.
Actually, it may not be Mozilla's fault, as I specified a wrong path for the CRL on the Web server :(
By the way, is the 'nextInstant' in UTC or local time ? How can I force Mozilla to download this CRL ? By setting the date in the past ?
As I use a 'global_config_url' for all my clients, my goal is to force them to download a few CRLs at Mozilla's launch.
> 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]
Sorry, I was so enjoyed by my success (hem hem :) ), that I forgot this issue. I'll have a look at it.
-- Damiano _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
