Yes, there's an earlier thread about this above, but the tale is so enthralling it seemed worth recapping, regrouping, redigesting and seeing if anyone can confirm my only current hypothesis.
For consistency let's start with new DB files. We install certs from within the browser and archive the DBs. We create new DBs, install certs programmatically using pk12util and archive the DBs.
Then against each set of DBs let's run certutil -L and certutil -K, plus certutil -L -n for each certificate that's been created (these .pfx files contain the cert chain back to the Root CA). And for an encore we'll trot out certutil -V and certutil -O. We'll pipe the output to two files, one for the browser-entered certs, one for their programmatically-entered siblings.
Doing a diff on the two files reveals the only significant difference to be the naming of the certificates in cert7.db. The browser-entered certs appear with the Organisation name appended to the Common Name (eg "MyClient HMSCert CA - MyClient Limited"). The programmatically-entered certs just have the Common Name (eg "My Client HMSCert CA"). Everything else; trust settings, detailed cert content, chaining; is identical.
Now the plot thickens.
When the certs are entered from within the browser it's necessary to manually set the appropriate trust authorisation on the "Signers" or "Authorities" tab (browser-dependent names) before the private keys can be verified. Attempting to verify the private keys before setting trust levels gives the following result:
Verification of the selected certificate failed for the following
reasons:
MyClient Root CA - MyClient Limited[Certificate Authority]
Certificate not trusted
Interesting. Because if Netscape is opened against the DBs containing the programmatically-installed certs and this exercise is repeated, the result is:
Verification of the selected certificate failed for the following
reasons:
privateKey
Unable to find Certificate Authority
Let's hold off on any conclusions for a moment.
Pointing a binary diff tool at the two cert7.db files, the output obviously differs in many minor respects, which is what we'd expect. However, the only clear difference between the two when it comes to the content of the entries for these particular certs is, again, the name assigned to them within the database. The difference is the same as that outlined above ("CN - O" vs "CN").
Does this ring any bells, resonate with any experiences, trigger any collegial developer memories? To me, given that there are no other differences in the detail of the certificates, I'm tempted to leap mindlessly to the conclusion that Netscape is looking for a parent cert based on name and not finding it. But how does one change the name of a cert programmatically?
The only dissenting morsel of evidence is this. When running certutil
-V against the private keys, the result is always
certutil: certificate is invalid: Peer's certificate issuer
has been marked as not trusted by the user.
This is the case with both the browser and programmatically -installed certs (which all display "C,C,C" or "u,pu,u" when we call certutil -L). Nonetheless, the browser-installed certificates do the SSL thing and get us to the website without incident.Given opportunity they'd probably get us to the church on time too.
I guess it goes to show you can't nail mince to the wall.
::Leigh
[EMAIL PROTECTED]
