72753 - new certs reported as expired when clock is slow

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P3)

Description

[Sonja Mirtitsch]

distributed stress test was run:

client and servercerts were generated on kentuckyderby
selfsrv -r -r was started on kentuckyderby
strsclnt was started on jordan using the certs created on kentuckyderby

strsclnt complains about invalid servercert

jordans clock is 1min 19sec slower than kentuckyderby's (no ntp daemon running)

the same test passsed on box and washer (linux) charm (HP) and hbombaix (AIX)

the test passes on jordan, if I use a certdatabase that is 10 minutes old

TZ is set to:
jordan: PST8PDT
box: TZ: Undefined variable.
washer: TZ: Undefined variable.
charm: PST8PDT
rsh hbombaix: PST8PDT
kentuckyderby: US/Pacific

Comment 1

[Sonja Mirtitsch]

Attachment: output log

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

More info:

1. the cert DBs get generated on the server system, kentuckyderby,
in this case.

2. The client running on jordan receives the newly minted server 
cert from the SSL server running on kentuckyderby and reports
that it has expired (probably thinking it is not yet valid).

The 24 hour "pending slop time" doesn't seem to be working here.

Is this a bug introduced in rev 1.8 of certdb.c ?
Or is there a problem with LL_ macros on AIX? or ??

Comment 3

[Sonja Mirtitsch]

I am not sure if this problem is the same, but just in case...:

Patrick wrote:

  Hello,

  It looks like NSS operates in GMT time by default. So if I have a cert
  issued for 11:00 EST,  and I run an NSS-enabled app, the certificate
  will be considered "expired" or not valid yet because NSS thinks it was
  issued for 15:00 EST...At least that's how I interpreted this problem.
  In my lab I did have such a scneario and the way I got my app to accept
  the cert was to change the timezone and set it to GMT (TZ=GMT).

  So is there a way to configure NSS to use EST instead of GMT?

  -- Patrick

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Attachment: patch, convert slop time to microseconds before using it

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Please review this patch.  

I'd also like someone to review the functions in util/dertime.c, especially
DER_AsciiToTime().  I'm not convinced it's right.  If its method of 
turning a yymmddhhmmss+hhmm string into a number of microseconds since 
Jan 1 1970 is wrong then we'll see more problems.  

Comment 6

[Wan-Teh Chang]

I reviewed the patch. It is fine.

So seems like the slop time for CERT_CheckCertValidTimes()
could never have worked before, or did NSS use a datatype
for time whose unit was seconds before switching to PRTime?

Some of the 'int64' types in certdb.c should be changed to
'PRTime' to be self-documenting.  It would also be nice to
add a comment near PENDING_SLOP and pendingSlop to indicate
the time unit is seconds, although that can be inferred from
the (24L*60L*60L) constant and is documented in cert.h.
the cert.h header file

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

I concur that the slop time has apparently never worked before.

At one time, it was necessary that NSS be able to compile against
either NSPR1 or NSPR2 headers.  In NSPR1, the type PRTime was a 
structure equivalent to NSPR2's PRExplodedTime type, so it was 
not possible to use the type PRTime in sources that had to compile
against either set of headers.  That is why NSS uses int64 instead
of PRTime almost everywhere in the cert library.

However, I believe there is no further requirement for NSS to continue
to build with NSPR headers, so it is now appropriate to change all
those int64s to PRTimes.  

The next patch does that, as well as fixes one other place where the
slop time needed to be converted to microseconds.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Attachment: modified patch incorporates suggestions above

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Attachment: Corresponding changes to header files

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Attachment: Patch for NSS_3_2_BRANCH for PSM 2.0

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

This bug is now fixed on the trunk.
The patch shown above for the NSS_3_2_BRANCH would also fix it for PSM.

Comment 12

[David P. Drinan]

I checked Nelsons patch for NSS 3.2 into the NSS_3_2_BRANCH.