Genau das meinte ich. Es gibt verschiedene Ansätze, um den Widerruf des Zertifikats auch wirklich dem Client mitzuteilen, aber alle haben ihre Probleme.
Sperrlisten werden in regelmäßigen Abständen heruntergeladen, aber alles was nach dem Download der letzten Version heruntergeladen wurde bleibt gültig, bis eine neue Version der CRL geladen wurde. Das kann aus Performancegründen aber nicht all zu häufig passieren, denn gerade nach Großereignissen wie Heartbleed können diese Listen eine beträchtliche Größe erreichen (Mobilnutzer mit beschränktem Volumen würden sich bedanken). Außerdem erfordert der Missbrauch eines Zertifikats immer irgend eine Form von man-in-the-middle Angriff. Wenn der Angreifer aber sowieso schon in der Leitung sitzt kann er auch den Download einer neuen CRL unterbinden.
Das gleiche gilt für die zweite Widerrufstechnik, die Der-Orden-Xar genannt hat. OCSP ist ein Echtzeitprotokoll, bei dem der Browser bei einem Server die Gültigkeit des Zertifikats abfragt. Ein Angreifer kann auch hier die Antwort abfangen. Bei ausbleibender Antwort werden die Browser per default alle das Zertifikat als gültig akzeptieren. Ein anderes Problem ergibt sich daraus, dass man bei OCSP sämtliche besuchte Seiten einem Drittanbieter mitteilt. Zum Schutz der Privatsphäre verzichtet ein standardmäßig eingestellter Chrome deshalb z.B. auf diese Form des Checks.
Das Problem des Widerrufs entscheidet sich also nicht dadurch, ob man eine 'tolle' Bezahl-CA hat, die diese Möglichkeit anbietet oder nicht, sondern dadurch, ob der Widerruf im Client ankommt. Einer der wenigen Ansätze, um die problematische Situation hier zu verbessern sind kurze Zertifikatslaufzeiten.
