Michael Kaply wrote: > Nelson B Bolyard wrote: >> what does >> certutil -d ~ -L >> output? > > c1dfd405-9dc0-4b7c-8e98-7b2772a81922 u,u,u > Thawte Code Signing CA - Thawte Consulting cc c,c,c > thawte c,c,c
> With NSS 3.12 it looks like this after import (and works) > > c1dfd405-9dc0-4b7c-8e98-7b2772a81922 u,u,u > Thawte Code Signing CA - Thawte Consulting cc ,, OK, there are some possible clues there, but I don't have enough info about those certs to be able to give a full diagnosis yet. Let me ask some questions and make some guesses that you can try. - I gather that you exported your code signing cert and its private key to a pfx file from Windows' cert store using Windows cert export wizard. That's because it has a UUID for a nickname. Windows gives every cert and key a UUID, and if you don't give your cert a "Friendly Name" before exporting it, Windows uses the UUID as the "Friendly Name" in the pfx file when it exports the cert and key. So, if you'd like a friendlier friendly name, go into windows cert manager and give that cert a Friendly name, then re-export it to a new pfx file, and then import it into a clean set of NSS DB files. - Did those CA certs also get exported in the pfx file? Or did you import them some other way, such as through your browser or with certutil? Please tell us how you imported them. - Did you do the exact same set of steps with 3.11 as with 3.12, starting with a DB in the same starting state? - Did you use the exact same pfx file in both cases? Or did you remake the pfx file each time? I'm guessing that you imported the CA certs from individual .cer files using the browser's cert manager, rather than from the pfx file. I guess that because their trust flags are c,c,c (which is almost never what you really want), and PSM has (or had, not sure if it still does) a habit of always setting those 'c' flags on CA certs when it imports them, if I recall correctly. But maybe that's a difference between 3.11 and 3.12. I also observe that your 3.11 DB has one more cert in it than the 3.12 DB. I can think of several possible explanations for that, including: a) you only imported that cert for 3.11 and not for 3.12, or b) the cert that is seen in the 3.11 DB but not the 3.12 DB is present in nssckbi for 3.12 but not in nssckbi for 3.11.9. Now here's a guess about how to solve the problem. I'm guessing that the CA cert identified as "thawte" is actually a thawte root CA cert. I'm guessing that in 3.12, that cert is in nssckbi and is marked as trusted for object signing. In your 3.11 DB, you have that cert there marked as UNtrusted for code signing. Perhaps this is because that root cert is NOT present in 3.11.9. (I don't know if it is or not, because the nickname "thawte" doesn't tell me enough to identify which of thawte's many CA certs that is.) An easy test of this hypothesis is to mark that last thawte cert in your 3.11.9 DB with a different set of trust flags, showing that it IS trusted for issuing object signing certs, then try signing with signtool again. To change the trust flags on that "thawte" cert, use a command like this: certutil -d ~ -M -n "thawte" -t "c,c,C" Let us know if that does it. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
