Handle bad system date on install

[tresf]

A customer installed QZ Tray however could not connect. The browser console logs showed the following error message:

WebSocket connection to 'wss://localhost:8181/' failed: Error in connection establishment: net::ERR_CERT_DATE_INVALID   qz-tray.js:120

Upon reviewing of the logs, it appears something has gone awry with the system date causing QZ Tray to generate a certificate for 2056 instead of something more sane, like 2022.

2020-09-30 22:36:54,970 [INFO] SSL certificate is still valid for 12878 more days: 2056-01-04T05:09Z.

It's my belief that the issue was caused by a system date being incorrect at time of original install, however this bug could be mitigated if QZ Tray were to regenerate a new SSL cert in the event it spots a validity over a certain threshold. Newer SSL rules don't permit SSL certs which last longer than 2 years (#504 via Ballot 193) and will predictably fail for a 36-year cert.

The task is to see if a 36-year offset can still produce usable SSL certs (e.g. upon restart).

My instinct is to say that if the root CA also suffers the 36-year offset (into the future), it won't work where as an offset into the past will. There's a good chance this bug will be closed as won't-fix but I wanted to document the anomaly.

Note, reinstalling QZ Tray fixed the issue for the offending machine.

[tresf]

Newer SSL rules don't permit SSL certs which last longer than 2 years (#504 via Ballot 193) and will predictably fail for a 36-year cert.

Unfortunately -- by design -- the root-ca.crt file that we create at runtime isn't renewable and a root cert generated for the future should still break the chain, since SSL's x509 NotBefore field should be honored strictly.

For this reason, the specific use-case of a future cert is invalid as a fixable bug. Happy to reopen if someone disagrees. For now, reinstall QZ Tray and the problem should go away.