All of Oculus’s Rift headsets have stopped working due to an expired certificate
41–50 of 390 posts
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#42Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#43They let their certificate expire, essentially bricking all of their devices. And now the app running it won't start, so they can't push an update. Just recently picked up a Rift. I love the hardware and their exclusives are top notch, but this confirms my suspicions that their backend is super goofy. They sell Rifts at Best Buy and want to pretend that it's a consumer-ready product, but here's why I am recommending…
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#44In 2091, an overworked developer will accidentally let the certificate expire for the Planetary Shield Defense Matrix, and the Zylorts will finally conquer Earth.
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#45Remember folks, if code signing, countersign with a timestamping service[1] so when your code signing cert expires, your older signed code will still work. [1] https://search.thawte.com/support/ssl-digital-certificates/i...
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#46Earlier quoted context omitted.
The problem isn't that Windows requires drivers to be signed. The problem is that Windows allows drivers to have an expiration date. If Windows verifies a driver's signature at the time the driver is installed, the driver should be considered trustworthy for as long as it remains installed on that system. There's no reason to re-verify the signature every time the driver is used .
Recommended practice is to timestamp windows drivers (and software) when they are signed. Without a timestamp, the driver is not trusted after the signing cert expires, which I guess is what happened here. With a timestamp, as long as the signing date was within the signing cert's validity period, the signed driver continues to be trusted beyond the signing certificate expiration.
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#47In 2091, an overworked developer will accidentally let the certificate expire for the Planetary Shield Defense Matrix, and the Zylorts will finally conquer Earth.
Sounds like the work of a double agent...
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#48A lot of applications and environments seem to be built with the assumption that they can add arbitrary complexity to their interface, since they're only going to be used by "experts" who can be expected to know everything of relevance and work through a thick documentation to understand the system. In truth, the "experts" who use your programs are going to also be using a dozen other applications, each with their own piles of documentation (or equal amounts of lack-of-documentation,) and have little brain-space left for the intricacies of your framework. So, they're going to use your system while knowing the minimum possible amount about it; if that system contains traps that cause problems for this kind of user, that's bad design.
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#49Remember folks, if code signing, countersign with a timestamping service[1] so when your code signing cert expires, your older signed code will still work. [1] https://search.thawte.com/support/ssl-digital-certificates/i...
What happens when the countersigning service's cert expires?
* data is not tampered
* signing certificate was time valid at signing time: signing time is within signing cert's validity
* Neither certificate was revoked before signature generation
* both, signing and timestamp certificates chain up to trusted root CAs (regardless of their time validity, just must be in trust store).
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#50Earlier quoted context omitted.
Recommended practice is to timestamp windows drivers (and software) when they are signed. Without a timestamp, the driver is not trusted after the signing cert expires, which I guess is what happened here. With a timestamp, as long as the signing date was within the signing cert's validity period, the signed driver continues to be trusted beyond the signing certificate expiration.
That seems silly. Presumably a cert has an expiration date after which we might assume its been compromised. If it has been compromised then it could have been used to backdate a driver signed with it. In other words, if you don't trust the cert you should not trust anything signed by it. Or is there another layer in this somewhere?