Innehållsförteckning

Revisionshistorik

Testfall och scenarion

Dessa testfall och scenarion bör testas med jämna mellanrum för att säkerställa att funktionaliteten för spärrkontroller kan upprätthållas även vid driftstörningar av olika slag.

Spärrkontroller via OCSP

Spärrkontroller via OCSP ska alltid vara den föredragna metoden. Om inget annat ska testas så är det endast en konfiguration som behöver justeras.

Konfiguration för testfallet

inera.common.trust.prefer-crls=false

Utförande av testfall

Förberedelser

1. Konfigurera tjänsten som ska testas med konfigurationen ovan. Notera aktuell konfiguration för att sedan kunna återställa till det ursprungliga läget. Starta sedan om tjänsten.

Utförande

1. Genomför tester för att verifiera att tjänsten och spärrkontrollerna beter sig som förväntat. Hur testet genomförs beror såklart på vilken tjänst som används och vart spärrkontroller genomförs.

2. Verifiera via de metrics som matas ut via /actuator/prometheus så att rätt mätpunkter ökar under tiden testerna utförs. På så sätt får man en indikation ifall tjänsten gör det som förväntas.

Återställning

1. Återställ tjänsten med den ursprungliga konfigurationen. Starta sedan om tjänsten.

Spärrkontroller via CRL

Spärrkontroller via CRL:er ska aldrig vara den föredragna metoden om inte under särskilda omständigheter. Om inget annat ska testas så är det endast en konfiguration som behöver justeras.

Konfiguration för testfallet

inera.common.trust.prefer-crls=true

Utförande av testfall

Förberedelser

1. Konfigurera tjänsten som ska testas med konfigurationen ovan. Notera aktuell konfiguration för att sedan kunna återställa till det ursprungliga läget. Starta sedan om tjänsten.

Utförande

1. Genomför tester för att verifiera att tjänsten och spärrkontrollerna beter sig som förväntat. Hur testet genomförs beror såklart på vilken tjänst som används och vart spärrkontroller genomförs.

2. Verifiera via de metrics som matas ut via /actuator/prometheus så att rätt mätpunkter ökar under tiden testerna utförs. På så sätt får man en indikation ifall tjänsten gör det som förväntas.

Återställning

1. Återställ tjänsten med den ursprungliga konfigurationen. Starta sedan om tjänsten.

Tillgängliga OCSP-adresser och otillgängliga CRL-adresser

Detta test syftar till att simulera att samtliga aktuella CRL-adresser är otillgängliga eller inte går att nå. I normal drift hade detta test inte haft någon effekt då OCSP alltid ska vara den föredragna metoden.

Om ett onormalt driftläge då revokeringskontroller via CRL:er är föredraget är aktivt så kan man på så sätt simulera ifall fallback-mekanismen för att nytta OCSP fungerar som tänkt. För att säkerställa att tjänsten inte kan nå CRL-adresserna är det blockeringar av CRL-adresserna i driftleverantörernas brandväggar som behöver komma på plats. Ta kontakt med aktuell driftleverantör för att få hjälp med hur detta sätts upp. För det här testet behöver den schemalagda CRL-hämtningen inte stängas av.

För att hitta vilka adresser som ska blockeras, öppna ett certifikat som är utfärdad av aktuell utfärdare och leta fram fältet CRL Distribution Points. Där hittas sedan med fördel en eller flera URL:er som i exemplet nedan. Adressen eller adresserna som syns i det fältet behöver blockeras. Se exempel nedan.

Image Added

Konfiguration för testfallet

inera.common.trust.prefer-crls=true

Utförande av testfall

Förberedelser

1. Skapa en sammanställning av alla CRL-adresser som ska blockeras. Kontakta driftleverantör och be om att dessa CRL-adresser ska blockeras i brandväggen.

2. Konfigurera tjänsten som ska testas med konfigurationen ovan. Notera aktuell konfiguration för att sedan kunna återställa till det ursprungliga läget. Starta sedan om tjänsten.

3. Kontrollera giltighetstiden på relevanta caches (TrustStatusCache, CRLDataCache, CRL LoadingCache) och se till att dessa hinner gå ut innan testet påbörjas.

Utförande

1. Genomför tester för att verifiera att tjänsten och spärrkontrollerna beter sig som förväntat. Hur testet genomförs beror såklart på vilken tjänst som används och vart spärrkontroller genomförs.

2. Verifiera via de metrics som matas ut via /actuator/prometheus så att rätt mätpunkter ökar under tiden testerna utförs. På så sätt får man en indikation ifall tjänsten gör det som förväntas.

Återställning

1. Be driftleverantören att återställa brandväggsblockeringarna till ursprungligt läge.

2. Återställ tjänsten med den ursprungliga konfigurationen. Starta sedan om tjänsten.

Otillgängliga OCSP-adresser och tillgängliga CRL-adresser

Detta test syftar till att simulera ett scenariot då OCSP-adresserna på certifikaten inte är tillgängliga eller inte går att nå. Med fördel så är OCSP den föredragna metoden för att evaluera rekoveringsstatus. På så sätt testas i detta scenario att fallback-mekanismen mot CRL:erna fungerar som tänkt. Ifall konfigurationen av spärrkontrollerna ser ut som “vanligt” är det endast blockeringar av OCSP-responders i driftleverantörernas brandväggar som behöver komma på plats för att säkerställa att tjänsterna inte ska få nå OCSP-adresserna. Ta kontakt med aktuell driftleverantör för att få hjälp med hur detta sätts upp.

För att hitta vilka adresser som ska blockeras, öppna ett certifikat som är utfärdad av aktuell utfärdare och leta fram fältet Authority Information Access. Där hittas sedan med fördel något som heter Access Method=On-line Certificate Status Protocol. Adressen som syns i det fältet behöver blockeras. Se exempel nedan.

Image Modified

Konfiguration för testfallet

inera.common.trust.prefer-crls=false

Utförande av testfall

Förberedelser

1. Skapa en sammanställning av alla OCSP-adresser som ska blockeras. Kontakta driftleverantör och be om att dessa OCSP-adresser ska blockeras i brandväggen.

2. Konfigurera tjänsten som ska testas med konfigurationen ovan. Notera aktuell konfiguration för att sedan kunna återställa till det ursprungliga läget. Starta sedan om tjänsten.

3. Kontrollera giltighetstiden på relevanta caches (TrustStatusCache, OCSPDataCache) och se till att dessa hinner gå ut innan testet påbörjas.

Utförande

1. Genomför tester för att verifiera att tjänsten och spärrkontrollerna beter sig som förväntat. Hur testet genomförs beror såklart på vilken tjänst som används och vart spärrkontroller genomförs.

2. Verifiera via de metrics som matas ut via /actuator/prometheus så att rätt mätpunkter ökar under tiden testerna utförs. På så sätt får man en indikation ifall tjänsten gör det som förväntas.

Återställning

1. Be driftleverantören att återställa brandväggsblockeringarna till ursprungligt läge.

2. Återställ tjänsten med den ursprungliga konfigurationen. Starta sedan om tjänsten.

Otillgängliga OCSP-adresser och otillgängliga CRL-adresser, <3 dagars otillgänglighet

Detta test syftar till att simulera

ett scenario då både OCSP-adresser och CRL-adresser är helt otillgängliga eller inte går att nå

. I ett äkta driftscenario så ska tjänsten fortfarande ha tillgång till cachead information för att på så sätt kunna evaluera revokeringsstatusen för certifikaten. I detta scenario är det endast kvarvarande OCSP-cachen som kan ge en giltig OCSP-revokeringsstatus. Då den cachen har kort utgångstid jämfört med CRL-cachen så kommer testet förr eller senare börja använda CRL:erna för att evaluera en revokeringsstatus.

Testet förutsätter att adresserna har varit otillgängliga i mindre än 3 dagar. Efter att den tidsgränsen har passerats så kan inte cacheade CRL:er användas på det konventionella viset. Se separat testfall för hur det hanteras då istället.

För att säkerställa att tjänsten inte kan nå OCSP- och CRL-adresserna är det blockeringar av dessa adresser i driftleverantörernas brandväggar som behöver komma på plats. Ta kontakt med aktuell driftleverantör för att få hjälp med hur detta sätts upp. För det här testet behöver den schemalagda CRL-hämtningen inte stängas av.

För att hitta vilka adresser som ska blockeras för CRL:erna, öppna ett certifikat som är utfärdad av aktuell utfärdare och leta fram fältet CRL Distribution Points. Där hittas sedan med fördel en eller flera URL:er som i exemplet nedan. Adressen eller adresserna som syns i det fältet behöver blockeras. För att hitta vilka adresser som ska blockeras för OCSP, öppna ett certifikat som är utfärdad av aktuell utfärdare och leta fram fältet Authority Information Access. Där hittas sedan med fördel något som heter Access Method=On-line Certificate Status Protocol. Adressen som syns i det fältet behöver blockeras. Se exemplen nedan.

Konfiguration för testfallet

inera.common.trust.prefer-crls=false

Utförande av testfall

Förberedelser

1. Skapa en sammanställning av alla OCSP- och CRL-adresser som ska blockeras. Kontakta driftleverantör och be om att dessa adresser ska blockeras i brandväggen.

2. Konfigurera tjänsten som ska testas med konfigurationen ovan. Notera aktuell konfiguration för att sedan kunna återställa till det ursprungliga läget. Starta sedan om tjänsten.

Utförande

1. Genomför tester för att verifiera att tjänsten och spärrkontrollerna beter sig som förväntat. Hur testet genomförs beror såklart på vilken tjänst som används och vart spärrkontroller genomförs.

2. Verifiera via de metrics som matas ut via /actuator/prometheus så att rätt mätpunkter ökar under tiden testerna utförs. På så sätt får man en indikation ifall tjänsten gör det som förväntas.

Återställning

1. Be driftleverantören att återställa brandväggsblockeringarna till ursprungligt läge.

2. Återställ tjänsten med den ursprungliga konfigurationen. Starta sedan om tjänsten.

Otillgängliga OCSP-adresser och otillgängliga CRL-adresser, >3 dagars otillgänglighet

Detta test är en utökning på testet ovanför. Testet syftar till att simulera ett scenario då både OCSP-adresser och CRL-adresser är helt otillgängliga eller inte har gått att nå i över 3 dagar. I ett äkta driftscenario så ska tjänsten fortfarande ha tillgång till CRL-cachen men all annan cache ska vid det här laget vara tömd. I det här läget kan den konventionella evalueringen av revokeringsstatusen inte användas längre då Javas egen logik anser att CRL:er som passerat 3 dagar i ålder inte längre är giltig. Nu måste en grundläggande revokeringskontroll aktiveras som har till syfte att göra direktuppslagningar av certifikatens serialnumber i CRL:erna. Som ännu ett steg kontrolleras även ifall en giltig certifikatskedja kan byggas med hjälp av de tillgängliga utfärdare som systemet har inläst. På det sättet kan tjänsten fortfarande leverera en revokeringsstatus och på så sätt även i fortsättningen fungera även fast tillförlitligheten till att revokeringsstatusen är korrekt inte kan garanteras.

För att säkerställa att tjänsten inte kan nå OCSP- och CRL-adresserna är det blockeringar av

dessa adresser i driftleverantörernas brandväggar som behöver komma på plats. Ta kontakt med aktuell driftleverantör för att få hjälp med hur detta sätts upp. För det här testet behöver den schemalagda CRL-hämtningen inte stängas av.

För att hitta vilka adresser som ska blockeras för CRL:erna, öppna ett certifikat som är utfärdad av aktuell utfärdare och leta fram fältet CRL Distribution Points. Där hittas sedan med fördel en eller flera URL:er som i exemplet

nedan. Adressen eller adresserna som syns i det fältet behöver blockeras. För att hitta vilka adresser som ska blockeras för OCSP, öppna ett certifikat som är utfärdad av aktuell utfärdare och leta fram fältet Authority Information Access. Där hittas sedan med fördel något som heter Access Method=On-line Certificate Status Protocol. Adressen som syns i det fältet behöver blockeras. Se

exemplen nedan.

Konfiguration för testfallet

inera.common.trust.prefer-crls=false
inera.common.crl-data-service.use-old-crls

=true
inera.common.trust.use-basic-crl-revocation-checker=true

Utförande av testfall

Förberedelser

1. Skapa en sammanställning av alla OCSP- och CRL-adresser som ska blockeras. Kontakta driftleverantör och be om att dessa adresser ska blockeras i brandväggen.

2. Konfigurera tjänsten som ska testas med konfigurationen ovan. Notera aktuell konfiguration för att sedan kunna återställa till det ursprungliga läget. Starta sedan om tjänsten.

3. Vänta nu i 3 dagar så att CRL:erna inte anses vara giltiga längre.

Utförande

1. Genomför tester för att verifiera att tjänsten och spärrkontrollerna beter sig som förväntat. Hur testet genomförs beror såklart på vilken tjänst som används och vart spärrkontroller genomförs.

2. Verifiera via de metrics som matas ut via /actuator/prometheus så att rätt mätpunkter ökar under tiden testerna utförs. På så sätt får man en indikation ifall tjänsten gör det som förväntas.

Återställning

1. Be driftleverantören att återställa brandväggsblockeringarna till ursprungligt läge.

2. Återställ tjänsten med den ursprungliga konfigurationen. Starta sedan om tjänsten.

Otillgängliga OCSP-adresser och otillgängliga CRL-adresser, >30 dagars otillgänglighet

Testet syftar till att simulera ett scenario då både OCSP-adresser och CRL-adresser är helt otillgängliga eller inte har gått att nå i över 30 dagar. I ett äkta driftscenario så ska tjänsten inte längre ha tillgång till någon som helst cache och ingen revokeringsstatus kan levereras. I det här fallet är sista utvägen att godkänna att ingen revokeringsstatus kunde evalueras då tjänsten inte har något som helst underlag för att verifiera certifikatets giltighet.

I det här fallet kan testproceduren snabbas på genom att rensa samtliga cachear för att slippa vänta i 30 dagar. Nyckeln är att rensa Redis-cacherna och även starta om tjänsten så att samtliga minnes-cachear också är tömda.

För att säkerställa att tjänsten inte kan nå OCSP- och CRL-adresserna är det blockeringar av dessa adresser i driftleverantörernas brandväggar som behöver komma på plats. Ta kontakt med aktuell driftleverantör för att få hjälp med hur detta sätts upp. För det här testet behöver den schemalagda CRL-hämtningen inte stängas av.

För att hitta vilka adresser som ska blockeras för CRL:erna, öppna ett certifikat som är utfärdad av aktuell utfärdare och leta fram fältet CRL Distribution Points. Där hittas sedan med fördel en eller flera URL:er som i exemplet nedan. Adressen eller adresserna som syns i det fältet behöver blockeras. För att hitta vilka adresser som ska blockeras för OCSP, öppna ett certifikat som är utfärdad av aktuell utfärdare och leta fram fältet Authority Information Access. Där hittas sedan med fördel något som heter Access Method=On-line Certificate Status Protocol. Adressen som syns i det fältet behöver blockeras. Se exemplen nedan.

Konfiguration för testfallet

inera.common.trust.soft-fail=false
inera.common.trust.allow-undetermined=true

Utförande av testfall

Förberedelser

1. Skapa en sammanställning av alla OCSP- och CRL-adresser som ska blockeras. Kontakta driftleverantör och be om att dessa adresser ska blockeras i brandväggen.

2. Konfigurera tjänsten som ska testas med konfigurationen ovan. Notera aktuell konfiguration för att sedan kunna återställa till det ursprungliga läget. Starta sedan om tjänsten.

3. Gör en tömning av Redis för att säkerställa att ingen som helst certifikatscache finns kvar som kan hjälpa tjänsten att evaluera revokeringsstatusen.

Utförande

1. Genomför tester för att verifiera att tjänsten och spärrkontrollerna beter sig som förväntat. Hur testet genomförs beror såklart på vilken tjänst som används och vart spärrkontroller genomförs.

2. Verifiera via de metrics som matas ut via /actuator/prometheus så att rätt mätpunkter ökar under tiden testerna utförs. På så sätt får man en indikation ifall tjänsten gör det som förväntas.

Återställning

1. Be driftleverantören att återställa brandväggsblockeringarna till ursprungligt läge.

2. Återställ tjänsten med den ursprungliga konfigurationen. Starta sedan om tjänsten.

Avstängda spärrkontroller

Detta är ett orealistiskt scenario då spärrkontrollerna alltid bör vara aktiv. Däremot är det ändå en nyttig övning att testa hur tjänsten beter sig i fallet då revokeringskontrollerna medvetet har stängts av.

Konfiguration för testfallet

inera.common.trust.do-revocation-check=false

Utförande av testfall

Förberedelser

1. Konfigurera tjänsten som ska testas med konfigurationen ovan. Notera aktuell konfiguration för att sedan kunna återställa till det ursprungliga läget. Starta sedan om tjänsten.

Utförande

1. Genomför tester för att verifiera att tjänsten och spärrkontrollerna beter sig som förväntat. Hur testet genomförs beror såklart på vilken tjänst som används och vart spärrkontroller genomförs.

2. Verifiera via de metrics som matas ut via /actuator/prometheus så att rätt mätpunkter ökar under tiden testerna utförs. På så sätt får man en indikation ifall tjänsten gör det som förväntas.

Återställning

1. Återställ tjänsten med den ursprungliga konfigurationen. Starta sedan om tjänsten.