Es handelt sich um eine professionelle PKI Lösung, die einem die Arbeit mit der Verwaltung einer Public Key Infrastructure (PKI) stark vereinfacht. Egal, ob das Unternehmen nur 5 Mitarbeiter hat oder es sich um einen Konzern mit 10000 Mitarbeitern handelt, die Lösung skaliert bei allen Unternehmensgrößen. Als übergeordnete CA kann man damit auch auch die Probleme mit Windows Zertifizierungsstellen in den Griff bekommen. In der Active Directory Domain muss nur das zuständige Root-CA Zertifikat verteilt werden.
EJBCA stellt auch einen OCSP Server bereit, so dass Revocation Lists leicht verwaltet werden können.
Die SOAP Schnittstelle lässt einen automatisierten Betrieb über beliebige Consumer zu, egal ob es sich um ein einfaches Perl Skript oder eine komplexe Tibco Lösung handelt.
Unter https://gitlab.com/ip6li/ejbca-docker gibt es ein Docker Template, mit dem EJBCA als Docker Container installiert werden kann. Die Installation mit MariaDB funktioniert nicht, es wird ausdrücklich Postgresql als Datenbank empfohlen.
Wer EJBCA im kommerziellen Umfeld nutzt und ein IT-Sicherheitsmanagement betreiben muss, sollte sich die Enterprise Version kaufen. Wer sich die Arbeit macht, seine private PKI und die Prozesse dazu nach den Regeln des CA/Browser Forums zu dokumentieren, hat bei der Wirtschaftprüfung (bei Banken obligatorisch) keine peinlichen Fragen zu erwarten. Das PKI Audit dauert dann u.U. keine 15 Minuten.
Neben Backups fallen bei EJBCA noch ein paar andere Wartungsarbeiten statt, die man am besten automatisiert.
Fangen wir mit dem Wichtigsten an, was bei eine PKI gemacht werden muss, die Datensicherung. Eine vollständige EJBCA Datensicherung besteht aus zwei Komponenten:
Damit das so einfach so funktioniert müssen wirklich alle Anpassungen an EJBCA im Verzeichnis ~/ejbca-custom erstellt werden. Nach der Installation von EJBCA sollte auch das Verzeichnis ~/ejbca/p12 nach ~/ejbca-custom kopiert werden. So wird sichergestellt, dass bei einem Desaster Recovery auch die privaten Schlüssel für die Administration mit kopiert werden.
Das ist eine der wenigen Stellen, die bei EJBCA bislang nicht so gut gelöst sind. Hier ist ein manueller Eingriff in die Wildfly Konfiguration erforderlich. Da Wildfly bei Basteleien an der Datasource gerne mal einen harten Crash hinlegt, sollte das EJBCA Deployment manuell entfernt werden. Dazu muss im Verzeichnis ~/wildfly/standalone/deployments die Datei ejbca.ear gelöscht werden. Am besten startet man danach Wildfly komplett neu und hat dann klare Verhältnisse. Da kommen etliche Fehlermeldungen der Klasse fatal oder error, die man hier erst einmal ignorieren kann.
wildfly/bin/jboss-cli.sh --connect data-source remove --name=ejbcads data-source add --name=ejbcads --driver-name="db-java-client.jar" \ --connection-url="jdbc:postgresql://sql:5432/ejbca" --jndi-name="java:/EjbcaDS" \ --use-ccm=true --driver-class="org.postgresql.Driver" --user-name="ejbca" \ --password="***" --validate-on-match=true --background-validation=false \ --prepared-statements-cache-size=50 --share-prepared-statements=true \ --min-pool-size=5 --max-pool-size=150 --pool-prefill=true \ --transaction-isolation=TRANSACTION_READ_COMMITTED \ --check-valid-connection-sql="select 1;"
Zunächst wird dabei die alte Datasource gelöscht und dann neu erstellt. Danach kann man wie in der EJBCA Installation beschrieben, EJBCA mit ant clean deployear EJBCA wieder deployen.