397966 - Cert manager displays incorrect expiration date for ECA Root Certificate

Status: RESOLVED WORKSFORME

(Core :: Security: PSM, defect)

Description

[David Fetrow]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 Mnenhy/0.7.5.0
Build Identifier: 2.0.0.6

The ECA Root certificate is used by DOD and Military contractors to encrypt and authenticate. It is near the top of the DOD "chain of Trust" which is separate
from the more usual chain of trust used by commercial certificates.

On the Mac (MacOS 10.4) both Thunderbird and Mozilla lists cert dates as:
Issued on 6/14/04 and Expires on 5/8/04. This means it is unusable and all
certs under it are also unusable by Mozilla or Thunderbird on the Mac. There
are thousands of these ECA certs.

Thunderbird and Mozilla under Linux (debian 4.0) do not have this problem. Expiry date is listed as 06/04/2040.

Since 2040 is past the old Unix 32-bit time rollover, I wonder if
that may be the issue here? Perhaps rollover is handled differently in
MacOS than Linux?


Reproducible: Always

Steps to Reproduce:
1. Import ECA Root cert from, say, http://verisign.com/eca
2. Preferences, Advanced, security, View Certs, CA's, US Gov, ECA Root
3. See date
Actual Results:  
Cert expiration date before creation date

Expected Results:  
Expiration date AFTER creation date (year 2040).

Although technically this rates merely as a "major" bug rather than
critical it prevents information from flowing between people and groups
who care enough to spend $125/year to assure that information is not tampered
with.

It could, concevieably, cost a life by delaying important information about,
for instance, a change in maintenance on a jet.

If it is, as I suspect, a date issue: It will also get worse as time goes on.

Comment 1

[David Fetrow]

Attachment: ECA root cert whose expiration date is incorrectly displayed on Intel Macs

Finding this cert can be a bit intimidating, some (but not all) sites from which it is available will talk about Official DOD usage and such so I attached the cert
here.

Comment 2

[Phil Ringnalda (:philor)]

Hmm, my first guess would have been just display (OS X defaults to YY for short date format, but you can change that to YYYY in System Prefs - International), but since doing that displays "1904" and since you say the cert actually doesn't work, not just looks wrong, that seems like something deeper.

Comment 3

[Daniel Veditz [:dveditz]]

This is a duplicate of bug 397968 (or vice versa). Is it PSM or NSS that gets it wrong? Which of the two bugs has more useful information?

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

This bug is about the expiration date incorrectly *displayed* in cert 
manager's dialog.

Bug 397968 is about the completely vague error message displayed by
Thunderbird when it cannnot sign a message, which leads users to 
conjecture about the cause of the failure.  That's probably the most 
serious of the bugs to be fixed.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Here is some background information for interested readers of this bug.
There are TWO standard formats for date/time stamps used in certificates.

The old standard, known as UTCTime, has this format
    YYMMDDHHMM[SS][+HHMM|-HHMM|Z]

That's a two-digit year, month (01-12), date of month (01-31), Hour (in 24 
hour format 00-23), Minute (00-59), Seconds are optional (00-59), followed 
by an optional time zone identifier, which may be +HHMM, or -HHMM, or simply 
the letter Z.  In the UTCTime format, numbers less than 50 are assumed to be 
in the 2000's, and numbers 50 or greater are assumed to be in the 1900's.  

The new standard, known as GeneralizedTime, has this format
    CCYYMMDDHHMM[SS][+HHMM|-HHMM|Z]

Where CC is the century (high order two digits of the year) and the rest is 
the same as in UTCTime.  

The expiration date string that appears in the ECARootCA.pem file is a
UTCTime string, containing: 400614102009Z which is properly interpreted as
2040-June-14 10:20:09 GMT

The NSS crypto library (used in mozilla) and the NSPR runtime library,
(which provides date conversion services in mozilla) together interpret 
and (on Windows or Linux) display that date string as:
    Thu Jun 14 10:20:09 2040
which is correct (even if the order seems a little unusual).
All the code involved is C code with no known platform dependencies.

The display being given by the browser's certificate manager dialog
on the MAC is clearly not the output of NSPR.  It is apparently the output
of some Macintosh specific library that honors the user's system preferences 
for date format.  

NSS parses the UTCTime string and computes a signed 64-bit date/time stamp
known as a PRTime.  That computation is correct for the ECARootCA cert on 
Windows and Linux (both x86 platforms), and so we expect it to also be 
correct for Intel Mac's also.  

Dan, there is a test script that uses NSS test programs and NSS+NSPR shared
libraries to display the cert's fields, including validity dates, as NSS 
sees them.  Can you build NSS 3.11.x (including NSS test programs) on Intel 
Mac?  If so, I have a simple test script that you can run that will show 
exactly how NSS interprets this cert on that platform.

Comment 6

[Kaspar]

Attachment: use LongDateRec instead of DateTimeRec etc.

(In reply to comment #5)
> The display being given by the browser's certificate manager dialog
> on the MAC is clearly not the output of NSPR.  It is apparently the output
> of some Macintosh specific library that honors the user's system preferences 
> for date format.  

Correct, the problem is here actually (in nsDateTimeFormatMac.cpp):

http://bonsai.mozilla.org/cvsblame.cgi?mark=347&file=mozilla/intl/locale/src/mac/nsDateTimeFormatMac.cpp#337

The attached patch, though not very thoroughly tested yet, fixes the problem for me. (It makes use of functions which are deprecated as of 10.4, that's true - but some of the replacements are only available in 10.4 or later, so they can't be used if backwards compatibility should be maintained. And I'm not really a Carbon guy anyway...)

Not completely sure about the correct component, but my guess would be Internationalization (it's definitely not PSM, for sure).

Comment 7

[Kai Engert [:KaiE:]]

Josh, this is about a year-2038-rollover issue (32 bit integer) when displaying real-world-certificates that have an expiration date in the far future.

It's a MAC platform specific bug. People on #camino recommended we should ask for your advice.

There is a patch attached to this bug. Would it be easy for you to review it?
Thanks!

Comment 8

[Josh Aas]

> some of the replacements are only available in 10.4 or later

We only support Mac OS X 10.4 and higher on the trunk, so please use 10.4+ (non-deprecated) functions for the trunk patch. If you're creating a 1.8.x patch, you'll need to use the stuff that works on 10.2.x+.

Comment 9

[Josh Aas]

Further notes...

"Beginning in Mac OS X v10.4, the BlockMoveData function is inlined to a direct call to the POSIX memmove function. For more information, see the header file MacMemory.h."

You might want to just use memmove depending on what exactly the 10.4 header for MacMemory.h says about it. The less we have to use carbon the better.

In general it looks like we should be using CFCalendarRef instead of LongDateRec on trunk, so once you do that you might not even be using the BlockMoveData call.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

A developer in the mozilla community, built NSS 3.11.4 (used in FF2).
He used NSS's "pp" test program to parse the ECA root CA cert, to convert 
the expiration date into a 64-bit PRTime, and to print out the date using 
NSPR functions to format the date from the PRTime.  He did this on an 
Intel Mac.  The results from that program on the Intel Mac were exactly 
the same as the results from that program on windows.  The expiration date
was given as
            Not After : Thu Jun 14 10:20:09 2040
which is correct.  

This tells me that the 64-bit PRTime representation of the date was and is
correct.  Since NSS does expiration date comparisons in the PRTime format,
and not using dates in any platform-dependent display format, I conclude that
there is no evidence that NSS did found that certificate to be expired.  
The date is incorrectly DISPLAYED, but there is no evidence that the date is 
incorrectly compared to the current date for expiration purposes.  

Comment 11

[Kaspar]

(In reply to comment #9)
> You might want to just use memmove depending on what exactly the 10.4 header
> for MacMemory.h says about it. The less we have to use carbon the better.
> 
> In general it looks like we should be using CFCalendarRef instead of
> LongDateRec on trunk, so once you do that you might not even be using the
> BlockMoveData call.

Hmm, I should probably have added that apart from not being a Carbon guy I'm not a CF person either... my patch was primarily intended as a quick PoC to demonstrate where the problem is.

Replacing all the deprecated functions is beyond my current skills, I'm afraid - so I'll gladly leave this to a real OS X developer. (Note that the current version of nsDateTimeFormatMac::FormatTMTime uses four deprecated functions, actually: DateToSeconds, TimeString, DateString, CopyPascalStringToC).

In any case, should we not change the component to "Internationalization"?

Comment 12

[Kai Engert [:KaiE:]]

reassign bug owner.
mass-update-kaie-20120918

Comment 13

[:Cykesiopka]

I asked someone to help me test if this was still an issue, and it looks like the answer is no => WFM.
I guess maybe Bug 360018 fixed this.

If this is wrong, feel free to reopen.