FF3RC1: An error occurred while trying to find updates
legaev...@gmail.com
To support FF3 I changed protocol of updateUrl in my extension to
HTTPS. Extension installs and works fine, but I see "An error occurred
while trying to find updates" error after trying of update.
I set extensions.logging.enabled to true and see following message in
Error Console:
Datasource: Update Started
Datasource: Addon Update Started: {a0a23159-1418-4a08-
bc4d-72045629c4b1}
RDFItemUpdater:checkForUpdates sending a request to server for:
https://local.site.com/extension/update.rdf, item =
({id:"{a0a23159-1418-4a08-bc4d-72045629c4b1}", version:"0.2.4.1",
installLocationKey:"app-profile", minAppVersion:"1.5",
maxAppVersion:"3.1", name:"myExtension", xpiURL:"", xpiHash:"",
iconURL:"chrome://myextension/skin/myext-32x32.png",
updateRDF:"https://local.site.com/extension/update.rdf", updateKey:"",
type:2, targetAppID:"{a0a23159-1418-4a08-bc4d-72045629c4b1}"})
RDFItemUpdater::onXMLLoad: cert issuer is not built-in
Datasource: Addon Update Ended: {a0a23159-1418-4a08-
bc4d-72045629c4b1}, status: 4
Datasource: Update Ended
P.S. local.site.com - is a local site (Apache 2.0) with self-signed
certificate.
P.S.S. In FF2.0 updates work fine.
John J. Barton
> Hello Everyone!
>
> To support FF3 I changed protocol of updateUrl in my extension to
> HTTPS. Extension installs and works fine, but I see "An error occurred
> while trying to find updates" error after trying of update.
My advice is to ignore the error messages. In my experience they are not
helpful. You're better off reading your install.rdf and update.rdf
carefully and comparing them to ones that work.
John.
Eric H. Jung
----- Original Message ----
> From: "legaev...@gmail.com" <legaev...@gmail.com>
> P.S. local.site.com - is a local site (Apache 2.0) with self-signed
> certificate.
AFAIK, you cannot use self-signed certificates. You need a cert that has a valid chain to a root CA.
Eric
Dave Townsend
> Hello Everyone!
>
> To support FF3 I changed protocol of updateUrl in my extension to
> HTTPS. Extension installs and works fine, but I see "An error occurred
> while trying to find updates" error after trying of update.
> I set extensions.logging.enabled to true and see following message in
> Error Console:
>
> Datasource: Update Started
> Datasource: Addon Update Started: {a0a23159-1418-4a08-
> bc4d-72045629c4b1}
> RDFItemUpdater:checkForUpdates sending a request to server for:
> https://local.site.com/extension/update.rdf, item =
> ({id:"{a0a23159-1418-4a08-bc4d-72045629c4b1}", version:"0.2.4.1",
> installLocationKey:"app-profile", minAppVersion:"1.5",
> maxAppVersion:"3.1", name:"myExtension", xpiURL:"", xpiHash:"",
> iconURL:"chrome://myextension/skin/myext-32x32.png",
> updateRDF:"https://local.site.com/extension/update.rdf", updateKey:"",
> type:2, targetAppID:"{a0a23159-1418-4a08-bc4d-72045629c4b1}"})
> RDFItemUpdater::onXMLLoad: cert issuer is not built-in
That is the appropriate error, your ssl certificate must be signed by
one of the built in CAs
legaev...@gmail.com
May be I can solve this problem by moving my extension to
addons.mozilla.org?
Mook
> legaev...@gmail.com wrote:
>> RDFItemUpdater::onXMLLoad: cert issuer is not built-in
>
> That is the appropriate error, your ssl certificate must be signed by
> one of the built in CAs
Huh, not even for a properly user-installed CA? How would third-party
distributors (think CCK-using large organizations deploying internally)
be able to provide updates? Get a "real cert"?
(Not that getting one is necessarily such a hard thing... but still,
this gives me a gut feel of Doing It Wrong)
--
Mook
John J. Barton
Another alternative is to use signed updates rather than https. The
extension is shipped with a public key. When the update.rdf is
downloaded by Firefox, its signature is checked by Firefox. If that
check succeeds, then Firefox downloads the update and computes its hash
to prevent attacks during download.
Here are the steps as I remember them:
1. Use mccoy http://developer.mozilla.org/en/docs/McCoy to put a
public key string into your install.rdf.
2. build your XPI zip file, including the install.rdf from #1.
3. Compute the SHA256 hash of the XPI file (a string), put this
updateHash in your update.rdf
4. Use mccoy to sign the update.rdf with the key from #1.
This is more complex than using addons.mozilla.org, but also more flexible.
John.
Mike Shaver
<mook.moz+nntp.n...@gmail.com> wrote:
> Dave Townsend wrote:
> > legaev...@gmail.com wrote:
>
> >> RDFItemUpdater::onXMLLoad: cert issuer is not built-in
> >
> > That is the appropriate error, your ssl certificate must be signed by
> > one of the built in CAs
>
> Huh, not even for a properly user-installed CA? How would third-party
> distributors (think CCK-using large organizations deploying internally)
> be able to provide updates? Get a "real cert"?
Any known-to-the-browser CA should work; if you find that it doesn't,
please file!
Mike
Eric H. Jung
A third option is to host your download at mozdev.org, where you don't have to go through the strict review process required by AMO. Mozdev provides secure updates and installs. For more info, see http://www.mozdev.org/drupal/wiki/MozdevDownloadReleases
Nils Maier
That's not the case, as Dave already mentioned.
Only those from the built-in token (i.e. only directly compiled into the
NSS db) will be accepted.[1]
Same goes for Application AUS btw.
So even if your organization runs a proper local CA and the ca cert was
installed into the certdb, even then you're out of luck.
Nils
http://mxr.mozilla.org/seamonkey/source/toolkit/mozapps/shared/src/badCertHandler.js#59
Mook
from Nils) and Mossop on IRC say it doesn't. Should I still file?
(the token name "Builtin Object Token" doesn't get localized, right?)
Mossop also says (or I misinterpreted him to mean) that, at the time,
NSS had no way of reporting that a trust was temporary, and that it
might be able to do so now. Better ask him directly :)
--
Mook
Mike Shaver
<mook.moz+nntp.n...@gmail.com> wrote:
> Hmm, I don't have a test case, but both code inspection (see the message
> from Nils) and Mossop on IRC say it doesn't. Should I still file?
With a test case, I think you should file -- I don't know of any
reason that all installed CA roots shouldn't be permitted for
extension update checks.
Mike
Mook
Filed as bug 435743 ; the built-in-CA-only was due to bug 340198. The
test didn't exist in the first place because, umm, no tests that
actually used https existed as xpcshell tests...
--
Mook
Demiao Lin
I encountered the same problem~
Eric H. Jung
----- Original Message ----
> From: Demiao Lin <ldm...@gmail.com>
> > P.S. local.site.com - is a local site (Apache 2.0) with self-signed
> > certificate.
> > P.S.S. In FF2.0 updates work fine.
>
> I encountered the same problem~
It's not a problem. It's working as designed. Self-signed certs aren't supported.
Eric