Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 158703 - certwatch incorrectly compares current time to UTC times in certificates
Summary: certwatch incorrectly compares current time to UTC times in certificates
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: crypto-utils
Version: 4
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Joe Orton
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-24 23:51 UTC by Alexandre Oliva
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version: 2.2-6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-26 09:01:58 UTC


Attachments (Terms of Use)
Proposed patch (deleted)
2005-05-25 20:58 UTC, Tomas Mraz
no flags Details | Diff

Description Alexandre Oliva 2005-05-24 23:51:37 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050512 Fedora/1.0.4-2 Firefox/1.0.4

Description of problem:
I'm not sure whether this is a problem in the installer or in openssl, so please redirect if appropriate.

The problem at hand is that the installer creates localhost.crt certificates that aren't valid at the time of the first boot, even though the system clock is correctly set during installation.  Which is not to say that I've run `date' or somesuch while the installer ran, all I know is that, before I rebooted for the install, and right after the box came back up when the install was complete, the clock was correct, and no ntpdate was involved.

Nevertheless, the certificate is not valid for at least two hours after install is complete.  I know it's off by a large amount because I get e-mail from certwatch, started by anacron long after the first boot, saying:

Date: Mon, 23 May 2005 21:22:33 -0300

 ################# SSL Certificate Warning ################

  Certificate for free, in file:
     /etc/pki/tls/certs/localhost.crt

  The certificate is not valid until Mon May 23 22:29:29 2005.

  Browsers will not be able to correctly connect to this
  web site using SSL until the certificate becomes valid.

 ##########################################################
                                  Generated by certwatch(1)


I often install Everything, with local time set to America/Sao_Paulo, with the system clock in UTC, but I'm not sure whether this is relevant.  Three hours is the current offset between America/Sao_Paulo (configured as localtime) and UTC (which the hardware clock is configured to use).

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Install Everything
2.Boot up
3.Check the root mailbox a few hours later

Actual Results:  certwatch will report localhost.crt is not valid yet

Expected Results:  it should be

Additional info:

Comment 1 Tomas Mraz 2005-05-25 06:46:57 UTC
What is the mtime of the localhost.crt file?
And what is the Not Before value printed by openssl x509 -text -in
/etc/pki/tls/certs/localhost.crt?


Comment 2 Alexandre Oliva 2005-05-25 17:27:56 UTC
            Not Before: May 24 02:26:17 2005 GMT

-rw-------  1 root root 1334 May 23 23:26 /etc/pki/tls/certs/localhost.crt

Seems about right...  This should place it in the middle of the install.

Could it be that certwatch is checking the UTC time in the certificate against
localtime?

Comment 3 Alexandre Oliva 2005-05-25 17:30:45 UTC
In case it's not obvious, I've collected the data in my previous comment on a
box different from the one that I used when preparing the original report.  Both
of them (and, in fact, all but one of the 6 boxes I've recently installed) had
this problem.  The one that didn't have the problem is one that takes 5+ hours
to install, so this might explain why.

Comment 4 Tomas Mraz 2005-05-25 20:13:01 UTC
This is a certwatch flaw - it incorrectly compares mktimed time (UTC) from the
certificate to current time() value.


Comment 5 Tomas Mraz 2005-05-25 20:58:15 UTC
Created attachment 114854 [details]
Proposed patch

This should fix it.

Comment 6 Joe Orton 2005-05-26 09:01:58 UTC
Thanks a lot Tomas, added in 2.2-6.


Note You need to log in before you can comment on or make changes to this bug.