Bug 158703 - certwatch incorrectly compares current time to UTC times in certificates
certwatch incorrectly compares current time to UTC times in certificates
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: crypto-utils (Show other bugs)
4
All Linux
medium Severity low
: ---
: ---
Assigned To: Joe Orton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-24 19:51 EDT by Alexandre Oliva
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.2-6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-26 05:01:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed patch (796 bytes, patch)
2005-05-25 16:58 EDT, Tomas Mraz
no flags Details | Diff

  None (edit)
Description Alexandre Oliva 2005-05-24 19:51:37 EDT
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 02:46:57 EDT
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 13:27:56 EDT
            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 13:30:45 EDT
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 16:13:01 EDT
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 16:58:15 EDT
Created attachment 114854 [details]
Proposed patch

This should fix it.
Comment 6 Joe Orton 2005-05-26 05:01:58 EDT
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.