Is it possible to make Firefox not accept any new Certificate Authorities without user interaction?
Long story short, I have having a problem where Firefox is adding a CA to it's database that is hosing things up. The actual problem is with the cert that is being offered to me, and I am working with that system owner to fix the cert, but in the mean time I would like to have Firefox not ever load the CA into it's database. This new CA is added without the user being prompted at all. Simply visiting a specific website causes this new CA to be added to the list (but again, not trusted, just added to the list).
By default when it is loaded the new cert has no permissions so it is not trusted, but the problem is the fact that the CA that is added is a duplicate name with another known good CA in my list and it causes things to go wacky when there are two with the same name (different signatures, different issuer, the only thing the same is the nickname).
I know this isn't a problem with Firefox directly. In 99.9999% of cases when it adds an additional CA to the list it doesn't cause a problem at all because it is not trusted and it won't inherently allow the secure connection. But since fixing the real problem with the owner of the website is going to take a long time (weeks/months) I would like to put a band-aid on the symptom so that I can cut my maintenance of this topic down greatly.
I am running Red Hat Enterprise Linux 5.9 with Firefox 10.0.12 (RHEL distributed Firefox).
I could go into extreme detail to explain what is causing my problem, but the short question I have is "Is there a way to make the CA database read-only"?
I have tried editing the permissions of cert8.db in ~/.mozilla/firefox/*.default/ to only be readonly (0400) vice read-write (0600) currently. However this causes Firefox to have kittens when I try to use anything that reads the CA list so I had to change it back.
I have a hacky script to remove the CA using certutil, but since certutil uses the 'nickname' of the cert to decide which one to delete, and both the good cert and the bad cert have the same nickname I get worried I'll blow away the good one and not the bad one. So far it has consistently matched the bad cert, but I don't have enough confidence that it will do that every time to push it out to my users. If I could use certutil -D with something more specific than nickname (fingerprint, signature value, etc) I would be OK with that as well.
I know there are options to restrict user changes to things like proxies and the such, is there a similar way to do it with CAs? about:config doesn't appear show anything that looks like it would do it.
Can I have it prompt me when it tries to add a CA to the database and allow me to say yes/no?
I am OK if the change is something that requires manual intervention if we do decide to add another CA to the list. Currently I am having to repair this problem multiple times a day and new CAs don't come all that often.
Unfortunately, I can't simply upgrade to the latest Firefox as software restrictions are in place. I'm open to any ideas you may have.
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:
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.
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.
No problem ctruhn. After speaking with the dev again, he had some followup questions:
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:
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.