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?
No. NSS does all time computations for cert validity in GMT times.
NSS has two functions for verifying certificates:
CERT_VerifyCert and CERT_VerifyCertNow
CERT_VerifyCert takes a PRTime argument which tells it what date/time
against which to check the cert. PRTime values are in GMT time by definition.
CERT_VerifyCertNow calls CERT_VerifyCert with the value from PR_Now()
as the date/time against which to check the cert.
Here are some comments from the NSPR header files about PRTime and PR_Now().
* NSPR represents basic time as 64-bit signed integers relative
* to midnight (00:00:00), January 1, 1970 Greenwich Mean Time (GMT).
* (GMT is also known as Coordinated Universal Time, UTC.)
* The units of time are in microseconds. Negative times are allowed
* to represent times prior to the January 1970 epoch. Such values are
* intended to be exported to other systems or converted to human
* readable form.
* The PR_Now routine returns the current time relative to the
* epoch, midnight, January 1, 1970 UTC. The units of the returned
* value are microseconds since the epoch.
It is the responsibility of the program that calls CERT_VerifyCertNow
to ensure that the time it passes is GMT-based. If some program is
producing incorrect results, it is likely that that program is passing
a value that is not GMT based. If that program is PSM, then please
file a bug against PSM.
--
Nelson Bolyard
