Earlier quoted context omitted.
Timestamping does exist but it isn't used in the Web PKI (what you're calling "TLS certificates") Both backdating and forward dating have been done in the Web PKI for various reasons, both legitimate (e.g. historically if you couldn't randomise serial numbers enough it was acceptable to randomise the notBefore time parameters slightly, this is no longer allowed) and illegitimate (we have pretty good circumstantial ev…
Something that is currently being used (sort of widely) is X509 OCSP. As the Cert gets signed, the CA also embeds an OCSP URL which clients can later use on the fly to determine if a cert is revoked. In case of a leaked private key where the actual PKI wasn't breached, they still have authority over the CA itself and can therefore determine which certs are valid and which are fake. This retains validity of the known…
In a very important sense the private key is the CA.
The OCSP responses are not encrypted (you'll notice that URL you mentioned is HTTP, you can't use HTTPS for this) but they are signed documents. They're signed by the issuer using its Private Key.
So, somebody who has the Private Key can mint bogus OCSP responses signed with that key too.
The recovery from losing a signing key is to revoke the entire tree under that key. This will usually involve pushing out software changes e.g. a Firefox or Chrome gets fresh data from the vendor saying "This CA is no longer trustworthy, disregard it".
This disaster scenario is why the root keys aren't (must not be) online. If you break into the computer systems of a famous but competent CA and seize total control of everything, you could perhaps (it should be difficult because they're using HSMs but if you've really got control of everything it may be possible) steal the private keys for the online intermediates. But their root is physically locked in somebody's safe, so, you can't steal that by this route for the same reason you can't steal gold bars from Fort Knox by hacking the Pentagon's web site.