Description
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.