Serverzertifikate

[ulbrichf]

Moin,
zur verschlüsselten Kommunikation werden Serverzertifikate genutzt.
Damit es zu keinen Problemen kommt, sollte bei der Beantragung auf einige Einstellung geachtet werden.
Für SSL/TLS Verschlüsselung ->

Anwendungsfall : Serverzertifikat
Schlüssellänge : mindestens 2048 bit
Laufzeit : sollte gültig sein 2 - 4 Jahre und zur Laufzeithälfte erneuern.
Signaturalgorithmus : sha256rsa

Servername / URL  :  CN
Servername / URL  :  Alternative Subject Name (ASN) wird auch "Alternative Antragsteller Name" genannt 

Wichtig ist, dass das Zertifikat auf die Domäne ausfgestellt ist, dessen Webseite aufgerufen werden soll.
Um RFC konform zu sein (chrome kontrolliert das, IE nicht) muß der Eintrag des CN im ASN wiederhalt werden.
Ist man nicht RFC konform, gibt es Fehlermeldung bei einigern Browsern oder Programmen.

In ASN können noch weitere Einträgen hinzugefügt werden... z.B. IP Adresse.

Hier der CN (Common Name)

2018-12-26_20h21_11.png

Hier der Eintrag des wichtigen ASN (Alternative Subject Name)

2018-12-26_20h20_39.png

[ulbrichf]

Wenn der CN/ASN nicht paßt, verhalten sich einige Programme unfreundlich und man muß den Zertifikatscheck abschalten, damit es weiter geht.

2018-12-26_20h41_32.png

2018-12-26_20h43_59.png

[Klaus]

Lieber Frank,
wir sind uns durchaus der Funktionsweise von Serverzertifikaten bewusst (schliesslich mache ich das beruflich). Das SSL-Zertifikat zur Verschlüsselung der API-Kommunikation ist für alle Teilnehmerserver das gleiche, deshalb ist es nicht vorgesehen dort den common-name eingetragen zu haben. Es ist ja auch ein self-signed Zertifikat, d.h. du hast sowieso nicht den passenden CA public key in deinem Client.
Ein Zugriff mit dem Webbrowser ist aber auch nur zu Testzwecken geeignet.
Grüße,
Klaus

P.S. Schau Dir doch auch mal an. Mehr zur Api und was da geplant ist, kann Paul sagen.

[Paul]

Lieber Frank,
wir sind uns durchaus der Funktionsweise von Serverzertifikaten bewusst (schliesslich mache ich das beruflich). Das SSL-Zertifikat zur Verschlüsselung der API-Kommunikation ist für alle Teilnehmerserver das gleiche, deshalb ist es nicht vorgesehen dort den common-name eingetragen zu haben. Es ist ja auch ein self-signed Zertifikat, d.h. du hast sowieso nicht den passenden CA public key in deinem Client.
Ein Zugriff mit dem Webbrowser ist aber auch nur zu Testzwecken geeignet.
Grüße,
Klaus

P.S. Schau Dir doch auch mal an. Mehr zur Api und was da geplant ist, kann Paul sagen.

Das ist soweit richtig.

Das Zertifikat ist self-signed, wird aber trotzdem geprüft:
Die Teilnehmersever bauen generell nur https Verbindungen mit Servern auf, die das Serverzertifikat liefern (Die CA enthält nur das Serverzertifikat).
Es gibt in der Konfiguration für den Teilnehmerserver eine Option nur Zugriffe mit dem Serverzertifikat als Client-Zertifikat zuzulassen, diese ist aber standartmäßig ausgeschaltet, da diese die API "privat" machen würde und die Sicherheit nur begrenzt erhöhen würde, da die "Adminfunktionen" sowieso zusätzlich mit einem Passwort geschützt sind.

Wenn du sichergehen möchtest, dass du mit einem Teilnehmerserver verbunden bist kannst du dir das Serverzertifikat runterladen und bei https Zugriffen als CA verwenden.
Das ist aber, solange du nicht die "privaten Funktionen" verwendest (und deine Pin überträgst), sowieso nicht wirklich notwendig.

Ich schreibe bei Gelegenheit mal eine Dokumentation zu der API, wenn ich fertig bin schicke ich dir gerne einen Link.

Grüße,
Paul

[ulbrichf]

Ich wollte hier niemanden negativ kritisieren, nur darauf hinweisen, das sich Applikationen teilweise intolerant verhalten, wenn Serverzertifikate abgelaufen sind, bzw. CN oder ASN nicht stimmen. Programmiertechnisch muss dann getrickst werden.
Ich selbst hatte Probleme mit meiner eigenen Webpräsenz mit nicht stimmigen ASN und nicht Zuständen kommenden CITRIX Verbindungen. Hatten den Beitrag nur allgemein in die Welt gesetzt und wollte auf keine Personen zielen.

Mit freundlichen Grüßen
Frank

[Klaus]

Hallo Frank,
es fühlt sich, glaube ich, niemand angegriffen oder negativ kritisiert. Ich hatte meinen Post ja auch extra freundlich angefangen um das zum Ausdruck zu bringen und die Weihnachtliche Stimmung nicht zu beeinträchtigen. Ich habe auch nur geantwortet, weil du meinen Hostnamen in deinem Beispiel verwendest. Sowohl beim debug-output als auch in dem leicht verunschärften Screenshot, den man aber trotzdem lesen kann :-)
Aber wenn du mit dem Webbrowser mal auf die reguläre Seite von telexgateway gehst, wirst du feststellen, dass die Zertifikate dort stimmen. Nur auf dem Port für die Teilnehemerserver-Api (die dort übrigens auch nur im Testbetrieb läuft) wird ein anderes Zertifikat zur Verschlüsselung und Authentifizierung der Teilnehmerserver untereinander verwendet. (aus oben genannten Gründen) Das lässt sich zwar mit dem Webbrowser testen - ist aber nicht Sinn und Zweck des Ganzen. Primär geht es um den Abgleich der Teilnehmerserver. Sekundär können im public Bereich auch Daten von extern abgerufen werden - wo Du die CA dafür bekommst um das auch zu authentifizieren und nicht nur zu verschlüsseln und welche api-endpoints es geben wird, schreibt Paul demnächst. Ich habe wie gesagt mit dem Teilnehmerserver, den Paul in den letzten 1,5 Jahren mit 3 stelligem Mt. Aufwand programmiert hat, eigentlich selber nichts zu tun.

Beste Grüße,
Klaus