Closed Bug 443811 Opened 11 years ago Closed 4 years ago

Expired certificate warning: date in message unclear.

Categories

(Core :: Security: PSM, defect, trivial)

PowerPC
macOS
defect
Not set
trivial

Tracking

()

RESOLVED FIXED
mozilla43
Tracking Status
firefox43 --- fixed

People

(Reporter: brunogirin, Assigned: Cykesiopka)

References

Details

(Whiteboard: [psm-cert-errors])

Attachments

(1 file, 3 obsolete files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-GB; rv:1.9) Gecko/2008061004 Firefox/3.0
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-GB; rv:1.9) Gecko/2008061004 Firefox/3.0

One of the web sites I use regularly failed to update their SSL certificates. Firefox brought up an error message to advise me of this. It reads:

Secure Connection Failed
www.thefaultywebsite.com uses an invalid security certificate
The certificate expired on 6/7/08 at 07:53

Considering I uses a UK English build of Firefox and it's a site I visit frequently, I assume the date above is 6th July 2008. However, if I communicate this error to the web site owners who are in the US, they may well read this as 7th June 2008. It would help debugging and communication if the date was in a long format that made the date obvious.

Reproducible: Always

Steps to Reproduce:
1. Go to a website that has an expired SSL certificate, if possible before the 12th of the month.
2. Use any function that requires HTTPS
Actual Results:  
A message similar to this appears:

Secure Connection Failed
www.thefaultywebsite.com uses an invalid security certificate
The certificate expired on 6/7/08 at 07:53

Expected Results:  
The date should use a long format to ensure clarity, such as:

Secure Connection Failed
www.thefaultywebsite.com uses an invalid security certificate
The certificate expired on the 6th July 2008 at 07:53
I agree, this is a very common problem . Localizing is one thing, but you also need to be able to communicate with other people that might be used to a different format.

This particular change should happen in the call to FormatPRTime at <http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsNSSIOLayer.cpp#1108>. But there are many more locations where this is used (search for kDateFormatShort for instance).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Given the files in question live in PSM, moving this bug over there.
Assignee: nobody → kaie
Component: Security → Security: PSM
Product: Firefox → Core
QA Contact: firefox → psm
just fyi, I think the shown date format should be independent of the installed build, but rather depend on locale configured on the local system.

The problem here is that we're passing a null locale into function FormatPRTime (first argument).

Let's find out how to obtain the correct locale object that we should use?
although I'd rather prefer to use some non-ambiguous ISO format like yyyy-mm-dd
Kai, ignore my comment about using a UK English build of Firefox in the bug report. This was pure speculation and it could very well be that the locale used was indeed the system's locale.

In fact, if you follow the code from the pointer given by Jo above, you go through the following code points (on UNIX at least):
http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsNSSIOLayer.cpp#1108
http://mxr.mozilla.org/mozilla-central/source/intl/locale/src/unix/nsDateTimeFormatUnix.cpp#278
http://mxr.mozilla.org/mozilla-central/source/intl/locale/src/unix/nsDateTimeFormatUnix.cpp#291
http://mxr.mozilla.org/mozilla-central/source/intl/locale/src/unix/nsDateTimeFormatUnix.cpp#181

all the way to the Initialize function:

http://mxr.mozilla.org/mozilla-central/source/intl/locale/src/unix/nsDateTimeFormatUnix.cpp#55

And this function checks for a NULL locale and initialises to whatever the default locale of the application is, which is the correct behaviour.

What drives the format is the second argument to FormatPRTime, as suggested by Jo above. Replacing kDateFormatShort with kDateFormatLong should return a string that uses a date in long format, which is an unambiguous user readable format, probably something like dd mmmm yyyy for English. Considering this is a user message, a message in that format is what is needed.

The ISO format is good for output that needs to be machine parsable without ambiguity but not ideal for user display.
I'm not sure it's the same dialog (else I should open a new bug, I can't find one more TB-specific), but in Thunderbird I've got a similar problem with the certificate of my IMAPS connections: moreover the same page used two DIFFERENT FORMATS to tell the certificate expiration date and the current date, which of course doesn't have sense, it's only less easy to confront 'em. ;)
Using the locale wouldn't necessarily help unless you'd set your short date format to something unambiguous. Long date format would be clearer.  I just found this bug after not knowing if "The certificate expired on 12/6/08 20:28." meant 1 month or 6 months ago.
Whiteboard: [psm-cert-errors]
reassign bug owner.
mass-update-kaie-20120918
Assignee: kaie → nobody
/r/9327 - Bug 443811 - Use long date format for cert date output.

Pull down this commit:

hg pull -r facf286c376a0ab4659f0ad44fce34422debf866 https://reviewboard-hg.mozilla.org/gecko/
Attachment #8609893 - Flags: review?(dkeeler)
https://reviewboard.mozilla.org/r/9325/#review8025

Ideally I would like to use ISO 8601 dates, or even ISO 8601 + long date, but just switching to long date is the easiest change that doesn't break nsIX509CertValidity API.

Adding/switching to ISO 8601 can be done in Bug 1053679 I guess.
I'm not sure I see the benefit of doing this incrementally. Why don't we just directly switch the nsIX509CertValidity API to ISO 8601 dates?
Flags: needinfo?(cykesiopka.bmo)
(In reply to David Keeler [:keeler] (use needinfo?) from comment #11)
> I'm not sure I see the benefit of doing this incrementally. Why don't we
> just directly switch the nsIX509CertValidity API to ISO 8601 dates?

Other than "it was an easy patch" and "some of these short date formats are so incredibly silly anything is an improvement", no other benefit. I'll look into switching the API.
Flags: needinfo?(cykesiopka.bmo)
Attachment #8609893 - Flags: review?(dkeeler)
Attachment #8609893 - Attachment is obsolete: true
Comment on attachment 8617976 [details]
MozReview Request: Bug 443811 - Use long date format for cert date output.

Bug 443811 - Use long date format for cert date output.
Attachment #8617976 - Flags: review?(dkeeler)
(In reply to Cykesiopka from comment #12)
> I'll look into switching the API.

I looked into this briefly, and it doesn't seem to be worth the effort to switch the API to ISO 8601.

nsIDateTimeFormat doesn't support it, and implementing support properly involves at least one OS I don't have access to.

https://bugzilla.mozilla.org/show_bug.cgi?id=1053679#c2 also seems to be a reasonable argument.
Comment on attachment 8617976 [details]
MozReview Request: Bug 443811 - Use long date format for cert date output.

https://reviewboard.mozilla.org/r/9327/#review14029

Ship It!
Assignee: nobody → cykesiopka.bmo
Oops, looks like the patch has been bit-rotten.
Keywords: checkin-needed
+ Fix bitrot
Attachment #8617976 - Attachment is obsolete: true
Attachment #8646781 - Flags: review+
Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/8e248632025d for making OSX xpcshell tests perma-crash like https://treeherder.mozilla.org/logviewer.html#?job_id=12795266&repo=mozilla-inbound


I see this in the crashing thread:
XUL!nsDateTimeFormatMac::FormatTMTime(nsILocale*, int, int, tm const*, nsAString_internal&) [nsDateTimeFormatMac.cpp:74ec3ff61daa : 196 + 0x24]
Flags: needinfo?(cykesiopka.bmo)
(In reply to Wes Kocher (:KWierso) from comment #24)
> Backed out in
> https://hg.mozilla.org/integration/mozilla-inbound/rev/8e248632025d for
> making OSX xpcshell tests perma-crash like
> https://treeherder.mozilla.org/logviewer.html#?job_id=12795266&repo=mozilla-
> inbound
> 
> 
> I see this in the crashing thread:
> XUL!nsDateTimeFormatMac::FormatTMTime(nsILocale*, int, int, tm const*,
> nsAString_internal&) [nsDateTimeFormatMac.cpp:74ec3ff61daa : 196 + 0x24]

Seems 10.10-specific... XPCshell tests on 10.6 are not crashing...
(In reply to Wes Kocher (:KWierso) from comment #25)
> (In reply to Wes Kocher (:KWierso) from comment #24)
> > Backed out in
> > https://hg.mozilla.org/integration/mozilla-inbound/rev/8e248632025d for
> > making OSX xpcshell tests perma-crash like
> > https://treeherder.mozilla.org/logviewer.html#?job_id=12795266&repo=mozilla-
> > inbound
> > 
> > 
> > I see this in the crashing thread:
> > XUL!nsDateTimeFormatMac::FormatTMTime(nsILocale*, int, int, tm const*,
> > nsAString_internal&) [nsDateTimeFormatMac.cpp:74ec3ff61daa : 196 + 0x24]
> 
> Seems 10.10-specific... XPCshell tests on 10.6 are not crashing...

Thanks for the heads up. I'll try and investigate what's causing the assert.
Status: NEW → ASSIGNED
Flags: needinfo?(cykesiopka.bmo)
Depends on: 1195177
+ Use kTimeFormatSeconds instead of kTimeFormatSecondsForce24Hour to workaround Bug 1195177

In all the various places kTimeFormatSecondsForce24Hour is used, the date is formatted according to the environment locale anyways. I don't really see why a 24 hour time has to be forced here.
Attachment #8646781 - Attachment is obsolete: true
Attachment #8660565 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/23c3b1d231ce
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
Duplicate of this bug: 1222292
Blocks: 444573
You need to log in before you can comment on or make changes to this bug.