Wie können wir helfen?

View Categories

07 Exemplarische Vorgehensweise für ein Testsystem

Einrichtung von DNS, Test-CA, Serverzertifikat und HTTPS für die MCDMS-WebAkte

Die folgende Anleitung beschreibt eine exemplarische Vorgehensweise für den Aufbau eines Testsystems der MCDMS-WebAkte.

Ziel ist es, eine Umgebung aufzubauen, die dem späteren Betrieb in einem Kliniknetz möglichst nahekommt:

  • interner DNS-Name
  • interne Zertifizierungsstelle
  • von dieser CA ausgestelltes Serverzertifikat
  • HTTPS über Port 8443
  • Betrieb als Windows-Dienst
  • Zugriff von Windows-PCs und optional iPad/iPhone ohne Zertifikatswarnung

Hinweis:
In produktiven Kliniknetzen sollten die vorhandenen DNS-, PKI-, Zertifikats- und Client-Verteilungsstrukturen der Klinik verwendet werden.
Die Einrichtung einer eigenen Test-CA ist dort in der Regel nicht erforderlich.

1. Grundlegende Werte festlegen

Vor Beginn sollten folgende Werte bekannt sein.

MCDMS APPPATH

Beispiel:

D:\Kliniken\KLINIK\MCDMS

IP-Adresse des Servers

Beispiel:

192.168.2.50

Interner DNS-Name der MCDMS-WebAkte

Beispiel:

mcdms-webakte.firma.local

Dieser Name muss später konsistent verwendet werden.

Beispiel:

DNS:
mcdms-webakte.firma.local

Zertifikat SAN:
mcdms-webakte.firma.local

HTTPS-Prefix:
https://mcdms-webakte.firma.local:8443/

Browser:
https://mcdms-webakte.firma.local:8443/

DNS-Name, Zertifikat und Browseradresse müssen übereinstimmen.

2. Internen DNS-Eintrag anlegen

Auf dem internen Windows-DNS-Server:

Server-Manager
→ Tools
→ DNS
→ Forward-Lookupzonen
→ entsprechende interne Zone auswählen

Beispiel:

firma.local

Anschließend:

Rechtsklick
→ Neuer Host (A oder AAAA)

Als Name beispielsweise:

mcdms-webakte

Als IP-Adresse die IP-Adresse des WebAkte-Servers:

192.168.2.50

Das Ergebnis lautet dann beispielsweise:

mcdms-webakte.firma.local → 192.168.2.50

Alternativ kann der Eintrag per PowerShell angelegt werden:

Add-DnsServerResourceRecordA `
  -Name "mcdms-webakte" `
  -ZoneName "firma.local" `
  -IPv4Address "192.168.2.50"

Auf einem Client kann die Auflösung anschließend geprüft werden:

Resolve-DnsName mcdms-webakte.firma.local

Die zurückgegebene IP-Adresse muss der IP-Adresse des WebAkte-Servers entsprechen.

3. Prüfen, ob bereits eine interne Zertifizierungsstelle vorhanden ist

Wenn im Unternehmen bereits eine interne Zertifizierungsstelle vorhanden ist, sollte diese verwendet werden.

In diesem Fall ist keine zusätzliche Test-CA erforderlich.

Es wird lediglich ein Serverzertifikat für den zuvor festgelegten DNS-Namen benötigt:

mcdms-webakte.firma.local

Der DNS-Name muss im Subject Alternative Name (SAN) des Zertifikats enthalten sein.

Danach kann direkt mit der Installation des Serverzertifikats fortgefahren werden.

4. Optional: Test-CA einrichten

Nur für Testsysteme:
Falls keine interne Zertifizierungsstelle vorhanden ist, kann zur Nachbildung einer Klinik-PKI eine eigene Test-CA eingerichtet werden.

PowerShell als Administrator starten.

Zunächst kann geprüft werden, ob die Rolle vorhanden ist:

Get-WindowsFeature AD-Certificate

Anschließend die Zertifizierungsstellenrolle installieren:

Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

Danach eine Test-Root-CA konfigurieren:

Install-AdcsCertificationAuthority `
  -CAType StandaloneRootCA `
  -CACommonName "ASPI-Test-CA" `
  -KeyLength 4096 `
  -HashAlgorithmName SHA256 `
  -ValidityPeriod Years `
  -ValidityPeriodUnits 10 `
  -Force

Den Dienst anschließend prüfen:

Get-Service CertSvc

Erwarteter Status:

Running

Die ASPI-Test-CA dient ausschließlich dazu, eine vorhandene Klinik-CA in einem Testsystem nachzubilden.

5. Zertifikatsantrag für die MCDMS-WebAkte erstellen

Im folgenden Beispiel wird das Zertifikat für diesen DNS-Namen erstellt:

mcdms-webakte.firma.local

Auf dem WebAkte-Server:

@'
[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=mcdms-webakte.firma.local"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=mcdms-webakte.firma.local"
'@ | Set-Content "C:\MCDMS-WebAkte.inf" -Encoding Ascii

Danach den Zertifikatsantrag erzeugen:

certreq.exe -new `
  "C:\MCDMS-WebAkte.inf" `
  "C:\MCDMS-WebAkte.req"

6. Serverzertifikat durch die CA ausstellen

Bei Verwendung der beispielhaften Test-CA:

certreq.exe -submit `
  -config "SERVERNAME\ASPI-Test-CA" `
  "C:\MCDMS-WebAkte.req" `
  "C:\MCDMS-WebAkte.cer"

SERVERNAME muss durch den tatsächlichen Namen des Servers ersetzt werden.

Bei einer Standalone-CA wird der Antrag normalerweise zunächst als ausstehend angezeigt.

Die angezeigte Anforderungs-ID merken.

Beispiel:

Anforderungs-ID: 2

Den Antrag genehmigen:

certutil.exe -resubmit 2

Anschließend das ausgestellte Zertifikat abrufen:

certreq.exe -retrieve `
  -config "SERVERNAME\ASPI-Test-CA" `
  2 `
  "C:\MCDMS-WebAkte.cer"

Falls Windows fragt, ob eine vorhandene Antwortdatei überschrieben werden soll, kann dies bestätigt werden.

7. Serverzertifikat installieren

Das ausgestellte Zertifikat auf dem WebAkte-Server installieren:

certreq.exe -accept "C:\MCDMS-WebAkte.cer"

Anschließend prüfen:

Get-ChildItem Cert:\LocalMachine\My |
Where-Object { $_.Subject -eq "CN=mcdms-webakte.firma.local" } |
Select-Object Subject, Thumbprint, NotAfter, HasPrivateKey

Wichtig ist insbesondere:

HasPrivateKey : True

Den angezeigten Thumbprint des Serverzertifikats notieren.

Dieser wird später beim Installationsskript benötigt.

Wichtig:
Für die MCDMS-WebAkte wird der Thumbprint des Serverzertifikats verwendet, nicht der Thumbprint der Root-CA.

8. Root-CA für Testclients exportieren

Dieser Schritt ist nur notwendig, wenn eine eigene Test-CA verwendet wird.

Auf dem Server:

$ca = Get-ChildItem Cert:\LocalMachine\Root |
Where-Object { $_.Subject -eq "CN=ASPI-Test-CA" } |
Select-Object -First 1

Export-Certificate `
  -Cert $ca `
  -FilePath "C:\ASPI-Test-CA.cer"

Prüfen:

Test-Path "C:\ASPI-Test-CA.cer"

Erwartet:

True

9. Root-CA auf einem Windows-Testclient installieren

Die Datei beispielsweise nach

C:\Temp\ASPI-Test-CA.cer

kopieren.

PowerShell auf dem Client als Administrator öffnen:

Import-Certificate `
  -FilePath "C:\Temp\ASPI-Test-CA.cer" `
  -CertStoreLocation Cert:\LocalMachine\Root

Anschließend prüfen:

Get-ChildItem Cert:\LocalMachine\Root |
Where-Object { $_.Subject -eq "CN=ASPI-Test-CA" } |
Select-Object Subject, Thumbprint, NotAfter

Wichtig:
Auf dem Client wird die Root-CA als vertrauenswürdig installiert.
Das einzelne WebAkte-Serverzertifikat muss nicht auf jedem Client installiert werden.

In einem produktiven Kliniknetz wird das Vertrauen in die interne CA üblicherweise zentral über Active Directory und Gruppenrichtlinien verteilt.

10. Optional: Root-CA auf iPad oder iPhone installieren

Für ein Testsystem kann das Root-Zertifikat auf ein iPad oder iPhone übertragen werden.

Anschließend:

Einstellungen
→ Allgemein
→ VPN & Geräteverwaltung
→ Profil installieren

Danach:

Einstellungen
→ Allgemein
→ Info
→ Zertifikatsvertrauenseinstellungen

Für die Test-CA das vollständige Vertrauen aktivieren.

Beispiel:

ASPI-Test-CA
→ Vollständiges Vertrauen aktivieren

In produktiven Umgebungen erfolgt dies üblicherweise zentral über ein Mobile-Device-Management-System.

11. MCDMS-WebAkte auf den Server kopieren

Es sollte das freigegebene Deployment der MCDMS-WebAkte verwendet werden.

Der komplette Ordner

Web\

wird nach

{APPPATH}\Web

kopiert.

Beispiel:

D:\Kliniken\KLINIK\MCDMS\Web

Die Struktur enthält beispielsweise:

Web\
├─ WEB.INI
├─ FORMULARE.INI
├─ PATIENTEN.INI
├─ AKTENSTRUKTUR.INI
├─ PROGRAM\
├─ SETUP\
├─ LOGS\
├─ HTML\
├─ CSS\
├─ JS\
└─ IMAGES\

12. MCDMS-WebAkte installieren

Windows PowerShell 5.1 als Administrator starten.

In den Setup-Ordner wechseln:

cd "D:\Kliniken\KLINIK\MCDMS\Web\SETUP"

Bei einer lokalen MCDMS-Installation kann der Dienst unter LocalSystem betrieben werden:

.\Install.ps1 -ServiceAccount LocalSystem

Das Installationsskript fragt unter anderem folgende Werte ab.

HTTPS-Prefix

Beispiel:

https://mcdms-webakte.firma.local:8443/

CertificateThumbprint

Hier wird der zuvor ermittelte Thumbprint des Serverzertifikats eingetragen.

MCDMS APPPATH

Beispiel:

D:\Kliniken\KLINIK\MCDMS

Das Installationsskript richtet anschließend die notwendigen Komponenten ein, unter anderem:

  • Produktionskonfiguration in WEB.INI
  • HTTPS-Prefix
  • AllowedHosts
  • HTTP.sys
  • SSL-Zertifikatbindung
  • erforderliche URLACL-Konfiguration
  • Windows-Firewallregel
  • Windows-Dienst MCDMS.WebAkte
  • automatischen Dienststart
  • Recovery-Einstellungen

Bei einem APPPATH auf einer Netzwerkfreigabe ist anstelle von LocalSystem ein entsprechend berechtigtes Dienstkonto zu verwenden.

13. Windows-Dienst prüfen

Nach der Installation:

Get-Service MCDMS.WebAkte

Erwartet:

Status : Running

14. Port 8443 prüfen

netstat -ano | findstr ":8443"

Es muss ein Listener für Port 8443 vorhanden sein.

15. Status-Endpunkt prüfen

Auf dem Server:

Invoke-WebRequest `
  https://mcdms-webakte.firma.local:8443/api/status `
  -UseBasicParsing

Erwartet wird:

StatusCode : 200

Der Status-Endpunkt liefert unter anderem Informationen wie:

Status      : ok
Application : MCDMS WebServer
Version     : 1.0.0.0

16. Zugriff von einem Windows-Client testen

Im Browser aufrufen:

https://mcdms-webakte.firma.local:8443/

Wenn DNS, Serverzertifikat und CA-Vertrauen korrekt eingerichtet sind, darf keine Zertifikatswarnung erscheinen.

Anschließend können die wichtigsten Funktionen geprüft werden:

  • MCDMS-Login
  • Patientensuche
  • Patient auswählen
  • Patientenstammblatt
  • „Zuletzt“-Liste
  • Aktenbereiche
  • Formulare öffnen
  • Formulare speichern

17. Optional: Zugriff vom iPad testen

In Safari:

https://mcdms-webakte.firma.local:8443/

Wenn die Root-CA korrekt installiert und als vertrauenswürdig aktiviert wurde, sollte der Zugriff ohne Zertifikatswarnung möglich sein.

Danach können beispielsweise Login, Patientenauswahl und Formularanzeige geprüft werden.

18. Wichtige Regel für DNS und Zertifikat

Für den HTTPS-Betrieb muss derselbe DNS-Name durchgängig verwendet werden.

Beispiel:

DNS:
mcdms-webakte.firma.local

Zertifikat SAN:
mcdms-webakte.firma.local

HTTPS-Prefix:
https://mcdms-webakte.firma.local:8443/

Browser:
https://mcdms-webakte.firma.local:8443/

Wenn diese Namen voneinander abweichen, kann es zu Zertifikatsfehlern kommen.

Produktivbetrieb in einer Klinik

Die oben beschriebene Einrichtung einer eigenen ASPI-Test-CA dient ausschließlich zur Nachbildung einer typischen Klinik-PKI in einem Testsystem.

Im produktiven Klinikbetrieb sollte normalerweise die bereits vorhandene Infrastruktur verwendet werden.

Der übliche Ablauf lautet:

  1. Die Klinik-IT stellt einen internen DNS-Namen für die MCDMS-WebAkte bereit.
  2. Die Klinik-IT stellt über ihre vorhandene Zertifizierungsstelle ein Serverzertifikat für diesen DNS-Namen aus.
  3. Das Serverzertifikat wird auf dem WebAkte-Server im Zertifikatsspeicher des lokalen Computers installiert.
  4. Die Arbeitsplatzrechner vertrauen der Klinik-CA bereits bzw. erhalten das Root-Zertifikat zentral über Active Directory und Gruppenrichtlinien.
  5. Mobile Geräte erhalten das CA-Vertrauen gegebenenfalls über das MDM-System der Klinik.
  6. Bei der Installation der MCDMS-WebAkte wird der Thumbprint des bereitgestellten Serverzertifikats angegeben.
  7. Install.ps1 richtet die MCDMS-WebAkte, HTTP.sys, die HTTPS-Bindung, die Firewall und den Windows-Dienst ein.

Die MCDMS-WebAkte benötigt damit keine eigene Zertifizierungsinfrastruktur. Sie verwendet das von der jeweiligen Klinik bereitgestellte Serverzertifikat.