Erste Installation und Zertifikatskette für den WiKID-Server

Der Leitfaden beschreibt Schritt für Schritt, wie Sie den WiKID Strong Authentication Server initial einrichten: Intermediate CA erzeugen, CSR erstellen, CSR einreichen, signiertes Zertifikat installieren, ein localhost-Zertifikat erzeugen und wAuth neu starten. Enthalten sind Checklisten für Admins und Betreiber, Troubleshooting-Hinweise, Sicherheitsüberlegungen sowie ein kurzes Glossar.

Wichtig: Behalten Sie die Passphrase für den privaten Schlüssel sicher; ohne sie ist das Zertifikat unbrauchbar. Lesen Sie insbesondere die Rollen- und Prüf-Checklisten vor dem Neustart.

Übersicht der Seite zur ersten Installation

Die Einrichtung des WiKID-Authentifizierungsservers ist in mehrere logische Schritte gegliedert. Nach Abschluss dieser Schritte können Sie Domains, Netzwerk-Clients und Benutzer hinzufügen und den Server produktiv nutzen.

Figure 3 - The Initial Administration Page

Zertifikatskette einrichten

Der WiKID-Server verwendet Zertifikate in mehreren internen Komponenten:

• Jeder Authentifizierungsserver fungiert als Intermediate Certificate Authority (CA).
• Jeder Server verwendet Zertifikate zur Identifikation und Autorisierung von Netzwerk-Clients.

Deshalb muss vor der vollständigen Nutzung des Servers ein Zertifikat erzeugt werden. Dies erfolgt über die Administrationsoberfläche: Wählen Sie den Tab Erstellen einer Intermediate CA (Creating an Intermediate CA), um die Zertifikatfunktionen aufzurufen.

Schritt 1: Intermediate CA erzeugen

Ziel: Erzeugen eines öffentlichen/privaten Schlüsselpaares und einer Certificate Signing Request (CSR).

Der Server enthält die WiKID-Corporate-CA als Ausgangspunkt. Der Assistent erzeugt Ihre Schlüssel und die CSR. Klicken Sie auf “Generate” und füllen Sie das Formular aus.

Figure 4 - Create Intermediate Certificate Authority Screen

Alle Felder in diesem Formular sind erforderlich. Hier die Feldbeschreibungen in Kurzform:

• Intermediate CA Administrator Email: Kontaktadresse für den Versand des signierten Zertifikats. Muss gültig sein.
• Servers Fully Qualified Domain Name: Der im DNS registrierte Hostname, z. B. server.example.com. SSL-Clients erwarten Übereinstimmung mit dem Verbindungs-Hostname.
• Organization Unit: Abteilungs- oder Bereichsname (Identifikation).
• Organization Name: Der Firmenname, sollte mit WiKID-Verkaufs-/Evaluationsdaten übereinstimmen, um die Zertifikatsausstellung zu beschleunigen.
• Locality: Stadt.
• State: Bundesland/Province, nicht abkürzen.
• Country Code: Zwei-Buchstaben-Ländercode (z. B. DE für Deutschland, US für Vereinigte Staaten).
• Passphrase: Schützt den privaten Schlüssel in einer PKCS#12-Datei. Diese Passphrase wird beim Serverstart benötigt. Sie wird nicht gespeichert und kann nicht wiederhergestellt werden — wählen Sie eine starke, einprägsame Passphrase.

Nach Klick auf Generate werden Schlüssel und CSR erzeugt. Das Ergebnis ähnelt der folgenden Anzeige.

Figure 5 - The CSR

Die Zertifikatsanforderung wird in Base64 DER-codiert angezeigt. Markieren Sie den gesamten Text im Textfeld und kopieren Sie ihn in die Zwischenablage.

Schritt 2: CSR zur Signierung einreichen

Klicken Sie auf den Link https://www/wikidsystems.com/wikid/newcertreq.jsp oberhalb des Textfelds. Dadurch öffnet sich die Einreichungsseite für CSR-Anfragen bei der WiKID-CA.

Figure 6 - CSR Submission Screen

Fügen Sie den CSR-Text (inklusive —–BEGIN CERTIFICATE REQUEST—– und —–END CERTIFICATE REQUEST—–) in das Feld ein und senden Sie das Formular ab. Sie erhalten eine Anfrage-Nummer für das Tracking; der CA-Administrator wird benachrichtigt.

Figure 7 - CSR Acknowledgment Screen

Der CA-Administrator bearbeitet die Anfrage. Das signierte Zertifikat wird an die in Schritt 1 angegebene E‑Mail-Adresse gesendet. Die Bearbeitungszeit beträgt in der Regel weniger als ein Werktag. Das per E‑Mail zugestellte Zertifikat sieht ähnlich aus wie die folgende Darstellung.

Figure 8 – Certificate Block

Hinweis: Das Zertifikat ist ohne den privaten Schlüssel (aus Schritt 1) nutzlos. Achten Sie darauf, das Zertifikat als reinen Text zu kopieren — E‑Mail-Clients wie Outlook oder Gmail können Textkodierungen verändern.

Schritt 3: Zertifikat installieren

Nach Erhalt des signierten Zertifikats öffnen Sie in der Administrationsoberfläche den Tab Install Intermediate CA und wählen Install.

Figure 9 – Certificate Installation Screen

Fügen Sie den Zertifikatstext aus der E‑Mail in das Textfeld ein, geben Sie die Passphrase ein, mit der der private Schlüssel gesichert wurde (Schritt 1) und führen Sie die Installation aus.

Wichtig: Bei einem Fehler prüfen Sie die Passphrase und stellen Sie sicher, dass Sie reinen Text (kein HTML) einfügen. Falls Sie die Passphrase vergessen haben, müssen Sie Schritt 1 wiederholen und ein neues Schlüsselpaar erzeugen.

Schritt 4: Localhost-Zertifikat erzeugen

Alle Dienste, die direkt mit dem Authentifizierungsserver kommunizieren, benötigen ein gültiges Zertifikat, das von der soeben installierten Intermediate CA ausgestellt wurde. Erzeugen Sie ein Client-Zertifikat mit dem vollständig qualifizierten Namen “localhost” für lokale Protokollmodule.

Hinweis: Einige Protokolle (z. B. RADIUS in der Enterprise-Version, LDAP, wAuth) besitzen keine eigene Zertifikatsauthentifizierung oder Transportverschlüsselung. WiKID stellt Protokollmodule bereit, die diese Protokolle transparent in gesicherte Verbindungen überführen. Daher verlangen lokale Schnittstellen ein Zertifikat, auch wenn das Protokoll selbst keine Zertifikate kennt.

Figure 10 – Certificate Generation Screen

Felder kurz erklärt:

• Client’s Fully Qualified Domain Name: Für lokale Dienste muss hier “localhost” stehen.
• Organization Name: Firmenname des Betreibers des Clients.
• Locality: Stadt.
• State: Bundesland/Province.
• Country Code: Zwei-Buchstaben-Ländercode.
• Client PKCS12 Passphrase: Passphrase zum Verschlüsseln der erzeugten PKCS#12-Datei für den Client.
• Passphrase again: Wiederholung zur Bestätigung.
• Server Keystore Passphrase: Passphrase der Intermediate CA (Schritt 1).

Klicken Sie auf Generate. Anschließend sehen Sie eine Ausgabe ähnlich der folgenden.

Figure 11 – PKCS Delivery Screen

Die Anzeige informiert über den Speicherort des erzeugten Zertifikats. Für Localhost-Dienste wird das Zertifikat bereits an der korrekten Stelle installiert.

Schritt 5: wAuth-Server neu starten

Melden Sie sich als root am Authentifizierungsserver an und führen Sie aus:

wikidctl restart

Der Dienst wird gestoppt und wieder gestartet. Sie werden zur Eingabe der wAuth-Passphrase aufgefordert — das ist die Passphrase, die Sie in Schritt 1 für die Intermediate CA festgelegt haben. Nach Eingabe verwendet der Server das neue Zertifikat für die Client-Authentifizierung.

Wenn Sie das wiederholte Eingeben der Passphrase beim Start vermeiden möchten, können Sie eine Datei /etc/WiKID/security anlegen, mit einer einzigen Zeile:

WAUTH_PASSPHRASE=yourpassprase

Wichtig: Die Speicherung der Passphrase auf Festplatte erhöht das Risiko bei einem kompromittierten System. Kümmern Sie sich um geeignete Dateiberechtigungen (nur root lesbar) und untersuchen Sie alternative Geheimnisverwaltungs-Lösungen.

Rollenspezifische Checklisten vor dem Produktivstart

Systemadministrator:

• Backup der aktuellen Konfiguration und des Keystores anfertigen.
• Private Key-Passphrase sicher notieren (Offline und verschlüsselt).
• CSR erzeugen, speichern, einreichen.
• Signiertes Zertifikat prüfen und installieren.
• Localhost-Zertifikat erzeugen und Prüfdienst ausführen.
• Neustart durchführen und Logs auf Fehler prüfen.

Netzwerk-/Security-Engineer:

• Firewall-Regeln validieren (Ports für wAuth und Protokollmodule freigeben).
• Client-Zertifikate verteilen und Installation testen.
• Monitoring für Zertifikatsablauf konfigurieren.

Applikationsverantwortlicher:

• Client-Anwendungen auf Hostnamen-Abgleich testen.
• Funktions- und Lasttests mit produktiven Szenarien durchführen.

Troubleshooting und typische Fehlerfälle

Wann die Einrichtung fehlschlägt (Counterexamples):

• Falscher FQDN im CSR: Clients erhalten Namensfehler (Hostname stimmt nicht mit Zertifikat überein).
• Passphrase verloren: Ohne Passphrase ist der private Schlüssel unzugänglich — Sie müssen neue Schlüssel erzeugen.
• Kopierte Zertifikatsdaten im falschen Format: E‑Mail-Clients wandeln Zeilenenden oder Kodierung. Achten Sie auf reinen ASCII-Text mit BEGIN/END-Linien.
• Berechtigungsprobleme: Unzureichende Dateiberechtigungen verhindern, dass Dienste auf Keystore zugreifen.

Konkrete Prüfungen:

• Prüfen Sie mit openssl, ob das Zertifikat korrekt ist:

openssl x509 -in server.crt -text -noout

• Prüfen Sie den privaten Schlüssel und die Passphrase:

openssl pkcs12 -info -in server.p12

(Bei Passwortfehlern wird openssl eine klare Fehlermeldung ausgeben.)

• Logs prüfen:

Überwachen Sie die WiKID-Logs und Systemlogs (/var/log/) während Installations- und Startvorgängen.

Alternative Ansätze

• Verwenden einer internen Enterprise-PKI: Wenn Sie bereits eine zentrale PKI im Unternehmen haben, können Sie die WiKID-Server-CSR dort signieren lassen und die Zertifikate per interner CA verteilen.
• Automatisierte Zertifikatsverwaltung: Tools wie HashiCorp Vault oder ein interner ACME-Server können langfristig die manuelle CSR-/Zertifikatspflege minimieren.
• Hardware-Sicherheitsmodule (HSM): Für höhere Sicherheit kann der private Schlüssel in einem HSM erzeugt und verwahrt werden.

Vorteile/Nachteile kurz:

• Interne PKI: + zentrale Kontrolle, - zusätzlicher Integrationsaufwand.
• ACME/HSM: + Automatisierung / Schutz, - mögliche Komplexität in der Integration mit WiKID.

Mini-Methodologie: Sicherer Ablauf für die Zertifikatserstellung

1. Plan: Bestimmen Sie FQDNs, Verantwortliche und E‑Mail-Adressen.
2. Backup: Exportieren Sie vorhandene Keystore-Dateien.
3. Generate: Erstellen Sie CSR und Schlüssel lokal.
4. Submit: Reichen Sie die CSR ein und tracken Sie die Request-ID.
5. Install: Nach Erhalt installieren und Verifikation durchführen.
6. Test: Funktionale Tests mit Clients und Protokollmodulen.
7. Dokumentation: Notieren Sie Seriennummern, Ablaufdatum, Verantwortliche.

Sicherheits- und Datenschutzhinweise

• Schützen Sie Passphrasen und private Schlüssel stets offline oder in einem bewährten Geheimnis-Manager.
• Minimieren Sie die Lebensdauer von Zertifikaten, indem Sie Wiederausstellung und Erneuerungsprozesse planen.
• Setzen Sie Dateiberechtigungen restriktiv (z. B. 600 für Keystore-Dateien, nur root lesbar).
• Protokollieren Sie alle Änderungen an CA- und Keystore-Konfigurationen für Audits.
• GDPR/Hinweis zur Datenverarbeitung: Zertifikate enthalten keine personenbezogenen Daten über Nutzer; Kontaktdaten (E‑Mails) sollten gemäß interner Datenschutzrichtlinien verarbeitet werden.

Testszenarien und Abnahmekriterien

Kriterien für die Abnahme

• Das signierte Intermediate-Zertifikat ist installiert und wird vom Server ohne Fehler geladen.
• Der Server akzeptiert TLS-Verbindungen von Clients, die das von der Intermediate-CA ausgestellte Zertifikat verwenden.
• Lokale Dienste (localhost) verbinden erfolgreich über das erzeugte Localhost-Zertifikat.
• Bei Neustart des Dienstes wird die Passphrase akzeptiert und der Dienst startet komplett.

Testfälle

• TC-01: CSR erzeugen, CSR extern signieren lassen, signiertes Zertifikat installieren → Verbindungstest per TLS ok.
• TC-02: Passphrase falsch eingeben → Installation schlägt fehl, aussagekräftige Fehlermeldung.
• TC-03: Localhost-Zertifikat erzeugen → lokale Module verbinden.

Rollenbasierte SOP (Kurzablauf)

Systemadministrator SOP:

1. Backup der Keystore-Dateien anlegen.
2. CSR per Admin-UI erzeugen.
3. CSR in interner CA einreichen und Request-ID notieren.
4. Empfang des Zertifikats prüfen, signiertes Zertifikat installieren.
5. Localhost-Zertifikat erzeugen, falls erforderlich.
6. Dienst neu starten und Starterrors prüfen.

Applikationsverantwortlicher SOP:

1. Hostname-Konfiguration der Clients verifizieren.
2. Client-Zertifikat verteilen und auf Clientseite installieren.
3. Verbindungstest mit Testanwendern durchführen.

Entscheidungshilfe (Mermaid-Flussdiagramm)

flowchart TD
  A[Start: Neuer WiKID-Server] --> B{Haben Sie eine zentrale PKI?}
  B -- Ja --> C[Erstellen CSR und Signierung über interne PKI]
  B -- Nein --> D[Erstellen interner Intermediate CA über UI]
  C --> E[Zertifikat installieren und Localhost-Zertifikat erzeugen]
  D --> E
  E --> F{Sind alle Dienste verbunden?}
  F -- Ja --> G[Neustart und Produktivsetzung]
  F -- Nein --> H[Troubleshooting: Logs, Passphrasen, FQDN prüfen]
  H --> E

Glossar (1-Zeiler)

• CA: Certificate Authority, Aussteller von Zertifikaten.
• CSR: Certificate Signing Request, Anfrage zur Ausstellung eines Zertifikats.
• PKCS#12: Containerformat für private Schlüssel und Zertifikate.
• FQDN: Fully Qualified Domain Name, vollständiger Hostname mit Domain.

Vorlagen und Kurzbefehl-Cheat-Sheet

Wichtige Kommandos lokal:

• WiKID-Dienst neustarten:

wikidctl restart

• PKCS#12-Informationen prüfen:

openssl pkcs12 -info -in client.p12

• Zertifikat prüfen:

openssl x509 -in server.crt -noout -text

Datei /etc/WiKID/security (Beispiel, nur root lesbar):

WAUTH_PASSPHRASE=MyStrongPassphrase

Sicherheits-Tipp: Legen Sie diese Datei mit chmod 600 und Eigentümer root:root an.

Häufig gestellte Fragen

Frage: Was passiert, wenn ich die Passphrase verliere?

Antwort: Sie können den privaten Schlüssel nicht wiederherstellen; erzeugen Sie ein neues Schlüsselpaar und wiederholen Sie den CSR-/Signaturvorgang.

Frage: Kann ich die interne WiKID-CA durch eine bestehende Unternehmens-CA ersetzen?

Antwort: Ja. Sie können die CSR über Ihre interne CA signieren lassen und das signierte Zertifikat installieren.

Frage: Ist es sicher, die WAUTH_PASSPHRASE in einer Datei zu speichern?

Antwort: Es ist möglich, aber riskanter. Nutzen Sie restriktive Berechtigungen und prüfen Sie alternative Geheimnismanagement-Lösungen für höhere Sicherheit.

Zusammenfassung

• Erzeugen Sie zuerst die Intermediate CA (Schritt 1) und bewahren Sie die Passphrase sicher auf.
• Reichen Sie die CSR ein und installieren Sie das signierte Zertifikat (Schritte 2–3).
• Erzeugen Sie ein Localhost-Zertifikat für lokale Dienste (Schritt 4).
• Starten Sie den Dienst neu und testen Sie alle relevanten Clients (Schritt 5).

Kernaussagen:

• Ohne private Passphrase ist das Zertifikat unbrauchbar.
• Prüfen Sie FQDN-Übereinstimmung zwischen Zertifikat und Clientverbindung.
• Achten Sie auf sichere Speicherung und restriktive Dateiberechtigungen.

Weitere Aktionen: Erstellen Sie Überwachungsregeln für bevorstehende Zertifikatsabläufe und dokumentieren Sie die Kontakte und Seriennummern aller ausgestellten Zertifikate.