1.1.2 | 2016-01-01 | Initielt Dokument | Arosii |
1.1.3 | 2019-08-19 | Tilføjet oprydningsjob til schedule | KvalitetsIT |
1.1.4 | 2019-11-06 | Rettet kode efter QA | KvalitetsIT |
1.1.5 | 2020-01-07 | Rettet kode efter release issue | KvalitetsIT |
1.1.8 | 2020-06-29 | Containerization af CRA | KvalitetsIT |
1.1.9 | 2020-09-25 | Null pointer i forbindelse med oprydning | KvalitetsIT |
Release 1.1.10
Findings fundet ifm. brug af CRA på KIH rettet.
Der er også fundet en uhensigtsmæssighed ifm. et af oprydningsjobbene, cleanIfGhostSerialNumberActivated, som gør at dette oprydningsjob ikke bør aktiveres.
Ændringer til konfiguration:
I filen services.xml er rettet følgende. cleanIfGhostSerialNumberActivated er sat til false og checkDatabaseConnection er tilføjet:
<bean id="certificateRevocationCleanUp" class="dk.nsi.nsp.cra.CertificateRevocationCleanUpImpl"> <constructor-arg ref="certificateRevocationStoreDatabase"/> <constructor-arg ref="certificateRevocationSources"/> <constructor-arg ref="status"/> <!-- Activate cleanup functionality --> <property name="cleanActivated" value="true" /> <property name="cleanIfRootExpiredActivated" value="true" /> <property name="cleanIfIntermediateExpiredActivated" value="true" /> <property name="cleanIfGhostUrlActivated" value="true" /> <!-- Sat til false, da den bruger al CPU hvis aktiveret --> <property name="cleanIfGhostSerialNumberActivated" value="false" /> <!-- Tilføjet i forbindelse med KIH rettelserne --> <property name="checkDatabaseConnection" value="true" /> </bean> |
CRA er blevet opdelt i maven-moduler.
Rettet følgende:
<bean id="certificateRevocationStoreDatabase" class="dk.nsi.nsp.cra.db.DBCertificateRevocationStoreImpl" init-method="init"> <constructor-arg ref="cra.db"/> <property name="rewriteBatchedStatements" value="true"/> <property name="cleanupSerialNumbersBatchSize" value="500"/> <property name="initialWaitForDatabaseConnection" value="20000"/> <property name="retriesWhenDatabaseConnectionFail" value="6"/> <property name="waitBetweenDatabaseConnectionRetries" value="5000"/> </bean> |
<task:scheduled-tasks scheduler="scheduler"> <!-- Execute dk.nsi.nsp.cra.CertificateRevocationAuthorityImpl.update --> <!-- initial-delay: milliseconds until first run (1 minutes)--> <!-- fixed-delay: 30 minutes--> <task:scheduled ref="certificateRevocationAuthority" method="update" initial-delay="60000" fixed-delay="1800000"/> <!-- Execute dk.nsi.nsp.cra.CertificateRevocationCleanUpImpl.cleanup --> <!-- initial-delay: milliseconds until first run (2 minutes)--> <!-- fixed-delay: milliseconds until next run from completion of previous run (1 min)--> <task:scheduled ref="certificateRevocationCleanUp" method="cleanup" initial-delay="120000" fixed-delay="60000"/> </task:scheduled-tasks> |
Tilføjet følgende:
<property name="cleanupSerialNumbersBatchSize" value="500"/>
til certificateRevocationStoreDatabase-bean i services.xml.
Leverancen er tagget som release-1.1.5.
Rettelse af kode efter finding ved release.
Parameter til aktivering af oprydning af udløbet rod-certifikat var ikke stavet ens i opsætning og i koden. Ændret værdien fra "cleanIfRootExpiredActivate" til "cleanIfRootExpiredActivated" i koden.
Leverancen er tagget som release-1.1.4.
Rettelse af kode efter QA findings:
Leverancen er tagget som release-1.1.3.
Følgende JIRA sager indgår i leverancen.
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.
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.
CRA logger til filen cra.log
Der ryddes ud løbende i historikken af revokerede certifikater, som findes i en given spærreliste, og hvis de ikke længere fremgår, så fjernes de.
Oprydning kan aktiveres vha. af værdien cleanActivated på certificateRevocationAuthority (Se schedule.xml)
Der er oprettet 4 forskellige oprydninger, som kan aktiveres og vil blive udført, hvis cleanActivated er aktiveret:
Kildekoden til CRA kan hentes gennem NSPs SVN:
https://svn.nspop.dk/svn/components/cra
CRA fra version 1.1.8 blevet omlagt til at kunne afvikles vha. docker-compose. Derfor er CRA blevet opdelt i følgende maven moduler:
CRA leveres gennem NSP’s SVN systemet:
svn co https://svn.nspop.dk/svn/components/cra/release-x.y.z cra |
Efter checkout skal projektet bygges med Maven således:
mvn install |
Følgende filer udgør nu leverancen og anvendes i resten af installationsvejledningen:
cra/cra-app/target/cra.war compose/configuration/cra/bootstrap.xml compose/configuration/cra/config.xml compose/configuration/cra/schedule.xml compose/configuration/cra/seal.xml compose/configuration/cra/services.xml compose/configuration/cra-ds.xml compose/configuration/database/drop-create-db.sql compose/configuration/log4j-cra.xml compose/configuration/log4j-nspslalog-cra.properties compose/configuration/nspslalog-cra.properties |
Deployment udføre vha. docker-compose. Der findes 3 udgaver til deployement - development, test og release.
Opsætningen af cra- og cradb-servicen er beskrvet i efterfølgende afsnit.
Et eksempel på deployment vha. docker-compos:
docker-compose -f compose/development/docker-compose.yml up --build |
Ved at angive --build, så bygges der docker images ud fra de Dockerfile-filer findes i de moduler, der skal bygges.
For alle 3 deployment er CRA servicen sat op, så følgende konfigurationsfiler kopieres til /pack/wildfly8/standalone/configuration:
compose/configuration/cra/bootstrap.xml compose/configuration/cra/config.xml compose/configuration/cra/schedule.xml compose/configuration/cra/seal.xml compose/configuration/cra/services.xml |
compose/configuration/log4j-cra.xml compose/configuration/log4j-nspslalog-cra.properties compose/configuration/nspslalog-cra.properties |
XML filen 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.
Under deployment vha. docker-compose, så bliver filen cra-ds.xml placeret i /pack/wildfly8/standalone/deployments.
CRA-databasen bliver bygget under deployment - eller et image af bygget biver hentet fra repo. Opskriften på byg af cradb findesi filen Dockerfile under cra-db modulet.
Det image som bygges til cradb basere sig på 'mariadb:10.1' og indeholder 2 sql-filer:
Både cra-ds.xml og drop-create-db.sql 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
Samtidigt med at alle konfigurationsfilerne er placeres korrekt og databasen er startes op kan, så bygges cra-app modulet.
I cra-app kopieres filen target/cra.war kopieres over i /pack/wildfly8/standalone/deployments/.
Konfigurationsfilen bootstrap.xml skal opdateres inden CRA deployes.
Inden CRA kan deployes skal konfigurationsfilerne opdateres til at afspejle den del af certifikatinfrastrukturen man ønsker af monitorer.
Opdaterings- og oprydningsintervallet for CRA defineres i filen schedule.xml.
I leverancen er værdien for opdatering sat til 1800000 millisekunder, hvilket er 30 min. Hvis en anden værdi ønskes så er det attributten fixed-delay der skal opdateres.
Der er også indført en initiel-delay på 60000 (1 min) millisekunder, så databasen kan nå at blive tilgængelig under opstart før cra-servicen prøver at tilgå den.
I leverancen er værdien for oprydning sat til at starte 120000 (2 minutter) millisekunder efter applikationen er startet og derefter scheduleres oprydningen til 60000 millisekunder (1 minut).
<task:scheduled-tasks scheduler="scheduler"> <!-- Execute dk.nsi.nsp.cra.CertificateRevocationAuthorityImpl.update --> <!-- initial-delay: milliseconds until first run (1 minutes)--> <!-- fixed-delay: 30 minutes--> <task:scheduled ref="certificateRevocationAuthority" method="update" initial-delay="60000" fixed-delay="1800000"/> <!-- Execute dk.nsi.nsp.cra.CertificateRevocationCleanUpImpl.cleanup --> <!-- initial-delay: milliseconds until first run (2 minutes)--> <!-- fixed-delay: milliseconds until next run from completion of previous run (1 min)--> <task:scheduled ref="certificateRevocationCleanUp" method="cleanup" initial-delay="120000" fixed-delay="60000"/> </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.
Seal føderationen skal konfigureres alt efter om der er tale om et test eller et produktionsmiljø. Attributten class på federation elementet skal have værdien dk.sosi.seal.pki.SOSITestFederation i et testmiljøcertificateRevocationAuthority og dk.sosi.seal.pki.SOSIFederation i et produktionsmiljø. Ydermere skal propertien sosi:issuer have en passende værdi alt efter miljø.
Heri skal propertien rewriteBatchedStatements have samme værdi som den har i cra-ds.xml
Fra version 1.1.8 er der desuden indført følgende parametre til sikre en forbindelse til databasen:
Så med disse værdier, så afventer certificateRevocationStoreDatabase 20 sekunder inden den forsøger at få forbindelse til databasen første gang. Hvis det fejler, så ventes der 5 sekunder inden der forsøges igen.
Ved 7. fejl så smides der en exception.
<bean id="certificateRevocationStoreDatabase" class="dk.nsi.nsp.cra.db.DBCertificateRevocationStoreImpl" init-method="init"> <constructor-arg ref="cra.db"/> <property name="rewriteBatchedStatements" value="true"/> <property name="cleanupSerialNumbersBatchSize" value="500"/> <property name="initialWaitForDatabaseConnection" value="20000"/> <property name="retriesWhenDatabaseConnectionFail" value="6"/> <property name="waitBetweenDatabaseConnectionRetries" value="5000"/> </bean> |
Opsætning af certificateRevocationAuthority til brug ifm. schedulering af opdatering.
<bean id="certificateRevocationAuthority" class="dk.nsi.nsp.cra.CertificateRevocationAuthorityImpl"> <constructor-arg ref="certificateRevocationStoreDatabase"/> <constructor-arg ref="certificateRevocationSources"/> <constructor-arg ref="status"/> <constructor-arg ref="federation"/> <property name="revocationBatchSize" value="20000"/> </bean> |
Opsætning af certificateRevocationCleanUp til brug ifm. schedulering af oprydning.
<bean id="certificateRevocationCleanUp" class="dk.nsi.nsp.cra.CertificateRevocationCleanUpImpl"> <constructor-arg ref="certificateRevocationStoreDatabase"/> <constructor-arg ref="certificateRevocationSources"/> <constructor-arg ref="status"/> <!-- Activate cleanup functionality --> <property name="cleanActivated" value="true" /> <property name="cleanIfRootExpiredActivated" value="true" /> <property name="cleanIfIntermediateExpiredActivated" value="true" /> <property name="cleanIfGhostUrlActivated" value="true" /> <property name="cleanIfGhostSerialNumberActivated" value="true" /> </bean> |
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.
<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.
<bean id="systemtest10CertificateRevocationSource" class="dk.nsi.nsp.cra.bootstrap.RemoteCertificateRevocationSource"> <constructor-arg value="http://m.aia.systemtest10.trust2408.com/systemtest10-ca.cer" type="java.lang.String" /> <constructor-arg value="http://crl.systemtest10.trust2408.com/systemtest10.crl" 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 constructor-arg's. De to sidste argumenter skal altid være certificateStore og certificateResolver
For at aktivere en CRS tilføjes den til listen certificateRevocationSources.
CRA har et relativt simpelt databaselayout bestående af to tabeller. En tabel med CRL endpoints og en tabel med revokerede certifikater.
Tabellen crl har følgende felter:
Tabellen revoked har følgende felter:
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.
Når CRA servicen skal hente crl filer, så kalder sender den et http request. Det er dog ikke altid at disse services der udstiller CRL filerne er tilgængelige.
For at undgå afhængigheder til andre services, så er det nu muligt at placere CRL filer i modulet cra-crl-stub.
For at CRA servicen sender sit request til stubben, så skal følgende gøres:
I docker-compose tilføjes crl.XYZ.com som alias
crl-stub: networks: cra_net: aliases: - crl.XYZ.com |