|
<< Klicken Sie, um das Inhaltsverzeichnis anzuzeigen >> Navigation: Technisches > Eigene Server-Zertifikate |
Standardmäßig erzeugt der Server sein Zertifikat selbst über eine eigene, installationsindividuelle Zertifizierungsstelle. Warum dieses mitgelieferte Wurzelzertifikat kein Sicherheitsrisiko darstellt und wie Sie es auf den Geräten (Tablets und Windows-PCs) installieren, beschreibt das Kapitel EMIL-Wurzelzertifikat. Das vorliegende Kapitel behandelt den umgekehrten Weg: die Verwendung eines eigenen, von Ihrer Einrichtung bereitgestellten Zertifikats.
Manche Einrichtungen möchten oder dürfen kein zusätzliches Wurzelzertifikat auf den Tablets installieren - etwa weil die Geräte über eine zentrale Geräteverwaltung (MDM) administriert werden oder weil bereits ein gültiges, öffentlich vertrautes Zertifikat (z.B. einer öffentlichen Zertifizierungsstelle oder per Let's Encrypt) für den Applikationsserver vorliegt. Für diesen Fall kann der Server so umgeschaltet werden, dass er statt seines selbst erzeugten Zertifikats ein von der Einrichtung bereitgestelltes verwendet. Vertraut das Tablet der ausstellenden Stelle ohnehin schon, entfällt jede zertifikatsbezogene Einrichtung am Tablet.
Geltungsbereich: Das eigene Zertifikat wird für alle verschlüsselten Verbindungen des Servers verwendet - also gleichermaßen für die RITA-Tablets, die EMIL-Arbeitsplätze (Clients) und den FHIR-Server.
Wichtig: In diesem Modus erzeugt und erneuert der Server nichts mehr selbst - alle internen, automatischen Zertifikatserneuerungen werden damit dauerhaft abgeschaltet. Die Verantwortung für ein gültiges, passendes und rechtzeitig erneuertes Zertifikat liegt ab dann vollständig bei der Einrichtung. Läuft das Zertifikat ab oder passt der Hostname (SAN) nicht, verweigern Tablets, Clients und FHIR-Gegenstellen die Verbindung. Dieser Weg richtet sich an Administratoren, die wissen, was sie tun.
Die meisten Einrichtungen erhalten ihr Zertifikat als einzelne, kennwortgeschützte P12- bzw. PFX-Datei, die Zertifikat, Zwischenzertifikate und privaten Schlüssel gemeinsam enthält. Diese Datei kann direkt eingelesen werden, ohne dass Sie die einzelnen PEM-Dateien selbst erzeugen müssen.
Öffnen Sie dazu die globalen Einstellungen und klicken Sie auf die Schaltfläche Eigenes Server-Zertifikat importieren. Wählen Sie die P12-/PFX-Datei aus und geben Sie das zugehörige Kennwort an. Der Server zerlegt die Datei anschließend selbst (mit OpenSSL) in die beiden benötigten Teile, legt sie im Ordner certs als owncert.pem (vollständige Kette) und ownkey.pem (unverschlüsselter Schlüssel) ab und trägt die oben genannten Einstellungen (CUSTOMCERT=1) automatisch in die config.ini ein.
Nach dem erfolgreichen Import werden Sie darauf hingewiesen, dass die Umschaltung erst ab dem nächsten Neustart des Applikationsservers aktiv wird, und gefragt, ob dieser Neustart jetzt erfolgen soll. Bestätigen Sie, wird der Applikationsserver neu gestartet und dieser Arbeitsplatz im Anschluss ebenfalls; lehnen Sie ab, wird das Zertifikat beim nächsten regulären Neustart des Servers wirksam. Zum Erneuern eines ablaufenden Zertifikats wiederholen Sie einfach den Import mit der neuen Datei.
Hinweis: Die nachfolgend beschriebene manuelle Einrichtung über die config.ini bleibt für Sonderfälle erhalten - etwa wenn bereits fertige PEM-Dateien vorliegen (z.B. die fullchain.pem und der Schlüssel von Let's Encrypt) und keine P12-Datei existiert.
Möchten Sie Bezug und Erneuerung eigener Zertifikate vollständig automatisieren, lesen Sie Automatischer Zertifikatsbezug über ACME.
Die Umschaltung erfolgt in der config.ini des Servers im Abschnitt [CONFIG]:
[CONFIG]
CUSTOMCERT=1
CUSTOMCERTFILE=owncert.pem
CUSTOMKEYFILE=ownkey.pem
Die Dateien werden im Unterordner certs des Server-Stammverzeichnisses erwartet (dort, wo im Standardbetrieb auch cert.crt und key.pem liegen). Die vom Server selbst erzeugten Dateien bleiben dabei unangetastet. Nach dem Hinterlegen oder Austauschen der Dateien - auch bei jeder turnusmäßigen Erneuerung - muss der Applikationsserver neu gestartet werden. Ein Zurückstellen auf den Automatikbetrieb ist jederzeit gefahrlos möglich (siehe unten).
• owncert.pem (Zertifikat): PEM-Format, reines ASCII ohne BOM. Es muss die vollständige Kette in dieser einen Datei enthalten, Reihenfolge: Server-(Leaf-)Zertifikat zuerst, danach die Zwischenzertifikate. Bei Let's Encrypt ist das die Datei fullchain.pem.
• ownkey.pem (privater Schlüssel): PEM-Format, unverschlüsselt (ohne Passphrase), muss zum Zertifikat passen. Schlüsseltyp RSA (mindestens 2048 Bit) oder ECC.
• Der SAN (Subject Alternative Name) des Zertifikats muss den FQDN/Hostnamen abdecken, über den die Geräte und Arbeitsplätze den Server erreichen. Verwendungszweck TLS-Server-Authentifizierung (serverAuth), Gültigkeitszeitraum aktuell.
• Die ausstellende Zertifizierungsstelle muss den Gegenstellen bekannt sein - bei den RITA-Tablets also eine öffentliche CA oder eine über die Geräteverwaltung (MDM) ausgerollte Haus-CA.
Voraussetzung im Netzwerk: Die Geräte müssen den Server über einen DNS-Namen (FQDN) erreichen, der im Zertifikat steht. Öffentliche Zertifizierungsstellen stellen keine Zertifikate auf reine IP-Adressen aus.
Sie können jederzeit gefahrlos wieder auf das selbst erzeugte Zertifikat des Servers samt der internen, automatischen Erneuerung zurückschalten. Setzen Sie dazu in der config.ini im Abschnitt [CONFIG] den Wert wieder auf 0:
[CONFIG]
CUSTOMCERT=0
Die Dateien owncert.pem/ownkey.pem können liegen bleiben, sie werden bei CUSTOMCERT=0 ignoriert. Nach einem Neustart des Applikationsservers verwendet der Server wieder sein eigenes, selbst erzeugtes Zertifikat und erneuert es fortan auch wieder selbstständig. Die dafür nötigen Dateien (cert.crt, key.pem, rcert.pem) wurden durch den Import zu keinem Zeitpunkt verändert.
Im Normalbetrieb akzeptiert der EMIL-Arbeitsplatz das Zertifikat seines eigenen Servers, ohne die Zertifikatskette gegen die Vertrauensanker des Rechners zu prüfen. Das ist Absicht: Mit dem selbst erzeugten Zertifikat des Auslieferungszustands wäre ein Betrieb sonst nicht möglich. Vertraulichkeit und Integrität der Übertragung sind davon nicht berührt - die Verbindung ist in jedem Fall mit TLS verschlüsselt.
Setzen Sie ein eigenes Zertifikat aus Ihrer PKI ein (CUSTOMCERT=1, siehe oben), können Sie die Arbeitsplätze zusätzlich prüfen lassen, ob die Kette aufgeht. Die Einstellung gehört der Einrichtung und nicht dem einzelnen Rechner - sie wird deshalb einmal zentral in der config.ini des Servers vorgenommen und gilt sofort für alle Arbeitsplätze:
[CONFIG]
CERTCHECK=CHECKONLY
Zulässig sind drei Werte:
• OFF - keine Prüfung. Das ist die Voreinstellung und das bisherige Verhalten; fehlt der Eintrag oder steht dort etwas anderes, gilt OFF.
• CHECKONLY - es wird geprüft, die Sitzung läuft aber in jedem Fall weiter. Schlägt die Prüfung fehl, erscheint am Arbeitsplatz ein Warnhinweis mit der technischen Meldung.
• STRICT - schlägt die Prüfung fehl, erscheint eine Fehlermeldung und die Sitzung wird beendet. Der Arbeitsplatz kann erst wieder arbeiten, wenn das Zertifikat stimmt oder die Einstellung zurückgenommen wird.
Der Arbeitsplatz erfährt die Betriebsart mit der Antwort auf seine Anmeldung und prüft daraufhin genau einmal je Programmlauf gegen den Zertifikatsspeicher des Rechners. Eine Änderung in der config.ini wirkt damit, sobald sich der jeweilige Arbeitsplatz das nächste Mal anmeldet; ein Neustart des Applikationsservers ist dafür nicht nötig.
Ist der Server nicht erreichbar, wird kein Zertifikatsurteil gefällt - ein Netzausfall führt auch im Modus STRICT nicht zum Abbruch der Sitzung.
Wichtig: Setzen Sie STRICT erst, wenn CUSTOMCERT=1 aktiv ist und das ausstellende Wurzelzertifikat auf allen Arbeitsplätzen hinterlegt wurde - andernfalls sperren Sie sämtliche Arbeitsplätze gleichzeitig aus, denn die Einstellung gilt zentral. Der empfohlene Weg ist, zunächst mit CHECKONLY zu arbeiten und erst nach einigen beanstandungsfreien Tagen auf STRICT umzustellen. Sollten Sie sich dennoch aussperren, genügt es, in der config.ini des Servers CERTCHECK wieder auf OFF zu setzen.
Wogegen die Prüfung schützt: Sie deckt eine falsch oder unvollständig eingerichtete Zertifikatskette auf, ein abgelaufenes Zertifikat, ein Zertifikat auf den falschen Servernamen sowie Arbeitsplätze, denen das Wurzelzertifikat der Einrichtung fehlt. Sie ist eine Kontrolle der eigenen Einrichtung und kein Schutz gegen einen Angreifer, der die Netzverbindung vollständig beherrscht: Die Betriebsart kommt selbst über diese Verbindung, und die Anmeldung hat zum Zeitpunkt der Prüfung bereits stattgefunden.