in ff3 an imported self-signed server certificate can't be marked trusted (edit button disabled)

RESOLVED FIXED

Status

Core Graveyard
Security: UI
P1
normal
RESOLVED FIXED
9 years ago
a year ago

People

(Reporter: al_9x, Assigned: kaie)

Tracking

({fixed1.9.1, regression})

unspecified
x86
Windows XP
fixed1.9.1, regression
Bug Flags:
blocking1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 (.NET CLR 3.5.30729)

this is when importing as opposed to adding an exception

regression from ff2 where importing works just fine


Reproducible: Always
(Reporter)

Comment 1

9 years ago
This is possibly related:

when adding a exception through certificate import the server url is set to "*" and there is no way to change it.  Perhaps that is the problem.
(In reply to comment #1)
> when adding a exception through certificate import the server url is set to "*"
> and there is no way to change it.  Perhaps that is the problem.

This should be as-designed - when you add an exception from an error page, we don't want to allow the site to sneak in a cert with a hundred altNames for paypal, ebay, etc., so we restrict it to only the server/port it came from.  When you import a cert though, you're telling us to trust it absent any context, so we don't restrict it to a particular server (obviously though, we will only trust it for servers it claims to represent), hence the "*".

I can't recreate this with a randomly selected cert, can you point to a certificate and site that has this problem?
(Reporter)

Comment 3

9 years ago
(In reply to comment #2)
> (In reply to comment #1)
> > when adding a exception through certificate import the server url is set to "*"
> > and there is no way to change it.  Perhaps that is the problem.
> 
> This should be as-designed - when you add an exception from an error page, we
> don't want to allow the site to sneak in a cert with a hundred altNames for
> paypal, ebay, etc., so we restrict it to only the server/port it came from. 
> When you import a cert though, you're telling us to trust it absent any
> context, so we don't restrict it to a particular server (obviously though, we
> will only trust it for servers it claims to represent), hence the "*".
> 
> I can't recreate this with a randomly selected cert, can you point to a
> certificate and site that has this problem?


I was dealing with my own makecert created certs but here is a public site with the same problem:
https://nntp.aioe.org/
Here are exact instructions (FF 3.0.1 on XP SP3):

1) Start the exception process, but don't confirm, instead view the cert and export it in PEM format
2) In the servers tab of the cert manager import the saved cert
3) go to the site, and you should get sec_error_untrusted_cert
(Assignee)

Comment 4

9 years ago
al_9x:

Importing a certificate does not assign trust to it!
The only thing you achieve, we "know" the cert before connecting to the site.
But that doesn't mean we trust it.

In the servers tab, there is an "edit" button.
When you click (selected) your imported cert showing "*", the edit button should be enabled.

Verify the cert and add the explicit trust you desire.
Connect again and it should work now.
(Assignee)

Comment 5

9 years ago
al_9x please test and give feedback, thanks.

I propose this is NOTABUG.
(Reporter)

Comment 6

9 years ago
(In reply to comment #4)
> al_9x:
> 
> Importing a certificate does not assign trust to it!
> The only thing you achieve, we "know" the cert before connecting to the site.
> But that doesn't mean we trust it.
> 
> In the servers tab, there is an "edit" button.
> When you click (selected) your imported cert showing "*", the edit button
> should be enabled.

the edit button is not enabled, you should be able to reproduce it with Comment #3
(Reporter)

Comment 7

9 years ago
> When you click (selected) your imported cert showing "*", the edit button
> should be enabled.

You are probably using redhat, could this be a windows thing?  I am on XP SP3 and it's disabled, tried it on a new profile as well.
(Reporter)

Comment 8

9 years ago
(In reply to comment #5)
> al_9x please test and give feedback, thanks.
> 
> I propose this is NOTABUG.

I'll changed the title to reflect the actual problem: the peer cert can't be marked trusted, because the edit button is disabled.

Can you reproduce this bug?  You said the edit button should be enabled? But is it for you?
(Reporter)

Updated

9 years ago
Summary: in ff3 a self-signed certificate imported to the servers tab still produces sec_error_untrusted_cert → in ff3 an imported self-signed server certificate can't be marked trusted (edit button disabled)
(Reporter)

Comment 9

9 years ago
(In reply to comment #5)
> al_9x please test and give feedback, thanks.
> 

Kai, Johnathan

You asked me a week ago to give feedback, I have, the bug is still unconfirmed.  Is there anything more I can do to help you reproduce it?  As I said, for me, on XP SP3 with FF 3.0.1 and a new profile, the edit button is disabled for an imported self-signed server certificate.
(Reporter)

Comment 10

9 years ago
(In reply to comment #5)
> al_9x please test and give feedback, thanks.
> 

why ask for feedback and then ignore it?
(Assignee)

Comment 11

9 years ago
I apologize for the delay. I'm not ignoring, I'm just being slow, it's just that there is more work to do than time slots available.
Likewise, it is not my intent to ignore, I do appreciate the work you've put in to helping diagnose these problems.  I'm failing at having enough hours in the day, really.
(Reporter)

Comment 13

9 years ago
Thank you both for replying.  To confirm this bug:

1) Import a self-signed server certificate to the servers tab
2) Select it and see if the edit button is enabled

This should not consume much time at all.
(Assignee)

Comment 14

9 years ago
Indeed, I can confirm the bug.
The edit button is not enabled.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 15

9 years ago
I think this is a regression.

The code in certManager.js, function websites_enableButtons()
does:
        var ti = serverTreeView.getTreeItem();
        if (!ti.hostPort.length) {
          enable_edit = true;
        }

My testing shows, the string hostPort contains ":443".

Apparently some code decides to provide a port number, even if there is no hostname. That's a bug.
Keywords: regression
(Assignee)

Comment 16

9 years ago
This might be a regression from bug 431909.

In the past the hostPort element was always the empty string. I think the new code from bug 413909 changed that, it didn't consider the possibility to have an empty hostname.
(Assignee)

Comment 17

9 years ago
Created attachment 343158 [details] [diff] [review]
Patch v1 [Checkin comment 23]
Attachment #343158 - Flags: review?(honzab)
Comment on attachment 343158 [details] [diff] [review]
Patch v1 [Checkin comment 23]

I would probably move the 'if (aPort == -1) aPort = 443' inside of 'if (!hostPort.IsEmpty()) {}' block. But this patch fixes the problem as is.
Attachment #343158 - Flags: review?(honzab) → review+
(Reporter)

Comment 19

9 years ago
(In reply to comment #17)
> Created an attachment (id=343158) [details]
> Patch v1

Is this planned for 3.1/3.5?  It's not in 3.1b3
(Assignee)

Comment 20

9 years ago
We forgot to land this regression patch in time.

Now we need approval or blocker flags...
Flags: blocking1.9.1?
(Assignee)

Updated

9 years ago
Attachment #343158 - Flags: approval1.9.1?
(Assignee)

Updated

9 years ago
Keywords: checkin-needed
Comment on attachment 343158 [details] [diff] [review]
Patch v1 [Checkin comment 23]


Could you update this cvs patch to a current hg one ? Thanks.
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P1
Comment on attachment 343158 [details] [diff] [review]
Patch v1 [Checkin comment 23]

This has now been marked a blocker, so it doesn't require patch-level approval. It does need to land on mozilla-central before landing on branch, so that should happen very soon, please?
Attachment #343158 - Flags: approval1.9.1?
Attachment #343158 - Attachment description: Patch v1 → Patch v1 [Checkin comment 23]
http://hg.mozilla.org/mozilla-central/rev/6d71ec255150
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [needs landing 1.9.1]
Landed on branch:

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/fc6cb3fba56f
Keywords: fixed1.9.1
Whiteboard: [needs landing 1.9.1]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.