Opened 4 years ago

Closed 4 years ago

#15586 closed defect (fixed)

Use 64-bit value to represent times

Reported by: params Owned by: rekkanoryo
Milestone: 3.0.0 Component: unclassified
Version: 2.10.7 Keywords:


When using the attached CA certificate pidgin uses NSS library to parse it and somehow it gets the expiry date as (null). The same CA certificate is correctly parsed by Mozilla Firefox 20.0. Perhaps there is need to update the NSS library.

Attachments (1)

Zscaler.cer (1.2 KB) - added by params 4 years ago.
zscaler intermediate root CA

Download all attachments as: .zip

Change History (8)

Changed 4 years ago by params

zscaler intermediate root CA

comment:1 Changed 4 years ago by datallah

  • Status changed from new to pending

Is there a publicly accessible server that uses this cert?

comment:2 Changed 4 years ago by params

  • Status changed from pending to new

Actually this particular certificate is issued by the proxy server being used in our organization. For any https site accessed through the proxy this is an intermediate CA. I doubt it is being used publicly outside my organization.

To reproduce the issue you just to add this atttached certificate via Tools->Certificates menu option and then press "Get Info" button for this new certificate. In the information the expiry date is mentioned as (null).

In my case I try to use pidgin for gtalk via using our internal proxy and then this particular certificate gets added in the chain and upon getting expiry date as (null) pidgin reports an error saying invalid certificate chain. I tried to add this certificate in the C:\Program Files\pidgin\ca-certs folder also, but then also the issue is same.

comment:3 Changed 4 years ago by datallah

  • Milestone set to 3.0.0
  • Summary changed from Issue in parsing CA certificate to Use 64-bit value to represent times

It's really a terrible thing to MITM all SSL traffic via a proxy, but that's relatively unrelated to the problem.

The reason it's *relatively* unrelated and not completely unrelated is that you probably won't find real certificates in the wild that expire after 2038-01-19 (the 32-bit unix timestamp barrier), but your certificate expires in 2063 (which is not really not a sane timeframe for a current certificate to expire).

It isn't actually an issue with NSS, but rather a libpurple issue and is a real bug.

The libpurple API uses time_t to store the effective and expiration dates and time_t is a 32-bit number on Windows with the default C runtime. It's also a 32-bit number on 32-bit Linux systems as far as I can tell.

This isn't something that can be corrected without an API change (which can't happen until the 3.0.0 release of Pidgin). Part of changing this behavior will likely mean that we need to use the glib date/time functions instead of the system functions (

comment:4 Changed 4 years ago by params

Thanks datallah for the detailed explanation (unix version of Y2K for dates after year 2038) behind this curious bug. Just wanted to add that using proxy for all internet is part of the corporate policy and there is not much I can do about it.

Waiting for Pidgin 3.0.0

comment:5 Changed 4 years ago by Daniel Atallah <datallah@…>

(In [2aa4d5ab8916]):
Add workaround so that certificates with times that can't be represented using 32-bit timestamps will still work when using NSS. Refs #15586

  • the current libpurple API uses time_t (signed 32-bit on most platforms)
  • this works by fudging the certificate dates to the subset of the time window that can be represented with time_t

comment:6 Changed 4 years ago by params

Is it possible to get nighly build (for windows xp/7) corresponding to the revision which contains your patch?

comment:7 Changed 4 years ago by Daniel Atallah <datallah@…>

  • Resolution set to fixed
  • Status changed from new to closed

(In [2ca1bb194693]):
Update certificate API to use 64-bit unsigned values instead of time_t. Fixes #15586

  • The dates may display incorrectly on glib < 2.26 because we only have ctime() to format the value, but (at least for NSS), functionality should be correct.
Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!