...

Release

Release 1.1.

...

8

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>

Release 1.1.7

Release 1.1.6

Tilføjet følgende:
<property name="cleanupSerialNumbersBatchSize" value="500"/>

til certificateRevocationStoreDatabase-bean i services.xml.

Release 1.1.5

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.

Release 1.1.4

Leverancen er tagget som release-1.1.4.

Rettelse af kode efter QA findings:

• Status opdateres ved alle fejl
• Fjernet udkommenteret kode.
• Flyttet kode fra CertificateRevocationAuthorityImpl ud til oprydning ud i egen klasse CertificateRevocationCleanUpImpl.
• Ændret struktur i oprydningskoden, så retur-værdier sendes vha. ny klasse CertificateRevocationCleanUpData.

Release 1.1.3

Leverancen er tagget som release-1.1.3.

Følgende JIRA sager indgår i leverancen.

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.

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

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.

Logning

CRA logger til filen cra.log

Oprydning

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:

• cleanIfRootExpiredActivated
  Hvis et rodcertifikatet fra certificateRevocationSources (Se bootstap.xml) er udløbet, så findes id fra crl tabellen vha. certifikatets url (Se Endpoints), og bruges til at slette rækker fra revoked vha. crlid (Se Revokeringer).
  Hvis der er et tilhørende intermediatecertifikat, så slettes det også på samme måde, som for rodcertifikatet.
• cleanIfIntermediateExpiredActivated
  Hvis ikke rodcertifikatet er udløbet, så checkes det om intermediatecertifikat er udløbet. Hvis det er udløbet, så slettes det på samme måde, som beskrevet for rodcertifikat.
• cleanIfGhostUrlActivated
  Hvis ikke rod- eller intermediatecertifikatet er expired. Så finder vi alle aktive url'er (både for rod- og intermediatecertifikater) fra certificateRevocationSources (Se Endpoints). Oplysninger tilknyttet certifikater som findes i cachen, men som ikke er aktive, slettes fra crl og revoked tabellen.
• cleanIfGhostSerialNumberActivated
  Hvis ikke rod- eller intermediatecertifikatet er expired. Hvis listen af revoked serialnumber (Se Revokeringer) indeholder værdier, der ikke kan findes i  den aktive liste af serialnumbers, så slettes de fra databasen.

Installation

Kildekode

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-app: Indeholder logik for opdaterings- og oprydningsjob. Desuden er der filer til at bygge cra.war filen. Det er basalt set de filer, der før var indeholdt i cra-projektet inden dockerfisering.
• cra-db: De filer der bruges til at bygge 'cradb'. Før har dette ligget udenfor CRA modulet.
• cra-crl-stub: Løsning  der udstiller en servlet, hvor man kan hente CRL-filer. Hvis ikke man inkludere cra-crl-stub i docker-compose, så hentes CRL på www.
• cra-qa: Her samles test-rapporter (jacoco) fra andre moduler og aggregeres.
• cra-parent:  Rod modulet til ovenstående moduler. Indeholder desuden compose folder, hvor docker-compose-, konfigurations- og databasefiler er placeret.

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.

Release 1.1.4

Leverancen er tagget som release-1.1.4.

Rettelse af kode efter QA findings:

• Status opdateres ved alle fejl
• Fjernet udkommenteret kode.
• Flyttet kode fra CertificateRevocationAuthorityImpl ud til oprydning ud i egen klasse CertificateRevocationCleanUpImpl.
• Ændret struktur i oprydningskoden, så retur-værdier sendes vha. ny klasse CertificateRevocationCleanUpData.

Release 1.1.3

Leverancen er tagget som release-1.1.3.

Følgende JIRA sager indgår i leverancen.

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.

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

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.

Logning

CRA logger til filen cra.log

Oprydning

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:

• cleanIfRootExpiredActivated
  Hvis et rodcertifikatet fra certificateRevocationSources (Se bootstap.xml) er udløbet, så findes id fra crl tabellen vha. certifikatets url (Se Endpoints), og bruges til at slette rækker fra revoked vha. crlid (Se Revokeringer).
  Hvis der er et tilhørende intermediatecertifikat, så slettes det også på samme måde, som for rodcertifikatet.
• cleanIfIntermediateExpiredActivated
  Hvis ikke rodcertifikatet er udløbet, så checkes det om intermediatecertifikat er udløbet. Hvis det er udløbet, så slettes det på samme måde, som beskrevet for rodcertifikat.
• cleanIfGhostUrlActivated
  Hvis ikke rod- eller intermediatecertifikatet er expired. Så finder vi alle aktive url'er (både for rod- og intermediatecertifikater) fra certificateRevocationSources (Se Endpoints). Oplysninger tilknyttet certifikater som findes i cachen, men som ikke er aktive, slettes fra crl og revoked tabellen.
• cleanIfGhostSerialNumberActivated
  Hvis ikke rod- eller intermediatecertifikatet er expired. Hvis listen af revoked serialnumber (Se Revokeringer) indeholder værdier, der ikke kan findes i  den aktive liste af serialnumbers, så slettes de fra databasen.

...

Kompilering

CRA leveres gennem NSP’s SVN systemet:

...