Certificate Revocation Authority. Certificate Revocation Authority

Transkript

1 Certificate Revocation Authority i Certificate Revocation Authority

2 Certificate Revocation Authority ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME Februar 2015 AA

3 Certificate Revocation Authority iii Indhold 1 Indledning Begreber Algoritme Logning Installation Kompilering Konfiguration Database Deployment Opsætning schedule.xml seal.xml services.xml bootstrap.xml Keystore CRS Remote CRS Databasen Endpoints Revokeringer

4 Certificate Revocation Authority 1 / 5 1 Indledning Certificate Revocation Authority (CRA) er et tool til NSP platformen der er ansvarlig for at opretholde en database med informationer om de certifikater der er trukket tilbage af udstederen. Databasen skal replikeres til alle NSP miljøer således at data er tilgængelig for SecurityValve og SecurityHandler. CRA er udviklet som en J2EE web applikation og anvender Spring til konfiguration og skedulering. Konfigurationsfilerne er specifikke for JBoss8/Wildfly som skal anvendes. 1.1 Begreber Certificate Authority (CA) En udsteder af X.509 certifikater. Nets og TDC er eksempler på CA er. En CA har et enkelt rod CA certifikat og muligvis flere intermediate CA certificater som bruges til at udstede slutbruger-certifikater. Certificate Revocation Tilbagekaldelse af et certifikat. Hvis et certifikat bliver kompromiteret kan det stadig anvendes på grund af den struktur som X.509 certifikater har. En CA vælger derfor at tilbagekalde et certifikat hvis det er nødvendigt. Certificate Revocation List (CRL) En liste af tilbagkaldne certifikater. Listen vedligeholdes og offentliggøres af en CA. Det er op til CA en hvor mange forskellige CRL er der indgår i infrastrukturen. Et certifikat udsted af en OCES CA, indeholder en URL til den CRL som certifikatet vil optræde på hvis det tilbagekaldes. Certificate Revocation Source (CRS) Boostrapping af CRA sker ved at angive et antal CRS er, der til sammen indeholder alle de CRL er der ønskes monitoreret i infrastrukturen. En CRS indeholder en eller to URL er til CRL er (en hvis der er tale om et OCES1 certifikat og 2 hvis det er et OCES2 certifikat) samt den certifikatkæde der knytter CRL erne til NSP/OCES 1.2 Algoritme For hver CRS som CRA er konfigureret med, hentes der en eller to CRL er som gemmes i databasen. CRA verificerer først at CRS en indeholder en valid OCES certifikatkæde og tjekker derefter om der er ændringer til CRL erne. CRL erne downloades, deres signatur verificeres og de tilbagekaldte serienumre gemmes i databasen. Hvis et af CA certifikaterne tilbagekaldes vil dette blive markeret i databasen således at alle certifikater, der peger på den tilhørende CRL, tilbagekaldes. 1.3 Logning CRA logger til filen cra.log 2 Installation 2.1 Kompilering CRA leveres gennem NSP s SVN systemet: svn co cra Efter checkout skal projektet bygges med Maven således: mvn install Følgende filer udgør nu leverancen og skal anvendes i resten af installationsvejledningen:

5 Certificate Revocation Authority 2 / 5 cra/target/cra-x.y.z.war cra/etc/cra/bootstrap.xml cra/etc/cra/config.xml cra/etc/cra/schedule.xml cra/etc/cra/seal.xml cra/etc/cra/services.xml cra/etc/cra-ds.xml cra/etc/drop-create-db.sql cra/etc/log4j-cra.xml cra/etc/log4j-nspslalog-cra.properties cra/etc/nspslalog-cra.properties 2.2 Konfiguration Inden CRA kan deployes skal konfigurationsfilerne kopieres over i biblioteket /pack/jboss8/standalone/configura tion. Følgende filer skal herefter findes: /pack/jboss8/standalone/configuration/cra/bootstrap.xml /pack/jboss8/standalone/configuration/cra/config.xml /pack/jboss8/standalone/configuration/cra/schedule.xml /pack/jboss8/standalone/configuration/cra/seal.xml /pack/jboss8/standalone/configuration/cra/services.xml /pack/jboss8/standalone/configuration/log4j-cra.xml /pack/jboss8/standalone/configuration/log4j-nspslalog-cra.properties /pack/jboss8/standalone/configuration/nspslalog-cra.properties XML filen /pack/jboss8/standalone/configuration/cra/bootstrap.xml indeholder et eksempel på en opsætning af et antal CRS er. Dette eksempel skal slettes og korrekte CRS er skal konfigureres inden selve applikationen deployes. En detaljeret gennemgang af filerne og opsætningen heri kan findes i afsnittet Opsætning. 2.3 Database Inden CRA kan deployes skal databasen og datasourcen sættes op. Filen drop-create-db.sql anvendes til at oprette databasen. Vær opmærksom på at filen erstatter en allerede eksisterende database med navnet cra. Filen cra-ds.xml skal placeres i /pack/jboss8/standalone/deployments/. Begge filer indeholder et simpelt brugernavn og kodeord for databasebrugeren og skal derfor rettes inden de anvendes i et produktionsmiljø. Vær også opmærksom på at værdien af connection property rewritebatchedstatements skal passe med den tilsvarende i services.xml som beskrevet nedenfor 2.4 Deployment Når alle konfigurationsfilerne er placeret korrekt og databasen er sat op kan filen cra-x.y.z.war kopieres over i /pack/ jboss8/standalone/deployments/. Konfigurationsfilen bootstrap.xml skal opdateres inden CRA deployes. 3 Opsætning Inden CRA kan deployes skal konfigurationsfilerne opdateres til at afspejle den del af certifikatinfrastrukturen man ønsker af monitorer. 3.1 schedule.xml Opdateringsintervallet for CRA defineres i filen schedule.xml. I leverancen er værdien sat til millisekunder, hvilket er 30 min. Hvis en anden værdi ønskes så er det attributten fixed-delay der skal opdateres.

6 Certificate Revocation Authority 3 / 5 <task:scheduled-tasks scheduler="scheduler"> <task:scheduled ref="certificaterevocationauthority" method="update" fixed-delay=" "/> </task:scheduled-tasks> <task:scheduler id="scheduler" pool-size="1"/> Vær opmærksom på at værdien af denne attribut har konsekvenser for værdien af konfigurationsparameteren ttl i SecurityValve og SecurityHandler. Se dokumentationen til disse tools for en udregning. 3.2 seal.xml Seal føderationen skal konfigureres alt efter om der er tale om et test eller et produktionsmiljø. Attributten class på feder ation elementet skal have værdien dk.sosi.seal.pki.sositestfederation i et testmiljæ og dk.sosi.seal. pki.sosifederation i et produktionsmiljø. Ydermere skal propertien sosi:issuer have en passende værdi alt efter miljø. 3.3 services.xml Heri skal propertien rewritebatchedstatements have samme værdi som den har i cra-ds.xml <bean id="certificaterevocationstoredatabase" class="dk.nsi.nsp.cra.db. DBCertificateRevocationStoreImpl" init-method="init"> <constructor-arg ref="cra.db"/> <property name="rewritebatchedstatements" value="true"/> </bean> 3.4 bootstrap.xml Heri defineres de CRS er der skal bruges til at bootstrappe CRA. For hver CRS der defineres vil CRA læse den konfigurerede CRL samt alle CRL er fra certifikaterne i certifikatkæden. Der er to måder at konfigurere en CRS. Enten vd at angive et slutbruger certifikat eller ved direkte at angive en url til en CRL og dens tilhørende certifikat Keystore CRS <bean id="testcertificaterevocationsource" class="dk.nsi.nsp.cra.bootstrap. KeyStoreCertificateRevocationSource"> <constructor-arg> <bean id="testkeystore" class="java.io.file"> <constructor-arg value="/pack/cra/cra-test.keystore" type="java.lang.string " /> </bean> </constructor-arg> <constructor-arg value="!234qwer" type="java.lang.string" /> <constructor-arg value="sosi:alias_system" type="java.lang.string" /> <constructor-arg ref="certificateresolver"/> </bean> Måden en KeyStoreCertificateRevocationSource konstrueres på, er ved at tage den offentlige del af et certifikat og gemme det i en Java Keystore fil. Filen, aliaset og kodeordet til filen (Ikke til den private nøgle) konfigureres derefter som de tre første constructor-arg s til en KeyStoreCertificateRevocationSource. Det sidste argument skal altid være certificateresolver For at aktivere en CRS tilføjes den til listen certificaterevocationsources. Java Keystore filer laves med programmet keytool der følger med Java. Der henvises til Java dokumentation for eksempler på hvordan man importerer et certifikat.

7 Certificate Revocation Authority 4 / Remote CRS <bean id="systemtest10certificaterevocationsource" class="dk.nsi.nsp.cra.bootstrap. RemoteCertificateRevocationSource"> <constructor-arg value=" " type="java.lang.string" /> <constructor-arg value=" type="java.lang.string" /> <constructor-arg ref="certificatestore"/> <constructor-arg ref="certificateresolver"/> </bean> Hvis man ikke har et certifikat udstedt af den CA man ønsker at tilføje kan en RemoteCertificateRevocationSource konstrueres ved at angive URL en til CA certificatet og URL en til den CRL der er signeret af CA en som de to første constru ctor-arg s. De to sidste argumenter skal altid være certificatestore og certificateresolver For at aktivere en CRS tilføjes den til listen certificaterevocationsources. 4 Databasen CRA har et relativt simpelt databaselayout bestående af to tabeller. En tabel med CRL endpoints og en tabel med revokerede certifikater. 4.1 Endpoints Tabellen crl har følgende felter: id url Teknisk identifikation af rækken - Allokeres automatisk af MySQL. Det endpoint hvor en CRL hentes fra. lastmodified Opdateres med et nyt timestamp hver gang CRL en downloades fra endpointet. nextupdate Det tidspunkt (timestamp) den sidst hentede version af CRL en er gyldig til. 4.2 Revokeringer Tabellen revoked har følgende felter: id Teknisk identifikation af rækken - Allokeres automatisk af MySQL. crlid Teknisk identifikation af den række fra tabellen crl som denne revokering kommer fra. serialnumber Serienummerer på det certifikat der er trukket tilbage. added Det tidspunkt (timestamp) rækken blev tilføjet til tabellen. since Det tidspunkt (timestamp) revokeringen trådte i kraft.

8 Certificate Revocation Authority 5 / 5 Hvis en CRL er udstedt af en CA og denne CA trækkes tilbage, så vil alle dens rækker i revoked blive slettet og en enkelt række med NULL i serialnumber vil blive oprettet. Et certifikat skal derfor betragtes som trukket tilbage hvis dets CRL enpoint findes i crl og dets serienummer findes i revoked eller der findes en række med serienummeret NULL.