Hey ctruhn!

I feel your pain. And while I'm no tech guru when it comes to certs. I do know a dev who is. He said he is going to look into this issue for you, give it some good thought and ask his co-workers for any ideas on this.

Thinking out load he said:
I don't think we can do that. There are the built-in roots that are "read-only" as part of the code, but changes/edits happen in the user's profile key*.db and cert*.db files.

He shouldn't have the conflicts he says he's getting especially for a non-trusted cert. (Is it really a CA cert? Seems unlikely. Maybe an intermediate)

Also I was thinking, could you give us the link to the specific site that's causing you this trouble? The devs could test the heck out of it and see what is occurring. Hopefully this isn't a security sensitive site or something you can only access from within a company network.

If you'd prefer not to mention the site in public, PM me the information and I will forward it to the dev.

In the meantime, he asked me if I could point you to the enterprise mailing list. As if there any tools for accomplishing this, they'd know.

Those are intermediate certificate that a server sends and that Firefox to build a valid certificate chain that ends with the build-in root certificate.
Firefox stores such intermediate certificate automatically, so they can be used on a next visit and in case when a server sends an incomplete certificate chain (missing intermediate certificate).
Stored intermediate certificates show as "Software Security Device" in the "Security Device" column in the Certificate Manager.

I'm not aware of a way to prevent Firefox from saving such intermediate certificates and you probably need to delete the cert8.db file to get rid of them.

Thanks to both of you for responding.

I may be using the wrong nomenclature for the certificates I am receiving. The one in question is shown as a "Software Security Device" although the name says "Root CA 123". I have never really had to deal with these too much before this issue, so bear with me if I state a few things wrong. Almost everything I "know" about it has been learned while trying to troubleshoot this issue.

To explain my problem in more detail:

The site that we are visiting which causes this new cert to get added is an internally hosted server that, unfortunately, is not able to be accessed publicly through our firewall. I could pass on the link, but it wouldn't do much good since our firewall would end up denying you before you got there.

But to show the symptoms:

I currently have a smart card with a personal certificate that some of our servers use to validate me. If I look at the 'Certificate Hierarchy' of my personal cert normally it shows:

* Root CA 123
  * CA 456
    *Doe.John.582917394

Root CA 123 is shown as being at the top of it's own hierarchy and issued by itself. This is my authoritative CA.

Now if I browse to one of the sites that is giving me this "bogus" CA, it automatically adds ANOTHER, duplicate named, certificate in my Authorities list named "Root CA 123" but it is a DIFFERENT cert. It has a different fingerprint and signature. So this is what I now have in my authority list:

• Root CA 123 -- With fingerprint ending in 01:02:03 - This is the "GOOD" CA that I put there myself and is trusted.
• Root CA 123 -- With fingerprint ending in 09:08:07 - This is the "BAD" CA that got automatically loaded when I visited a particular website

The "bad" CA (09:08:07) is not trusted in Firefox for any of the 3 available trust options. This is expected since I have not done anything to choose to allow that new cert. So in a normal situation, this isn't a problem that it added the new CA because it isn't trusted, it's just that it knows about it.

But where the problem comes in is that if I look at my personal certificate now it shows the 'Certificate Hierarchy' as:

* Interoperability CA 456
  * Root CA 123
    * CA 456
      * Doe.John.582917394

This is because that new, bad, Root CA 123 is issued by 'Interoperability CA 456' and Firefox is now seeing that my card says it was issued by 'Root CA 123' and Firefox is matching that to the bad CA 123 and is showing that new hierarchy.

So now when I visit certain other sites that normally work fine, I get an error saying they don't trust the issuer of my certificate and do not allow me access. Now it takes manual intervention to get access to the site again.

Now if I go back to my authorities list and delete that bad Root CA 123, my personal certificate hierarchy is correct again because Firefox (or from what I can tell, certutil) is matching the proper Root CA 123 again and things work fine.

I have verified this behavior using certutil and it shows duplicate Root CA 123 names when I search with the '-n' option and point it to my local certificate database (~/.mozilla/firefox/*.default/).

As I mentioned above, I have also verified that so far certutil is matching this bad Root CA 123 first when doing a delete of the nickname "Root CA 123". However, since the name is identical and certutil only deletes based on the nickname of the cert I am very hesitant to push my little script out that clears the bad cert. If I delete the wrong one, it is more of a pain to get the right one loaded again.

I have talked to various people who manage these servers that are causing these problems and I believe we know where the problem actually is, but it can take weeks/months for them to get the problem resolved due to various technical and bureaucracy hurdles. In the short term I was hoping for a band-aid that I can use within Firefox to alleviate the symptom while the source problem is being resolved.

I have a ticket open with Red Hat for this "issue" to see if they knew a way to lock down the CA list but so far have not been able to make any progress and I was hoping that going straight to the source would help.

Since this is not really a Firefox problem at it's core, I realize that there might not be a way to do this. I think I can approach this various ways, but so far I haven't figured out one that works.

1) Make Firefox prompt the user before accepting a new CA, even if it isn't trusted

2) Make Firefox not allow a new CA to be added to the list

3) Find a more unique way to delete certs with certutil rather than by name alone. If I could use the signature or another unique data point I would be more comfortable pushing out a script that runs in cron or something to check if this bad CA exists on some regular basis and if it does, remove it. Really any second data point would help since the only common thing between them is the nickname

4) Without using Firefox directly, make the cert*.db read only so that new CAs can't be added.

5) ?????

So far all of these ideas have hit a dead end in one place or another, but I was hoping there was another option that maybe I haven't thought about.

I have verified that the Windows guys don't see this problem with IE, but I am unable to really test to see Firefox + Windows shows the same result (more bureaucracy).

If the answer is no, I'll figure something else out.

Thanks again everyone. I really appreciate your help.

- Fixed some formatting above

No problem ctruhn. After speaking with the dev again, he had some followup questions:

• I assume "Root CA 123" is an example name, not the real name?
• smart card -- is "Root CA 123" one produced by his company, or is it also one of the built-in ones in Firefox if he didn't have the smartcard installed?

Seems unlikely two unrelated CA or sub-CA certs would have the exact same issuer name. Was the name too generic? If they actually related and I assume created by your organization perhaps you could simply add the "Integration CA 456" certificate to your root store -- assuming you trust it.

Firefox validates certificate chains by looking up issuers, and in case of duplicates by default it grabs the one with the most recent "Not Before" date. There is a newer algorithm under development that won't stop at the first match but will continue to trying intermediate combinations until it finds a match or runs out of options. If you'd like to try it you need to add the boolean preference "security.use_libpkix_verification" and set it's value to true. This pref will not appear in about:config by default, but you can right-click in about:config to add it.

Here is an article on technet that explains the issue that the server that is hosting these certs is having:

http://blogs.technet.com/b/pki/archive/2010/05/13/certificate-path-validation-in-bridge-ca-and-cross-certification-environments.aspx

I have talked to the admins of the boxes in question and they are looking into fixing the source problem, but it is now out of my hands and will take a while. In the mean time I am having to deal with the annoyances of it. By this point I have probably spent more time trying to find a work-around than the time it would have taken me to delete the 'bogus' cert each time it comes up, but now I am just interested in it.

dveditz - Thanks for the information about how it uses the "Not Before" date. That is consistent with what I am seeing as well. The technet article also mentions it.

The "security.use_libpkix_verification" setting doesn't seem to change the behavior of Firefox when selecting the certificate chain. I'm using an old version of Firefox (Red Hat's supported 10.0.12). This is the most up-to-date in RH's repo, but it's still definitely not 18.0. Do you know if that functionality exists in said version?

So since I haven't found a way to stop from taking the CA into the list, I think I am comfortable enough with a hacky script to delete the duplicate cert. It does appear to always match that cert first since it's Not Before date is the most recent. I still don't like doing it that way, but as long as I do a bit of error checking I think I can live with it.

The initial question still stands that if anyone knows of a better way to do this I would be interested to hear.

Thanks again guys.

Yes, security.use_libpkix_verification exists on the ESR 10 branch. Sorry that didn't help, it should have rejected the invalid path and only returned the path to your local root.