cwilcox
novice
Posts: 8
Loc: Cambridge, MA
Registered on 08-03-07
Post Rank (AVG):
|
 09-29-08 05:02 PM - Post#304611 - Post Rank:
In response to HUIT
It is in fact an SSL issue. I solved the problem by replacing the server.pem SSL certificate file with one from a working system. While this is a full working solution, it comes with a caveat. This will allow you to leave SSL encryption enabled, but having the same cert on multiple client machines is generally a bad idea.
The best solution to the problem is to do a reinstall of the application while having your computer's clock set to a date before September 22th, 2008, apply all updates and set the date back to today. The cert that's created should be valid.
Oh sure, huit, you solved the problem  Here's some more background info I hadn't yet passed along. Oh, and I submitted a bug report about this to FileMaker today.
The problem is like the Year 2038 problem but where that involves a signed 32 bit value starting from 1/1/1970, this is an unsigned 32 bit value starting from 1/1/1900. The "Internet clock" rollover is February 7, 2036 06:28:16 UTC, 9,999 days after September 22, 2008 Dates with Special Importance in Computing
I don't know if NTP is literally involved in the certificate generation but this is the timestamp scheme it uses. NTP uses an unsigned 64 bit value to store timestamps but 32 of the bits are for fractions of a second.
A little googling turned up a problem with that the rollover in Microsoft Word 2000 WD2000: Tables with Dates Beyond the Year 2036 Sort Incorrectly I'm sure there are others as it likely affects any program storing the timestamp as a 32bit unsigned integer that starts counting from 1/1/1900.
Edited by cwilcox on 09-29-08 05:03 PM. Reason for edit: added comment about bug report
|
