StrongSwan: Die Zertifikatsverwaltung aufbauen
Warum Zertifikate?
Dies ist eine berechtigte Frage, da man sehr wohl argumentieren könnte, daß ein
Schlüssel zur Absicherung einer IPsec-Verbindung ausreichen sollte, um etwaige
Störenfriede draußen zu halten, damit also ein ähnliches Verfahren wie in einem
WLAN zum Einsatz kommt. Dieses Verfahren hätte natürlich einige Vorteile, da
man sich so nur den Schlüssel merken muß und man kein Zertifikat hat, das einem
ablaufen kann.
Allerdings hat die Sache einen entscheidenden Haken: Wer auch immer in den
Besitz eines solchen Schlüssels gerät, hat damit automatisch Zugang zu einer so
abgesicherten IPsec-Verbindung, was eine Änderung des Schlüssels erforderlich
macht – doch je größer ein IPsec-Verbund ist, umso aufwendiger wird es, alle
Stationen mit dem neuen Schlüssel zu versehen. Zudem kann man schnell eine der
Stationen vergessen, welche sich so ausgesperrt wiederfindet.
Zudem läßt sich nur mit einem Sicherungsschlüssel die Identität einer Station
nicht eineindeutig feststellen, und auch wenn man diesen zum Verschlüsseln
verwendet, so ist eine sichere Verschlüsselung auf diesem Wege nur mit einigem
Mehraufwand möglich.
Um genau diese Probleme zu umgehen, kommen Zertifikate ins Spiel. Diese bringen nicht nur einen zur Verschlüsselung notwendigen Schlüssel mit, sondern enthalten gleichzeitig auch eine Kennung für den Teilnehmer, dem das Zertifikat zugeteilt ist, sowie einen Zeitraum, in dem das Zertifikat gültig ist, und eine Kennung, die das Zertifikat identifiziert. Zudem ist es jederzeit möglich, ein einmal ausgestelltes Zertifikat zurückzuziehen, wodurch es nicht mehr eingesetzt werden kann: Das wäre genau so, als wäre das Zertifikat bereits abgelaufen. Somit kann man den Mißbrauch deutlich eindämmen und zudem drastisch erschweren.
nach obenKaufen oder nicht?
Die Antwort auf diese Frage hängt entscheidend davon ab, zu welchem Zweck Sie
IPsec-Verbindungen aufbauen wollen. Dient es einfach nur dazu, sich mit Ihrem
Server zu verbinden, so können Sie sich den Umstand und die Kosten einfach
sparen und stattdessen Ihr eigenes Zertifikat verwenden. Dies versieht seinen
Dienst i. d. R. genauso gut wie ein käuflich Erworbenes.
Die Sache sieht etwas anders aus, wenn Sie IPsec-Verbindungen gewerblich
anbieten wollen, beispielsweise indem Sie Ihren Server als Vermittlungsstelle
zwischen den Rechnern Ihrer Kunden einsetzen. Hier empfiehlt sich eher ein
käuflich erworbenes Zertifikat, da hier eine Zertifizierungsstelle Ihre Domain
- und ggf. auch Ihre Identität – überprüft und bestätigt. Zudem verfügt eine
ausgewiesene Zertifizierungsstelle über Möglichkeiten, kompromittierte
Zertifikate schnell zu sperren, so daß niemand Unfug damit anstellen kann; dies
ist insbesondere für Gewerbetreibende wichtig.
Eine eigene Zertifizierungsstelle einrichten
Wenn Sie den Weg einschlagen wollen, Ihr eigenes Zertifikat zu verwenden, so
sind hier zunächst einmal einige Handgriffe Ihrerseits vonnöten. Dazu bauen Sie
zunächst einmal Ihre eigene Zertifizierungsstelle auf, so daß Sie nach eigenem
Ermessen Zertifikate ausstellen und bei Bedarf auch wieder zurückziehen können.
Zudem ist für ein Zertifikat, damit ihm überhaupt vertraut werden kann, eine
digitale „Unterschrift“ vonnöten, mit der Sie die Echtheit des Zertifikats
bestätigen. Zertifikaten ohne diese Unterschrift wird i. d. R. nicht vertraut,
und StrongSwan wird in diesem Fall die Mitarbeit verweigern und das Zertifikat
schlichtweg zurückweisen.
Allerdings ist es zwingend erforderlich, daß diese Unterschriftengrundlage
ausschließlich in Ihrem Besitz verbleibt, damit niemand unter Ihrem Namen
irgendwelche Zertifikate ausstellen und sich somit Zugang zu Ihren
IPsec-Verbindungen verschaffen kann.
Damit Sie überhaupt anfangen können, legen Sie zunächst einmal ein Verzeichnis an, das nur für die Zertifizierungsstelle Verwendung findet, in dem sich also nichts anderes befindet, und setzen Sie die Zugriffsrechte so, daß kein Fremder Zugang dorthin hat (dies ist insbes. für Rechner relevant, auf die mehrere Personen Zugriff haben), am besten sogar im Homeverzeichnis von root. Dies stellt sicher, daß einzig Sie als Systemverwalter Zugriff auf die Daten, die zu Ihrer Zertifizierungsstelle gehören, bekommen.
Die folgenden Anleitungen sind von dieser Originalanleitung bei strongswan.org abgeleitet worden und tragen dem Problem Rechnung, daß Algorithmen wie SHA1 und MD5 mittlerweile als nicht mehr sicher gelten. Zudem ist ein längerer Schlüssel ebenfalls von Vorteil.
nach obenDas Wurzelzertifikat
Zu Anfang ist es erfordelich, daß Sie ein Wurzelzertifikat erzeugen, auf dem Sie Ihren gesamten Zertifikatbaum aufbauen. Dies läuft in zwei Schritten ab und erfordert, daß Sie zunächst einmal einen Schlüssel erzeugen.
- Öffnen Sie eine Textkonsole und melden Sie sich als root an.
- Wechseln Sie in das Arbeitsverzeichnis Ihrer Zertifizierungsstelle.
- Führen Sie folgenden Befehl aus: ipsec pki --gen --size 4096 > cakey.der
- Führen Sie direkt im Anschluß folgenden Befehl aus: ipsec pki --self --in cakey.der --dn "C=DE, O=<your_org>, CN=<your_org> CA" --lifetime 10950 --digest sha256 --ca > cacert.der
Dies legt zunächst einmal einen RSA-Schlüssel mit 4096 Bit Länge an. Dieser ist die Identifikation Ihrer Zertifizierungsstelle: Geben Sie ihn niemals aus der Hand, und legen Sie ihn unter gar keinen Umständen auf Ihrem Server ab! Für die Wurzel Ihres Zertifikatbaumes brauchen Sie lediglich das Wurzelzertifikat, damit die Gültigkeit der Endzertifikate einwandfrei festgestellt werden kann, insofern besteht gar nicht die Notwendigkeit, diesen Schlüssel auf Ihren Server zu kopieren.
Im zweiten Schritt erzeugen Sie aus Ihrem Schlüssel ein Zertifikat. Dazu muß
der Schlüssel, den Sie zuvor erzeugt haben, eingelesen werden. Zudem ist es
erforderlich, daß Sie noch ein paar Daten angeben, die die Gültigkeit und die
Sicherheit Ihres Zertifikates beeinflussen.
Da Sie das Wurzelzertifikat nur auf Ihrem Server einsetzen und es i. d. R. auch
nicht aus der Hand geben, setzen Sie die Gültigkeitsdauer einfach auf einen
hohen Wert (hier sind es knapp dreißig Jahre, die Sie sich um die Erneuerung
des Wurzelzertifikats keine Gedanken machen müssen) und geben Sie als
Signaturalgorithmus einen stärkeren Algorithmus als SHA1 oder MD5 an, da diese
beiden mittlerweile zu einfach zu knacken sind. Dann müssen Sie die
Identifikation, die vom Zertifikat bereitgestellt wird, an Ihre Gegebenheiten
anpassen. Setzen Sie dazu für C den zweibuchstabigen
Code Ihres Landes ein (hier ist es DE für Deutschland) und für
O den Namen Ihrer Organisation. Gleiches tun Sie für
den allgemeinen Namen (CN) der Entität, für die Sie
das Zertifikat ausstellen. Ferner müssen Sie das Wurzelzertifikat selbst
signieren, damit es gültig wird und somit seine Aufgabe als Ausgangspunkt für
weitere Zertifikate übernehmen kann.
Das so erstellte Wurzelzertifikat kopieren Sie auf Ihrem Server in das
Verzeichnis /etc/ipsec.d/cacerts/.
Damit sind Sie jetzt für den nächsten Schritt gesetzt. Bei Bedarf können Sie jedoch noch weitere Zertifikatsebenen dazwischenschieben, je nachdem, wie Ihre IPsec-Infrastruktur es erfordert. Bei vielen Unterabteilungen (die Sie übrigens mit OU ebenfalls in der Identifikation angeben können) empfiehlt sich eine, wenn nicht gar zwei, Zwischenebenen, die Sie ggf. einzelnen Abteilungen und Unterabteilungen zuweisen und mit denen letztlich die Endzertifikate signiert werden.
nach obenOptional: Zwischenzertifikate
Hierbei handelt es sich ebenfalls um zeichnungsberechtigte Zertifikate, die jedoch nicht am Wurzelknoten des Zertifikatbaums liegen, sondern deren Gültigkeit durch das Wurzelzertifikat bestätigt wird. Dazu geben Sie nacheinander die folgenden Befehle an:
- ipsec pki --gen --size 4096 > intermediate-key.der
- ipsec pki --pub --in intermediate-key.der | ipsec pki --issue --cacert cacert.der --cakey cakey.der --dn "C=DE, O=<your_org>, CN=<your_org> sub CA" --digest sha256 --lifetime 3650 --ca > intermediate-cert.der
+++ WARNUNG +++ WARNUNG +++ WARNUNG +++ WARNUNG +++ WARNUNG +++
Verwenden Sie niemals denselben Schlüssel für mehrere
Zertifikate! Sollte Ihnen der Schlüssel jemals abhanden kommen, so sind
schlagartig sämtliche daraus erzeugten Zertifikate kompromittiert und müssen
neu erstellt werden, was für Sie einen entsprechend größeren Aufwand bedeutet!
Ansonsten kann immer nur ein Zertifikat zur Zeit kompromittiert werden, was es
Ihnen erlaubt, dieses zurückzuziehen und einfach neu auszustellen, wodurch sich
der Aufwand in Grenzen hält. Sollte so eines der Zwischenzertifikate
kompromittiert werden, so ist i. d. R. nur eine kleine Gruppe betroffen, für
die Sie die Zertifikate im Normalfalle recht schnell neu ausgeben können.
Deutlich übler sieht es jedoch aus, wenn der Schlüssel für das Wurzelzertifikat
entwendet wird, da so der gesamte Zertifikatsbaum nicht mehr sicher ist. In
diesem Fall bleibt nur noch, alle Zertifikate, angefangen beim Wurzelzertifikat
über die Zwischenzertifikate bis hin zu den Endzertifikaten, komplett
auszutauschen, um es einem Angreifer unmöglich zu machen, eine unerwünschte
IPsec-Verbindung herzustellen! Belassen Sie die Schlüssel für die Zertifikate,
die Sie zum Unterzeichnen anderer Zertifikate einsetzen, daher immer an einem
sicheren Ort!
Haben Sie das Zwischenzertifikat erzeugt (was ähnlich abläuft wie beim
Wurzelzertifikat; der einzige Unterschied besteht darin, daß Sie hier das
Wurzelzertifikat und den zugehörigen Schlüssel benötigen, um dieses Zertifikat
zu signieren), so können Sie entweder noch weitere Unterebenen erzeugen, was
wiederum abläuft wie hier beschrieben, nur daß Sie dann das bereits erzeugte
Zwischenzertifikat verwenden müssen, um die nächst niedrigere Ebene zu
signieren, oder aber Sie erzeugen jetzt die Endzertifikate für die einzelnen
Teilnehmer in dem geplanten IPsec-Verbund.
Kopieren Sie diese Zwischenzertifikate anschließend ebenfalls nach
/etc/ipsec.d/cacerts/. Zudem können Sie die
Zwischenzertifikate nebst zugehöriger Schlüssel an andere Personen, die für die
jeweiligen Abteilungen zuständig sind, weitergeben, damit diese ihrerseits
Endzertifikate ausstellen können, ohne auf Sie zurückkommen zu müssen – aber
für den Fall des Falles, sprich in einer Abteilung, für die Sie ein
Zwischenzertifikat ausgestellt haben, läuft irgendetwas schief, können Sie alle
dort ausgestellten Zertifikate für ungültig erklären, indem Sie das
Zwischenzertifikat zurückziehen, ohne daß Sie auch nur eines der ausgestellten
Endzertifikate anfassen müßten.
Hinweis: Schachteln Sie nicht zuviele Ebenen zwischen das Wurzel- und die Endzertifikate! Erstens wird der Verbindungsaufbau mit jeder zusätzlichen Ebene nur unnötig weiter hinausgezögert, und zweitens verzetteln Sie sich umso eher, je mehr Ebenen und Verzweigungen Sie verwalten müssen! Weniger ist in dem Fall dann mehr, und es ist immer besser, den Zertifikatbaum so kompakt wie möglich zu gestalten und nur die Zwischenebenen einzuziehen, die unabdingbar erforderlich sind. Normalerweise werden mehr als zwei Ebenen ohnehin nicht erforderlich sein, und im Regelfalle werden Sie eher mit einer Zwischenebene auskommen.
nach obenDas Serverzertifikat
An ein Zertifikat, das Sie auf einem Server installieren wollen, sind natürlich einige strenge Anforderungen zu richten, damit dessen Echtheit bestätigt werden kann. Dazu ist es notwendig, daß die Identifikation einem Server eineindeutig zugeordnet werden kann, d. h. daß der Server nicht mehrere Zertifikate zugewiesen bekommt und daß jedes Zertifikat nicht auf mehreren Servern zum Einsatz kommt. Sollte sich wider Erwarten ein Bruch der Sicherheitsmaßnahmen für einen Server ergeben, so läßt sich das betroffene Zertifikat zurückziehen und erneut ausstellen, ohne daß es die anderen Server im IPsec-Verbund betrifft. So legt man sich nicht komplett lahm, und ein Angreifer kann schlimmstenfalls auf einem einzigen Server Schaden anrichten. Die anderen Server bleiben davon vollkommen unberührt.
Auch bei diesem Zertifikat ist wiederum ein zweistufiges Vorgehen erforderlich;
der Unterschied zu einem Zwischenzertifikat ist jedoch, daß dieses nicht dazu
herangezogen werden kann, um weitere Unterzertifikate auszustellen.
Gehen Sie dazu wie folgt vor:
- ipsec pki --gen --size 4096 > serverkey.der
- ipsec pki --pub --in serverkey.der | ipsec pki --issue --cacert cacert.der --cakey cakey.der --dn "C=DE, O=<your_org>, CN=<your_org entity>" --digest sha256 --lifetime 730 > servercert.der
In diesem Beispiel wird das Serverzertifikat direkt vom Wurzelzertifikat
signiert. Der Vorteil dieses Verfahrens ist, daß Sie so eine sehr flache
Baumstruktur erhalten. Der Nachteil ist jedoch, daß, wenn Sie das
Wurzelzertifikat sperren müssen, sämtliche Zertifikate nicht mehr zu gebrauchen
sind und erneuert werden müssen!
Arbeiten Sie mit einer Zwischenebene, so brauchen Sie nicht gleich das
Wurzelzertifikat auszutauschen, sondern es reicht, wenn Sie das
Zwischenzertifikat des betroffenen Teilbaumes zurückziehen, um einem Problem
zu begegnen. Der Rest bleibt so aktiv und kann über IPsec weiterarbeiten.
Wenn Sie Zwischenzertifikate verwenden, so müssen Sie statt
cacert.der und cakey.der
eben die Dateinamen des betreffenden Zertifikates bzw. Schlüssels angeben, um
das Endzertifikat damit zu erstellen. Das Verfahren ist ansonsten in beiden
Fällen identisch.
Sowie Sie das Serverzertifikat erzeugt haben, legen Sie es auf Ihrem Server unter /etc/ipsec.d/certs/ ab und kopieren Sie den Schlüssel für den Server nach /etc/ipsec.d/private/. Damit wären alle notwendigen Zertifikate bereits auf dem Server installiert.
nach obenDas Nutzerzertifikat
Ein Nutzerzertifikat wird letztlich auf dem gleichen Wege angelegt wie ein
Serverzertifikat auch, nur daß Sie hier zusätzlich noch einen alternativen
Namen angeben sollten, der eine Überprüfung der Identität vereinfacht. Nicht
nur können Sie sich die Angabe der kompletten Identifikation ersparen, sondern
Sie können, wenn Sie Verbindungen serverseitig einrichten, mit Platzhaltern
arbeiten und können so einer ganzen Personengruppe mit einer einzigen
Verbindungsdefinition Zugang gewähren – natürlich immer vorausgesetzt, daß
diese ein gültiges Zertifikat für Ihre IPsec-Verbindungen vorweisen können.
Dazu ist es trotzdem empfehlenswert, auch noch den Nutzernamen und das
zugehörige Passwort abzufragen. Somit hat jemand, der ein Endzertifikat nebst
zugehörigem Schlüssel abgreift, nicht zwangsläufig gewonnen, sondern muß erst
eine weitere Hürde überwinden, um eine IPsec-Verbindung aufbauen zu können. Nur
bis dahin dürfte das fragliche Zertifikat bereits gesperrt sein.
Führen Sie zur Erzeugung eines Nutzerzertifikates folgende Befehle aus:
- ipsec pki --gen --size 4096 > userkey.der
- ipsec pki --pub --in userkey.der | ipsec pki --issue --cacert cacert.der --cakey cakey.der --dn "C=DE, O=<your_org>, CN=<userid>" --san <userid> --digest sha256 --lifetime 730 > usercert.der
Wie Sie feststellen, wurde ein alternativer Name angegeben, den Sie statt der
vollständigen Identifikation zur Identitätsfeststellung heranziehen können.
Meistens handelt es sich bei einem alternativen Namen um eine Nutzerkennung in
Form von <Nutzername>@<Entität>, einer E-Mail-Adresse, o. ä.
Diese Kennung muß deckungsgleich mit der Nutzerkennung sein, die Sie für eine
Anmeldung am IPsec-Gateway verwenden, sonst beschwert sich StrongSwan, und die
Verbindung kommt nicht zustande.
Um dieses Zertifikat zu verwenden, installieren Sie es
auf Ihrem persönlichen Rechner im Verzeichnis
/etc/ipsec.d/certs/ und den zugehörigen Schlüssel
im Verzeichnis /etc/ipsec.d/private/.
Das Wurzel- sowie etwaige Zwischenzertifikate brauchen Sie nicht zu
installieren, da die Vertrauenskette zwischen den einzelnen Zertifikaten
serverseitig überprüft wird. Zudem wäre es auch mit einem Wurzel- oder
Zwischenzertifikat möglich, sich Zugang zu Ihrem IPsec-Verbund zu verschaffen,
weshalb es generell keine gute Idee ist, diese aus der Hand zu geben, außer es
erweist sich als absolut notwendig.
Zertifikate zurückziehen
Ab und an kann es erforderlich sein, ein ausgestelltes und an sich noch
gültiges Zertifikat zurückzuziehen, sei es, daß es der betreffenden Person
abhanden gekommen ist oder samt zugehörigem Schlüssel gestohlen wurde, sei es,
daß sich betreffende Person dauerhaft aus Ihrem IPsec-Verbund abmelden möchte
oder weshalb auch immer. In diesem Fall ist es notwendig, daß Sie das
betreffende Zertifikat zurückziehen, so daß es nicht mehr verwendet werden
kann, auch wenn es noch nicht abgelaufen ist. Falls Sie ein Zertifikat sperren
müssen, führen Sie folgenden Befehl aus (beachten Sie bitte, daß Ihnen das
fragliche Zertifikat zur Verfügung stehen muß, damit Sie es sperren können!):
ipsec pki --signcrl --cacert cacert.der --cakey cakey.der
--reason <reason> --cert usercert.der > crl.der
Als Grund können Sie folgende Werte angeben:
Sperrgrund | Bedeutung |
---|---|
key-compromise | Der dem Zertifikat zugrundeliegende Schlüssel wurde entwendet oder geknackt. Die betroffene Verbindung ist nicht mehr sicher. |
ca-compromise | Die Zertifizierungsstelle wurde kompromittiert, z. B. weil der dem betroffenen Zertifikat zugrundeliegende Schlüssel geknackt oder entwendet wurde. Das betroffene Zertifikat und alles darunter ist nicht mehr sicher. |
affiliation-changed | Die betroffene Entität gehört nicht länger zu dem IPsec-Verbund, sei es, daß sie den Verbund komplett verlassen hat, sei es, daß sie jetzt zu einer anderen logischen Untereinheit des Verbundes gehört. Das Zertifikat kann jedenfalls nicht weiter verwendet werden. |
superseded | Das Zertifikat wurde durch ein anderes abgelöst und wird nicht mehr verwendet. |
cessation-of-operation | Die Entität, für die das Zertifikat ausgestellt wurde, stellt ihren Betrieb ein. Das zugewiesene Zertifikat wird nicht länger benötigt. |
certificate-hold | Das Zertifikat ist zeitweilig zurückgezogen. |
Diese Sperrliste legen Sie anschließend im Verzeichnis /etc/ipsec.d/crls/ ab. Starten Sie StrongSwan anschließend mit systemctl restart strongswan.service neu, und das fragliche Zertifikat ist gesperrt. Somit kann es nicht mehr verwendet werden, um sich an Ihrem IPsec-Gateway anzumelden.
nach obanSollte man selbst öffentlich als Zertifizierungsstelle auftreten?
Sollten Sie sich mit derlei Überlegungen tragen, so möchte ich Ihnen ganz offen
sagen: Lassen Sie es lieber bleiben, schon in Ihrem
ureigenen Interesse. Sowie es nämlich um vertrauliche Daten geht – und sowie
Sie mit Kryptographie zu tun bekommen, sind vertrauliche Daten nicht weit –
bewegen Sie sich auf verdammt dünnem Eis.
Zwar mag es auf den ersten Blick durchaus reizvoll erscheinen, selbst
Zertifikate anzubieten, doch gibt es hier eine Menge Unwägbarkeiten, die man
beileibe nicht alle überblicken kann. Es fängt bereits damit an, daß Ihr Server
sich ständigen Angriffen aus dem Internet ausgesetzt sieht, und ein Server, auf
dem eine Zertifizierungsstelle untergebracht ist, ist ein sehr lohnendes Ziel
für irgendwelche Übeltäter, die, sollte solch ein Angriff jemals erfolgreich
sein, Ihre ganze Zertifizierungsstelle aushebeln und Zugriff auf alle darüber
abgesicherten IPsec-Verbindungen erhalten. Schließlich sind diese so in der
Lage, sich selbst unter dem Namen Ihrer Zertifizierungsstelle jederzeit eigene
Zertifikate auszustellen, die sie in Ihrem IPsec-Verbund einsetzen können.
Schlimmer noch: Ein Angreifer könnte damit die gesamte durch Ihre Zertifikate
gesichert geglaubte Kommunikation abhören!
Ein anderer heikler Punkt ist die Frage der Haftung. Da Sie etwaige
Haftungsansprüche nicht per se ausschließen können (bei grober Fahrlässigkeit
oder Vorsatz sind Sie auf jeden Fall mit im Boot, wenn es um Schadensersatz
geht), da es ja Ihre Zertifikate waren, die ausgehebelt worden sind, kann der
daraus entstehende Schaden schnell in die Millionen gehen. Die Frage ist, ob
Ihre Haftpflichtversicherung hier überhaupt mitspielt, wenn Sie leichtfertig
Zertifikate an Dritte herausgeben.
Zudem stellt sich immer die Frage, wie Sie die Legitimität irgendwelcher
Anfragen aus dem Internet zuverlässig überprüfen wollen. Ausgewiesene
Zertifizierungsstellen verfügen sowohl über das notwendige Personal als auch
über die erforderliche Sachkunde auf diesem Gebiet, um das bewerkstelligen zu
können, nur Sie als Einzelkämpfer stehen hier sehr schnell auf verlorenem
Posten. Und selbst wenn Sie Zertifikate nur an Personen herausgeben, die Ihnen
persönlich bekannt sind, stellt ein solches Unterfangen ein nicht
kalkulierbares Risiko dar. Schließlich müssen Sie zu jeder Zeit gewährleisten
können, daß die Integrität Ihrer Zertifizierungsstelle gewahrt bleibt. Dies
umfaßt diverse Sicherheitsvorkehrungen auf Ihrem Server, die verhindern, daß
irgendwer einfach Zugriff auf Ihren Server bekommt, und ungewöhnliche
Aktivitäten aufzeichnet und meldet. Und sollte doch irgendwer unberechtigten
Zugriff bekommen, so müssen Sie schnellstmöglich, am besten sofort, reagieren
und das Problem beheben, bevor irgendwer Unheil mit etwaigen ergaunerten
Informationen anrichten kann. Das bedeutet im Fall einer Zertifizierungsstelle,
daß Sie alle betroffenen Zertifikate sperren müssen.
Sollten Sie aller Warnungen zum Trotz dennoch der Meinung sein, eine öffentlich
erreichbare Zertifizierungsstelle einrichten zu wollen, so erkundigen Sie sich
vorher unbedingt eingehend zu dieser Problematik. Konsultieren Sie auf jeden
Fall einen Rechtsanwalt, der Sie bezüglich juristischer Fragen berät und Sie
insbesondere auf etwaige rechtliche Fallstricke, die mit diesem Thema verbunden
sind, hinweisen kann. Holen Sie zudem unbedingt eine Auskunft bei Ihrem
Versicherer ein, ob dieser einen etwa entstehenden Schaden überhaupt reguliert
oder was Sie eine entsprechende Haftpflichtversicherung, die diese Schäden
abdeckt, überhaupt kostet. Darüber hinaus brauchen Sie auf jeden Fall die Hilfe
eines IT-Spezialisten, der sich mit der Sicherheit auf dem Bereich der
Informatik auskennt und Ihnen dabei hilft, Ihren Server gegen Angriffsversuche
zu sichern. Und zu guter Letzt: Halten Sie das Betriebssystem Ihres Servers
grundsätzlich auf dem neuesten Stand und setzen Sie ausschließlich dedizierte
Root-Server für dieses Vorhaben ein. So haben Sie die Gewähr, daß Sie als
Einziger Zugriff darauf haben und Ihnen niemand sonst ins Handwerk pfuschen
kann.
Einer Sache können Sie bei diesem Unterfangen jedoch versichert sein: Einfach
wird die ganze Angelegenheit garantiert nicht, und zudem müssen Sie einen
erheblichen Zeitaufwand einplanen, wenn Sie auch nur halbwegs erfolgreich sein
wollen, zumal es auf diesem Gebiet genügend Konkurrenz gibt.