View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000410||Main CAcert Website||certificate issuing||public||2007-02-05 17:42||2013-01-14 21:23|
|Fixed in Version||2007|
|Summary||0000410: Status of certificate not reflected on website|
|Description||When creating a new server certificate, it is correctly signed and visible on the website.|
However, it doesn't appear under "Server certificates", "Domain certificates" when you log in to the site.
When clicking the link to change view from "Domain Certificates" to "View all cetificates", it is visible, but still in the state "pending" with an expiry date of "0000-00-00 00:00:00".
It looks to me as if the status of the certificate is not correctly being updated in the DB.
|Tags||No tags attached.|
||This also seems to be the case for client certificates.|
||I had the exactly same problem with my renew or new server certificates.|
OK, I looked at the code as why this could happen. This is what I found.
What I see on the website:
Expires is "0000-00-00 00:00:00"
Status is "pending"
The PHP variables to display the page:
$verified is set by:
if($row['expired'] == 0)
$verified = _("Pending");
The SQL query also says
UNIX_TIMESTAMP(`domaincerts`.`expire`) as `expired`,
`domaincerts`.`expire` as `expires`
So "expireD" is the epoch time of "expireS"
Due to the panding state, $row['expired'] must be 0 as returned from the SQL query.
(But, if ExpireD is really 0, I would expect expireS to be 1970-01-01 00:00:00, strange.)
The "expire" field in the "domaincerts" table must be set incorectly when a certificate is generated. It's not the actual expirydate.
It seems when the expiry date is updated, it's empty due to leading spaces when there is only 1 digit in the day of the month.
Just wait until tomorrow and then it will work again. ;-)
I guess it will be fixed by next month.
In the DB desciption:
`expire` datetime NOT NULL default '0000-00-00 00:00:00',
makes it the strange date.
That explains the inconsistency noticed in the previous comment.
fix_expirydate.php (2,027 bytes)
I added a file that should fix the current broken dates in the DB.
It's not tested and it will probably contain errors.
The actual update query is commented out, it should output what's going on.
||The bug has been fixed, the database table of the old server certs has been fixed. We couldn´t find any affected client certs.|
||johan: Can you please check, whether the bug is actually solved, and close this bug in case?|
It looks OK for me, so I close it.
I still find it a little strange no affected Client certs were found.
(Problems were reported on the mailinglist.)
|2007-02-05 17:42||johan||New Issue|
|2007-02-05 19:32||johan||Note Added: 0000773|
|2007-02-07 16:56||mbartsch||Note Added: 0000774|
|2007-02-09 10:42||johan||Note Added: 0000776|
|2007-02-09 11:28||johan||Note Edited: 0000776|
|2007-02-09 11:30||johan||Note Added: 0000777|
|2007-02-09 11:41||johan||Note Edited: 0000777|
|2007-02-09 12:03||johan||File Added: fix_expirydate.php|
|2007-02-09 12:06||johan||Note Added: 0000778|
|2007-02-09 15:16||Sourcerer||Status||new => needs work|
|2007-02-09 15:16||Sourcerer||Assigned To||=> Sourcerer|
|2007-02-09 19:40||Sourcerer||Status||needs work => solved?|
|2007-02-09 19:40||Sourcerer||Fixed in Version||=> production|
|2007-02-09 19:40||Sourcerer||Resolution||open => fixed|
|2007-02-09 19:40||Sourcerer||Note Added: 0000781|
|2007-02-11 13:27||Sourcerer||Note Added: 0000785|
|2007-02-13 09:42||johan||Status||solved? => closed|
|2007-02-13 09:42||johan||Note Added: 0000787|
|2013-01-14 21:23||Werner Dworak||Fixed in Version||=> 2007|