maemo.org Bugzilla – Bug 1403
Secure certificate not properly setup, says untrusted site
Last modified: 2008-04-07 15:23:51 UTC
You need to
before you can comment on or make changes to this bug.
As far as I know we are paying a SSL certificate to handle properly anything
behind https:// . However, it doesn't save the normal screens of untrusted
sites. In some cases logging to bugzilla implies to accept twice an "untrusted
site" window, one for maemo.org and another one for bugs.maemo.org. Other times
you get in a kind of loop having to accept up to 6 times.
Of course chicking the "Trust this site from now" checkbox saves you this
hassle, but then why we need a proper certification in place.
It looks like a problem of configuration. Attaching screenshots.
Created an attachment (id=421) [details]
Cetificate properties 1
Created an attachment (id=422) [details]
Certificate properties 2
Created an attachment (id=423) [details]
Error message 1
Created an attachment (id=424) [details]
Error message 2
*** Bug 1444 has been marked as a duplicate of this bug. ***
Moved to correct Product and Component.
Thanks, known issue. We are in the process of ordering new certificates. I take
Complaints about this in ITT, setting to P2.
Got the new SSL certs today morning, this will be fixed shortly.
From a user point of view the problem still persists. Reopening until the issue
is completely solved.
If you check your browser does not complain about untrusted site, it says
untrusted authority. Well, this is plain wrong, since the certificate is coming
We will not get any better than this, I am afraid. The 'Common Name' of the
authority who issued the certificate is missing, but all our certificates at
maemo.org are like that.
I try to complain, let's see...
Alright, we got it sorted out now. The intermediate certificate was missing.
Now you are not supposed to receive any weird message.
The thing is that those messages are still appearing. I was trying to find the
moment to report back but there is other user that has done it. Reopening.
*** Bug 2153 has been marked as a duplicate of this bug. ***
Please look at the additional details provided in
i.e., *.garage.maemo.org is also affected.
not quite sure what protocol says, but this should be treated as a blocker. At
some point svn clients should refused access to the svn repositories (curl I'm
told already does) which means teams may be unable to do commits.
for reference, you can use this syntax:
bug 2153 instead of including a url, Bugzilla likes it better.
I guess that currently svn is hosted by https://garage instead of
https://project.garage, so it's unaffected.
We will not get a wildcard certificate for garage. So you can forgot about
We will not get a wildcard certificate for *.maemo.org either, so you can keep
on posting that your browser complains when you type https://a.maemo.org or
https://b.maemo.org. It will not be fixed.
For the reference here is a list of valid sub domains that are in use and have
https://bugs.maemo.org (not bugzilla.maemo.org)
As far as the repo is concerned the correct address is:
http://repository.maemo.org (not https), so we do not need a certificate there.
ok, then please do us a favor and stop running https servers for any other dns
entries, otherwise you're going to get very unhappy and confused users.
note that not offering https downloads is bad news. for security reasons you
really should offer downloads via https (arguably only via https, but...).
Not using wildcard certs is your choice, but some of the root issues in this
bug (and bug 2153, which was duped to this) are clearly not fixed. A minimal
example is http://maemo.org/community/mailing-lists.html, where all the
"Subscribing via Web" links exhibit this problem.
Not supporting reasonable URLs like https://www.maemo.org in a mistake IMO, but
whatever. Still, the fact that many of these URLs *work* (if you ignore the SSL
warning) means that people are inevitably going to be linking to those pages.
Seems like the right thing to do would be to return error pages.
Is this list of subdomains something static or can we add i.e. news or
downloads? Or why can't we have this wildcard cert? (I'm asking out of
ignorance, please bare with me if I'm asking something stupid).
What is true is that as people get new versions of popular browsers these pages
under https not covered by a certificate will simply not load. We need a plan
We are still looking at this with Ferenc. By now I'm removing the "blocker"
since as for today it is not a blocker.
Jumping directly to https://maemo.org and (apprently) any subpage under it
generates and error "Unable to verify the identity of maemo.org as a trusted
site". See screenshot.
Created an attachment (id=589) [details]
Error when opening https://maemo.org/news
still experiencing this bug as described in Comment #22, can you please make
this a blocker bug again?
Ferenc, please delegate this bug to Niels updating him with any info. He will
push it. Thanks.
This is also causing me severe difficulties, as I am getting blocked when I
click the "Log in" link at http://maemo.org/, try to use Bugzilla or try to log
in to edit pages related to applications I've ported to OS2007 and am trying to
re-port to OS2008.
This is especially problematic as I am working with the Firefox 3 Beta (to give
it a good test) which doesn't even give the option of accepting un-trusted
certificates, so I have to log in as another user specifically to launch
Firefox 2 to do anything, which is, frankly, a pain in the backside.
Problem seems to be that the certificate is signed by Verisign with a
certificate that has expired. The server should provide an intermediate
certificate to fix this problem.
Somehow the maemo.org server isn't sending this intermediate certificate
together with the maemo.org certificate. All settings look ok.
Marcell is talking to the ISP to resolve this issue.
This issue has now been resolved. There shouldn't be any warnings about the
certificate for https://maemo.org.