Interesting: Error: Expected certificate attribute 'issuerName' value incorrect, expected: 'OU=Equifax Secure Certificate Authority,O=Equifax,C=US', got: 'CN=GeoTrust SSL CA,O="GeoTrust, Inc.",C=US'. Source File: resource://gre/modules/CertUtils.jsm Line: 60 Is thrown when you check for updates in SeaMonkey 2.5b1 We do have |CN=GeoTrust SSL CA,O="GeoTrust, Inc.",C=US| as part of our prefs here. So not sure what is going wrong. (Or if this is simply thrown as it is the first that we test with). Either way having this error appear is a bad omen to our users. CC-ing rstrong about this and his thoughts. (Since its not technically an error unless all potentials fail -- I'm loathe to have Cu.reportError here)

Agreed that this could be improved with some added complexity to the code so if you'd like to change the behavior feel free to provide a patch. Keep in mind that when there is a failure all errors must be reported. If you would like to just stop the error from happening in the future you could just flip the preferences around so the one that succeeds is checked first.

Also appears in Version 2.3 build 20110813. The error message "*Update Failed* Something is trying to trick Seamonkey into an insecure update. Please contact your network provider ans seek help." is misleading and frightens any Seamonkey user. Automatic updates are broken because of this.

(In reply to Hb [:Hb] from comment #2) > Also appears in Version 2.3 build 20110813. The error message "*Update > Failed* Something is trying to trick Seamonkey into an insecure update. > Please contact your network provider ans seek help." is misleading and > frightens any Seamonkey user. > > Automatic updates are broken because of this. No. This bug is because we report the failure to verify a cert even when the next cert is successfully verified. That message is due to a different bug.

(In reply to Robert Strong [:rstrong] from comment #3) > > Automatic updates are broken because of this. > No. Please see the error message. Trying to update doesn't change Seamonkeys version number. I consider this as failure. Seamonkey queries the DNS: 1. aus2-community.mozilla.org: ... cname cb-ausstage01.sj.mozilla.com 2. cb-ausstage01.sj.mozilla.com: type A, class IN, addr 63.245.210.21 And then totally 4 packets with around 60 bytes each are exchanged. > This bug is because we report the failure to verify a cert even when the > next cert is successfully verified. I notice only one connection attempt. Seamonkey has only one pair of IssuerName and CommonName in the preferences: app.update.certs.1.commonName = aus2-community.mozilla.org app.update.certs.1.issuerName = OU=Equifax Secure Certificate Authority,O=Equifax,C=US > That message is due to a different bug. Do you mean bug 653830 or http://support.mozilla.com/de/questions/803171? I see a workaround by patching app.update.certs.1.issuerName = CN=GeoTrust SSL CA,O="GeoTrust, Inc.",C=US

(In reply to Hb [:Hb] from comment #4) > Created attachment 564417 [details] > Error message: Update Failed > > (In reply to Robert Strong [:rstrong] from comment #3) > > > Automatic updates are broken because of this. > > No. > Please see the error message. Trying to update doesn't change Seamonkeys > version number. I consider this as failure. No, *this* bug is about SeaMonkey 2.3.1+ spewing unnecessary errors when there is no error. The bug you are seeing is: Bug 679677 If you are on 2.1, 2.2 or 2.3.0 you'll have that error about the update itself, when you only have that issuerName as part of the prefs, (and is the exact reason we released 2.3.1 and had updates for that out for over a month). That said, I will be creating an addon to add the necessary prefs "shortly" and announcing it on many places, including the official seamonkey blog.

(In reply to Hb [:Hb] from comment #4) > Seamonkey has only one pair of > IssuerName and CommonName in the preferences To clarify Callek's comment above, what you are saying here is only true for 2.1 to 2.3 and was the reason why we did a 2.3.1 at all, see bug 679677. 2.3.1 and later have 3 pairs of IssuerName and CommonName allowed in preferences, so updates do work. As the first (unchanged) one is not matching the cert we are using now, though, we run into the problem this bug report is for, we are reporting an error that in fact isn't one.

and then it is normal to see the same error in 2.4.1 ,not just in 2.5b1 , if I got it right :-) Thanks

Callek, bug 704988 should have stopped the errors from being written to the error console. Could you please verify and close this bug if this is true? Thanks

V. Fixed by 704988