Zaradi svoje pomembnosti so digitalni certifikati zelo izpostavljeni neposrednim ali posrednim napadom. Na primer, zasebni ključ lahko ukradejo ali ga lastnik izgubi, kar ogrozi tudi verodostojnost digitalnega certifikata; ali pa CA pri izdaji certifikata ne upošteva vseh varnostnih smernic. Zaradi takšnih primerov mora obstajati možnost, da v dvomu o zanesljivoti certifikata lahko le-tega prekličemo oziroma moramo vzpostaviti mehanizem, ki preverja, ali so certifikati veljavni.
V certifikatu, ki ga CA izda varni spletni strani, CA zapiše podatke, ki internetnemu brskalniku odjemalca (v tej vlogi je uporabnik, ko brska po spletnih straneh) omogočijo ugotavljanje ali so bili certifikati napačno izdani ali kompromitirani in jih je zato CA preklicala.
Za preverjanje veljavnosti certifikatov sta uporabnikom na voljo dva mehanizma:
Datoteka CRL vsebuje serijske številke preklicanih certifikatov z datumom in časom njihovega preklica, oznako vzroka preklica in druge podatke kot je URL, ki pove, kje se seznam nahaja. Za sezname skrbijo CA, ki so izdale certifikate, ki so vpisani v CRL. Njihovo vsebino posodablja CA periodično v intervalih, ki so krajši od 24 ur, ponavadi so dolgi eno uro, ali takoj po preklicu vsebinsko posodobi katerega od digitalnih certifikatov. Seznami CRL se ponavadi nahajajo na več strežnikih, ki so po omrežju razporejeni tako, da se maksimira dostopnost do njih.
Seveda mora nekdo (ali neka organizacija) skrbeti za CRL in za uveljavljanje smernic preklicov certifikatov. Pri preklicih nastanejo velike težave, če smo certifikat preklicali pomotoma. Za uveljavljanje delovnih smernic certifikatov je odgovoren CA, zato se pičakuje, da je zadolžen tudi za ugotavljanje, da je zahteva za preklic certifikata skladna s smernicami delovanja CA.
S protokolom OCSP poskušajo odpraviti nekatere slabosti CRL. Protokol ponuja mehanizem preverjanja statusa certifikata v sprotnem času. S tem protokolom lahko končni gostitelj poizve na OCSP strežniku, če je bil določeni certifikat preklican. Poleg prednosti OCSP, kot so manjša potrebna pasovna širina, delovanje v sprotnem času in preverjenje velikega obsega poslovanja v skoraj sprotnem času, se lahko pri njegovi uporabi pojavijo tudi problemi. To je verjetno tudi razlog relativno počasnega širjenja njegove uporabe.
Nekatere izvedbe protokola OCSP še vedno uporabljajo CRL, drugi pa so dovolj tesno povezani – integrirani – z IPK, da lahko poizvedujejo neposredno v bazi certifikatov. Ko protokol OCSP uporablja CRL, zadostuje, da CA posodablja CRL le v strežnikih OCSP. To zahteva dosti manj pasovne širine omrežja kot pri mehanizmu CRL. Zato so lahko posodabljanja dosti bolj pogosta in zato so stanja preklicov v CRL bližje „realnemu času“.
Ko je strežnik OCSP integriran s PKI, lahko s kriptografsko zaščiteno poizvedbo, ki vsebuje serijsko številko certifikata, v stežniku OCSP zahtevamo informacijo o statusu certifikata. Strežnik OCSP preveri stanje certifikata v kopiji oziroma kopijah CRL, ki jih vsebuje (od raznih CA). Svojo ugotovitev o statusu certifikata – ta je lahko "preklican", "veljaven" ali "neznan" – pošlje v svojem odzivu na poizvedovanje. Ta dialog med odjemalcem in strežnikom porabi zelo malo pasovne širine omrežja in ne potrebuje vmesnega pomnilnika za CRL. V primeru, da je strežnik OCSP integriran s PKI, lahko neposredno dostopa do informacij o preklicih certifikatih in poizvedovalec bo vedno dobil takojšen odziv na svojo poizvedbo o statusu preklicov certifikatov.