Sichere HTTPS Kommunikation mit SSL-Zertifikaten

Konzept und Nutzen für Projekt Manager einfach erklärt

Bei der Kommunikation via Internet (z.B. zwischen einem ALM Tool via Jira, ServiceNow oder SAP Cloud ALM und Conigma Connect) ist im Normalfall eine verschlüsselte Kommunikation über HTTPS gewünscht (HTTP wäre unverschlüsselt). Vorliegender Blog Eintrag erläutert das Konzept dahinter als Grundlage für die Projektmanager unserer Kunden, die richtigen internen Ressourcen hierfür einzuplanen.
Bei einer bidirektionalen Kommunikation nimmt jeder der beiden Kommunikationspartner jeweils einmal die Client- oder die Serverrolle ein, je nach Kommunikationsrichtung. Der Zertifikatssetup ist also zweimal durchzuführen, einmal pro Richtung.
Im Vergleich zu unverschlüsselter HTTP-Kommunikation bieten HTTPS vor allem zwei große Vorteile:

1. Authentifizierung: Der Client kann sicherstellen, dass der Server derjenige ist, der er vorgibt zu sein.

2. Verschlüsselung: Die Kommunikation ist für Dritte nicht einsehbar, nur die beiden Kommunikationsparteien können den Inhalt entschlüsseln.

Die für die sichere Kommunikation notwendigen Voraussetzungen sind in erster Linie vom Server zu erfüllen. Er muss dem Client ein gültiges Zertifikat präsentieren auf Basis dessen die Verschlüsselung aufgesetzt wird. Zusätzlich muss der Server den zum Zertifikat gehörigen privaten Schlüssel besitzen. Um gültig zu sein, muss das Serverzertifikat von einem vertrauenswürdigen Herausgeber (Root CA) signiert sein. Bei der Konfiguration eines Servers, ist diesem mitzuteilen, welches Zertifikat er bei einer Verbindungsanfrage vorweisen soll.
Vertrauenswürdig heißt hierbei, dass der Client dem Herausgeber vertraut (sprich das Root Zertifikat des Herausgebers ist im Zertifikatsspeicher des Clients installiert).
Gängige Betriebssystem (Windows, Linux, etc.) bringen in ihrem Zertifikatsspeicher schon die Standardzertifikate gängiger Herausgeber (z.B. Let’s Encrypt, Verisign, Comodo) mit.
Für Firmen, welche als eigener (nicht-Standard) Root CA auftreten ist es notwendig das Root Zertifikat im Zertifikatsspeicher des Clients aufzunehmen.
Ein Serverzertifikat ist grundsätzlich für einen spezifischen Server ausgestellt und für eben diesen signiert, kann also von einem Softwarehersteller nicht mitgeliefert werden.
Wichtig in diesem Kontext ist: Zu Zertifikaten erhalten sie ggf. private Schlüssel (.key Datei) oder Sie erhalten Zertifikatsdateien mit integriertem privatem Schlüssel (.pfx Datei). Diese Dateien sind unbedingt geheim zu halten, durch Fremdzugriff auf den Schlüssel sind alle Sicherheitsmerkmale einer HTTPS Verbindung aushebelbar.

Bei der Konfiguration von Conigma Connect wird in der Konfigurationsdatei das entsprechende Zertifikat eingetragen. Ein häufiger Fehler ist dabei, dass eine Zertifikat ohne verfügbaren privaten Schlüssel genommen wird was dazu führt, dass Conigma Connect nicht startet und einen entsprechenden Fehler ausgibt.

Ein weiterer häufiger Fehler ist, dass das Zertifikat nicht die erforderlichen Zwecke enthält. Best Practice ist es, die folgenden Angaben für einen HTTPS-Server zu machen:

keyUsage = digitalSignature, nonRepudiation, keyEncipherment
extendedKeyUsage = serverAuth

Auf nonRepudiation kann verzichtet werden, sollte der Root CA es nicht vergeben.