Patrick wrote:
> My app is a custom NSS-enabled app. It does call CERT_VerifyCertNow in my
> certificate authentication callback function (specified by
> SSL_AuthCertificateHook). And this function does not take a time argument.
> So how can my app take responsibility for passing in the right time?
In my previous message on this subject I wrote:
> > CERT_VerifyCertNow calls CERT_VerifyCert with the value from PR_Now()
> > as the date/time against which to check the cert.
> > * 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.
UTC is the new term for GMT, btw.
NSPR's PR_Now function uses a platform-dependent method to get the GMT
time.
On unix, PR_Now calls gettimeofday() which (on many Unix flavors)
depends on the proper setting of the TZ environment variable in order to
return GMT properly. If your system time zone is set wrong, or your process
doesn't have TZ set properly, then you'll get the wrong times. This is
pretty typical on Unix. In your case, I think TZ would be set to EST5EDT
On Windows, PR_Now calls ftime(), which uses time zone info obtained from
a call to GetTimeZoneInformation(). Both of those functions are Win32
functions. GetTimeZoneInformation (I believe) gets its time zone info
from somewhere in the O.S. which is initialized from the registry, which
is set using the date/time control panel applet.
On Win95 systems, there is a known problem where the system gets into a
state where the time zone that the date/time control panel applet shows
you is DIFFERENT from the value application programs receive.
This leads to a confusing situation where the date/time control panel
appears to have the correct time zone but applications compute wrong results.
In such cases, the solution is to use the date/time control panel applet to
change the time zone twice, once to change it to some intentionally wrong
time zone (don't use GMT), and then after rebooting, change it again back
to the correct time zone and reboot again. This procedure seems to get the
date/time applet's time zone and the applications' time zones back in sync.
> Also if I run NSS's certutil tool, my certificate times are displayed as
> "15:00 EST" even though the times shown in my certificate server (CMS4.2
> on NT) show "11:00 EST".
Which of those times is correct? Did you issue the cert at 1100 or at 1500?
Are you saying that the "not before" time in the certificate is wrong when
it is issued?
Is the program that fails also running on the same NT system as CMS? or
a different system? What type of system is it running on?
The cert contains "notbefore" and "notafter" times. Those times always
include an explicit time zone. Often that time zone is "Z" which means GMT.
The notbefore time in the cert should be equivalent to the time of issuance
in your time zone. If you issue the cert at (say) 11:00 EDT and the cert's
notbefore time reads 15:00 Z, that's OK.
certutil is supposed to show you the notbefore and notafter times exactly as
they are in the cert, with whatever time zones are in the cert. If the
cert has a GMT time zone and you're in the EDT zone, it should still display
the GMT time.
> ..So it looks like to me that CERT_VerifyCertNow is working right but
> NSS is interpreting the times in the certificate incorrectly?
> which would mean a bug in CERT_VerifyCert?
>
> Another possibility is that my test CMS is really issuing certs in GMT time (I
> doubt it)?
Again, If you issue the cert at (say) 11:00 EDT and the cert's notbefore time
reads 15:00 Z, that's OK. But if you issue the cert at 11:00 EDT and the
cert's notbefore time says 15:00 EDT, that would be wrong.
I can think of numerous possibilities, including
1. Perhaps CMS is issuing a cert with the wrong start times. Perhaps it is
creating a notbefore time value with the GMT time but the local time zone.
E.g. you issue the cert at 1100 EDT which is 1500 GMT, but the cert says
notbefore 1500 EDT.
2. Perhaps PR_Now is returning the wrong value, possibly because the information
on which it relies to know what time zone you're in is incorrect (as discussed
above).
3. Perhaps NSS improperly decodes the "notbefore" time in the cert (e.g.
misinterpreting the time zone in that string).
4. Perhaps NSS improperly compares the PR_Now value with the decoded notbefore
time from the cert. I doubt that's the case because this code has been
reviewed repeatedly by many people.
To track this down, it would be helpful if you could do all the following
things:
1. Modify your program (the one that's having the failure) to call PR_Now
immediately after CERT_VerifyCertNow fails, and display the 64-bit value
in hex.
2. Issue a new cert, and test it with the modified program.
3. assuming it fails, email me all the following:
- the true time at which you issued the cert.
- the true time at which the test failed
- the hex value of PR_Now from the test program when it failed
- the raw binary, or base64 encoded, DER cert.
Maybe I can reproduce it with that info.
--
Nelson Bolyard Sun / Netscape Alliance
Disclaimer: I speak for myself, not for Netscape
