Application update using SSL and own certificate
Philipp Wagner
I have another problem with the application update. Using an HTTP
app.update.url works without problems.
The problem comes with HTTPS URLs for app.update.url. I add our in-house
certificate using JavaScript with the method described here:
This works great for normal XMLHttpRequests, I do them all the time. But
doing an "check for updates" gives me the catch-all error "xml malformed
(200)".
A debug build and the highest possible NSPR logging gives me a huge log
file but not really much additional information, but I guess the problem
comes from the way I add our certificate. To quote [1]:
"updateLink using an https site with a non-builtin token CA signed
certificate will fail regardless of whether or not updateHash is used."
I guess that's valid for an application update as well?
Am I right with my assumptions? Is there anything I can do about it?
Thanks!
Philipp
[1]
https://developer.mozilla.org/en/extension_versioning,_update_and_compatibility
Robert Strong
I personally haven't played with the different cert import cases but it
appears to be possible per
https://bugzilla.mozilla.org/show_bug.cgi?id=401292
Cheers,
Robert
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
Philipp Wagner
thanks for your reply.
Am 25.11.2009 22:32, schrieb Robert Strong:
> I personally haven't played with the different cert import cases but it
> appears to be possible per
> https://bugzilla.mozilla.org/show_bug.cgi?id=401292
If I read the bug report right, the problem here was that the builtin
SSL certificate for AMO was not recognized any more after adding own
certificates in a strange way.
I on the other side want to use my own certificate to connect to my
update site.
From https://bugzilla.mozilla.org/show_bug.cgi?id=401292#c62 it seems
that it would be possible to remove this restriction to built-in
certificates now if upgrade issues from Firefox 2 were resolved (see
comment 42 in that bug report).
Should I file a bug report for that or is there no chance that this gets
fixed anyways?
Philipp
Jesper Kristensen
> Hi Robert,
>
> thanks for your reply.
>
> Am 25.11.2009 22:32, schrieb Robert Strong:
>> I personally haven't played with the different cert import cases but it
>> appears to be possible per
>> https://bugzilla.mozilla.org/show_bug.cgi?id=401292
>
> If I read the bug report right, the problem here was that the builtin
> SSL certificate for AMO was not recognized any more after adding own
> certificates in a strange way.
> I on the other side want to use my own certificate to connect to my
> update site.
>
> From https://bugzilla.mozilla.org/show_bug.cgi?id=401292#c62 it seems
> that it would be possible to remove this restriction to built-in
> certificates now if upgrade issues from Firefox 2 were resolved (see
> comment 42 in that bug report).
>
> Should I file a bug report for that or is there no chance that this gets
> fixed anyways?
>
> Philipp
You are right in that you cannot use your own CA root unless you rebuild
NSS and compile your CA root into it at build time. You could of cause
also patch the JS component to remove the extra protection.
Removing this restriction might be possible now that certificate
exceptions are added in a different way starting in Firefox 3.0, as said
in your linked comment. However as far as I remember old exceptions were
not migrated at the time of the switch, so Firefox users, who used
Firefox from all the way back to Firefox 2 may still have such
exceptions, which needs to be migrated or removed before the extra
restriction can be relaxed. However migrating those might be tricky, as
I am not sure if it is possible to distinguish them from intentionally
added new CA roots. You can try to file a bug, but I wouldn't count on
it being fixed.
Nelson Bolyard
> You are right in that you cannot use your own CA root unless you rebuild
> NSS and compile your CA root into it at build time. You could of cause
> also patch the JS component to remove the extra protection.
Be aware that making any of those changes would mean that you would be
unable to distribute the result under the Mozilla & Firefox trademarked
brand names and logos. It's fine for your own private testing, but ...
See http://www.mozilla.org/foundation/trademarks/policy.html
Philipp Wagner
I've reported it at https://bugzilla.mozilla.org/show_bug.cgi?id=531694,
please move it into the right bugzilla category, I didn't find one that
I thought would fit.
This bug shows again the problems Mozilla has with SSL certificate
handling inside corporate environments. The way I add our in-house
certificate is a hack at best (the same thing CCK does) and this bug
shows that certificates added this way are not even equal to built-in
ones. (I'm developing a XULRunner application, and while patching
XULRunner would be possible, I'd rather like to avoid that.)
Perhaps this topic could be put on the agenda some time?
Philipp