3.1.1.2 - Spärrkontroller

Spärrkontrollen i Common använder sig av både CRL:er (Certificate Revocation List) och OCSP (Online Certificate Status Protocol) för att avgöra om ett certifikat ska förklaras som giltigt, protokollen används i samspel med varandra för att ge ett stabilt system för spärrkontroller. För att avgöra statusen på ett certifikat används antingen CRL eller OCSP som primär källa, det andra protokollet används som fallback och påkallas ifall den primära källan inte ger ett tillförlitligt svar. Det protokoll som används vid fallback bestäms av den specifika applikationens konfiguration. Om varken CRL eller OCSP kan ge ett tillförlitligt svar på revokeringsstatus blir resultatet en UNDETERMINED_REVOCATION_STATUS.

Spärrkontroller med OCSP

Spärrkontroller med OCSP görs i första hand med direktuppslag mot OCSP-respondern. Informationen kring vilken responder det är som ska anropas hämtas direkt från certifikatet som kontrolleras. Om direktuppslaget går bra lagras revokeringsstatusen för certifikatet i Redis-cachen. Misslyckas direktuppslaget mot OCSP-respondern konsulteras istället Redis-cachen.

När giltigheten för ett certifikat kontrolleras hämtas OCSP-data via direktuppslag eller från cachen vid behov, datat tillhandahålles till en instans av CertPathValidator som utvärderar certifikatet och returnerar revokeringsstatus.

I fallen där revokeringsstatus inte går att avgöra med hjälp av OCSP går applikationen över till CRL för att försöka få en revokeringsstatus därigenom.

Spärrkontroller med CRL

Spärrkontroller med CRL görs enbart med uppslag mot en Redis-cache där spärrlistor lagras. Cachen fylls i sin tur på av ett bakgrundsjobb som hämtar spärrlistor utifrån ett konfigurerat intervall. De listor som hämtas av jobbet avgörs utifrån de certifikatsutfärdare som är inlästa i den aktuella applikationen samt av en konfigurerbar lista URL:ar som är konfigurerade för att också hämtas. Kriteriet för att spärrlistan/spärrlistor skall bli inlästa i cachen är att:

• Deras signaturer kan verifieras av någon betrodd certifikatsutfärdare.
• eller att sökvägen till spärrlistan finns angiven i konfigurationen för den specifika applikationen

När giltigheten för ett certifikat kontrolleras konsulteras cachen för matchande X509CRL-objekt från de tidigare hämtade spärrlistorna, datat tillhandahålles till en instans av CertPathValidator som utvärderar certifikatet och returnerar revokeringsstatus.

I fallen där revokeringsstatus inte går att avgöra med hjälp av CRL:er går applikationen över till OCSP för att försöka få en revokeringsstatus därigenom.

Fallback-mekanismer

Logiken för spärrkontroller är utformad för att kunna hantera en mängd onormala scenarion så som driftstörningar, tömda Redis-cachear, mm. för att i nästan alla lägen kunna ge en revokeringsstatus. Ett exempel på hur ett sådant flöde skulle kunna se ut är som följer:

1. Certifikatets giltighet ska kontrolleras mot OCSP-respondern. OCSP-respondern kan inte ge ett svar på grund av driftstörningar.
2. OCSP-cachen konsulteras men här finns ingen matchande revokeringsstatus för det aktuella certifikatet.
3. Under tiden har CRL-jobbet försökt att hämta nya spärrlistor men misslyckats på grund av driftstörningar.
4. Fallbacken mot CRL aktiveras och CRL-cachen konsulteras. Cachen hittar en matchande spärrlista och kan därigenom avgöra revokeringsstatusen för certifikatet. 
5. Som sista led kan spärrkontrollen helt inaktiveras (ej rekommenderat annat än vid kris)