> Johnathan is right on. I think you need to generate a base64-encoded > version of the binary values (not the textual serializations).
Based on this blog post here http://www.jessies.org/~car/blog/200907081926-for-firefox-sake.php, it is actually base64 encoding of a block of memory - a long int containing the der representation of serial number and the issuer name. Chris's (the author of that blog post) hack produces the exact notation of the string that you see in the cert_override.txt under your profile directory. So it is the nsNSSCertificate::GetDbKey() that actually generates that string for you. > I did > something similar when playing with EV certificates, and the method I > used to get these encoded values involved patching NSS tools to spit > them out. > I did try your patch and it produced the base64 output as you mentioned. But it was different from the format that you see in cert_override.txt, where that magic string starts with a sequence of "AAAA...". But interestingly enough, your string also worked. When I injected the self-signed cert in to cert8.db & populated the cert_override.txt with your magic string output from pp, firefox accepted it! So now, this throws another wrench in my understanding of how FF actually deals with cert_override. Does the exact format the magic string actually matter? Or does firefox just check for the certificate in its cert store (cert8.db) & verify cert fingerprint in cert_override.txt and allow access to the site? _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
