SwissSign Benutzeranforderung schlägt fehl

[gjack]

Hallo zusammen,

ich habe SwissSign als Zertifikatsanbieter neu eingerichtet.
Das Anfordern von Benutzerzertifikaten schlägt benutzerunabhängig fehl.

Die Ereignisanzeige zeigt das Event 8911 bei der Gatewayrolle an.
---------------------------------
In der Beschreibung steht:
Requesting the certificate for CN=xx.xxx@firma.de failed. Error: Unexpected error: Fehler beim Senden der Anforderung.

Message:
Fehler beim Senden der Anforderung.
Error type:
System.Net.Http.HttpRequestException

Error code: 2148734208
Program location:
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
bei Netatwork.NoSpamProxy.Cryptography.SwissSignCertificateProvider.<SendRequestAsync>d__28.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
bei Netatwork.NoSpamProxy.Cryptography.SwissSignCertificateProvider.<EnrollAsync>d__27.MoveNext()

Die Anfrage wurde abgebrochen: Es konnte kein geschützter SSL/TLS-Kanal erstellt werden..
Message:
Die Anfrage wurde abgebrochen: Es konnte kein geschützter SSL/TLS-Kanal erstellt werden..
Error type:
System.Net.WebException

Error code: 2148734217
Program location:
bei System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)
bei System.Net.Http.HttpClientHandler.GetRequestStreamCallback(IAsyncResult ar)
------------------------------

Beim Empfangs- und Sendeconnector ist das gültige Mailserverzertifikat hinterlegt.
Die komplette Zertifikatskette vom RAO-Operatorzertifikat ist importiert.
Im Moment gehen mir die Ideen aus, wo ich noch was prüfen soll bzw. worauf sich der geschützte SSL/TLS-Kanal bezieht.

 

[869288141]

Hallo @gjack,
welche Version von NSP ist aktuell im Einsatz? Ggf. erst einmal noch auf die neuste Version aktualisieren.
Ansonsten wie sieht es mit den Services als Proxy Server, SSL Interception/Inspection auf der Firewall aus?!


Gruß,
Daniel

 

[gjack]

Hi Daniel,

aktuell ist 15.6.0 im Einsatz.
Ich bezweifle, dass ein Update auf 15.7.0 ein Qualitätssprung wäre. Vor allem, da in den Releasenotes nichts in Bezug auf SSL oder TLs vermerkt ist.

Auf der Firewall war IPS aktiviert.
Ich habe das testweise deaktiviert, aber Fehler bleibt.
Proxy Server ist nicht im Einsatz.

 

[gjack]

SSL-Inspection war nicht aktiv und DPI habe ich deaktiviert.
Aber Fehler bleibt.

 

[869288141]

Hallo @gjack,

aktuell ist 15.6.0 im Einsatz.

dann habe ich jetzt die 50/50 Chance. Es gibt zwei Versionen von 15.6.0.x.

In den Release Notes von Version 15.6.0.2731 ist folgenden Bug behoben worden:

Der Anbieter für Schlüsselanforderungen sendet die Attribute „givenName“ und „surname“ nicht in der Anfrage.

Auf der Firewall war IPS aktiviert.

Ich habe das testweise deaktiviert, aber Fehler bleibt.

Ein Blick in die Logs der Firewall hätten auch gereicht.

Ich würde sicherheitshalber die Server mit den Rollen von NSP neu starten. Danach nochmals probieren.
Der Server, welche die Gateway Rolle inne hat, kommt auch über Port 80 bzw. 443 ins Internet?


Gruß,
Daniel

 

[gjack]

Ja, der Server kommt über 80 und 443 ins Internet.
Ok. dann mache ich das Update auf 15.7.0

Wenn natürlich Vor- und Nachname fehlt, ist das ein valider Grund, um ein Zertifikat nicht auszustellen.
Dennoch passt das aus meiner Sicht nicht zu dem Fehler mit dem ungültigen SSl/TSL-Kanal und die Prüfung auf Vorname/Nachname hat zu dem Zeitpunkt laut Fehlermeldung noch gar nicht stattgefunden.

 

[869288141]

Dennoch passt das aus meiner Sicht nicht zu dem Fehler mit dem ungültigen SSl/TSL-Kanal und die Prüfung auf Vorname/Nachname hat zu dem Zeitpunkt laut Fehlermeldung noch gar nicht stattgefunden.

Ich kann es dir von hier aus (aus der Ferne) nicht sagen. Daher kann ich dir leider nur mit Ideen zur Seite stehen.

Du siehst sicherlich im Logfile auf der Firewall welche FQDN/URL versucht wird aufzurufen. Diese würde ich kopieren und auf dem Server mit der Gateway Rolle den Browser starten und manuell versuchen aufzurufen. Somit kannst du fehlende Root- und Intermediate Zertifikate auf dem Server ausschließen. Damit verbunden auch eine Gegenprüfung, ob eine Infrastruktur Komponente den Stream verhindert/aufbricht.

Abgesehen davon, wann hat es das letzte Mal vollumfänglich funktioniert und welche Version von NSP war zu diesem Zeitpunkt im Einsatz?


Gruß,
Daniel

 

[gjack]

Es hat noch nie funktioniert, da bisher kein SMIME zum Einsatz kam.
Die Logfiles der Firewall sind nicht aussagekräftig, da das ein Low Budget Teil ist.

 

[869288141]

Die Logfiles der Firewall sind nicht aussagekräftig, da das ein Low Budget Teil ist.

Alternativ fällt mir Wireshark ein. Da siehst du die volle Adresse.

 

[MichiH]

Moin gjack,

für TLS ist das Betriebssystem zuständig, hast Du da mal geschaut, was dort aktiviert ist? Eventuell sind alte auch Cipher-Suites aktiviert. SwissSign ist das etwas "krüsch", was die TLS Version und die Cipher angeht.
Ich habe auch im Hinterkopf, das die TLS Einstellungen, die Du mit dem NSP setzen kannst, nicht mehr verwendet werden sollten.

Ansonsten stimme ich Daniel zu, Wireshark wäre das Troubleshooting Mittel der Wahl.

 

[JanJäschke]

Hey

Ja der TLS Kanal Fehler deutet erstmal darauf hin, dass es (noch) nixht der behoben Bug ist sondernd ad Netzwerk oder die Server settings.

Per Wireshark und ohne TLS 1.3 kannst du sehen welche cipher möglich wären und ob die Aushandlung korrekt ist. Wenn hier was schief geht wäre das dann ein easy kill.
Firewall dazwischen wäre dann ggf. immer Nachbarin Grund, aber wenn du da nichts siehst hoffen wir einfach mal

Ansonsten wäre das CAPI log noch ein nächster Schritt für die Analyse: das macht nur deutlich weniger Spaß als Wireshark

 

[gjack]

Ich habe einen Zertifikatsrequest mit Wireshark mitgeschnitten und es ist auf jeden Fall eine Kommunikation mit SwissSign möglich.

609 2.589624700 91.194.146.65 192.168.0.215 TCP 66 443 → 55581 [SYN, ACK, ECE] Seq=0 Ack=1 Win=14600 Len=0 MSS=1436 SACK_PERM WS=256
612 2.598239700 91.194.146.65 192.168.0.215 TCP 60 443 → 55581 [ACK] Seq=1 Ack=173 Win=15872 Len=0
645 2.607704800 91.194.146.65 192.168.0.215 TLSv1.2 1514 Server Hello
646 2.607704800 91.194.146.65 192.168.0.215 TCP 1514 443 → 55581 [ACK] Seq=1461 Ack=173 Win=15872 Len=1460 [TCP PDU reassembled in 676]
648 2.607704800 91.194.146.65 192.168.0.215 TCP 1230 443 → 55581 [PSH, ACK] Seq=2921 Ack=173 Win=15872 Len=1176 [TCP PDU reassembled in 676]
674 2.613790500 91.194.146.65 192.168.0.215 TCP 1514 443 → 55581 [ACK] Seq=4097 Ack=173 Win=15872 Len=1460 [TCP PDU reassembled in 676]
675 2.613790500 91.194.146.65 192.168.0.215 TCP 1514 443 → 55581 [ACK] Seq=5557 Ack=173 Win=15872 Len=1460 [TCP PDU reassembled in 676]
676 2.613790500 91.194.146.65 192.168.0.215 TLSv1.2 1514 Certificate, Server Key Exchange
677 2.613790500 91.194.146.65 192.168.0.215 TLSv1.2 87 Certificate Request, Server Hello Done
685 2.630322600 91.194.146.65 192.168.0.215 TCP 60 443 → 55581 [FIN, ACK] Seq=8510 Ack=174 Win=15872 Len=0
693 2.646523000 192.168.0.212 192.168.0.215 DNS 115 Standard query response 0x0a54 A cmc.swisssign.ch CNAME cmc.gslb.swisssign.ch A 91.194.146.65


Im Gateway-Logfile von NSP ist die aufgerufene URL dokumentiert.

Request url is https://cmc.swisssign.ch/ws/cmc?acc...sonal+S/MIME+E-Mail+ID+Silver&amp;validity=1y.

Rufe ich diese URL im Browser auf, erscheint nur "Page not found. Request: i7P-8vBW-I81G"

Kurz und Knapp: Die Firewall ist daher aus meiner Sicht raus.

 

[JanJäschke]

Uhh da klingelt was bei mir
Den Ausschnitt schaue ich mir morgen näher an.

Kannst du dich derzeit mit dem RAO Zertifikat im Web der SwissSign noch anmelden?

Ich suche morgen mal was ich da letztes Jahr noch hatte, aber ich glaube ich hatte das gleiche Bild in unserer Zestumgenung und SwissSign hatte ein neues RAO ausstellen müssen

Denke das finde ich wieder

 

[gjack]

Hi Jan,
ich kann mich mit meiner Mailadresse bei SwissSign im MPKI-Portal https://ra.swisssign.ch anmelden und habe dort auch die Rolle SwissSign MPKI RAO.

Das RAO Zertifikat habe ich heruntergeladen, aber ich weiß nicht, wie und wo man sich damit bei SwissSign anmeldet.
Da könnte ich ein bisschen Schützenhilfe von Dir gebrauchen.

 

[JanJäschke]

Guten Morgen =)

Dein Log Ausschnitt ist leider sehr einseitig xD
Könntest du ggf. das ganze mit mir teilen?
Was gut ist, dass die Kommunikation stattfindet, nun bleibt aber die Frage ob der Zertifikats Handshake korrekt klappt und ob das RAO Klient Zertifikat mit übermittelt wird.

LG
Jan

 

[gjack]

Moin Jan,

ich habe mir den Mitschnitt explizit nach den Handshakes angesehen und die waren alle erfolgreich

611 2.590145100 192.168.0.215 91.194.146.65 TLSv1.2 226 Client Hello (SNI=cmc.swisssign.ch)
==> TLSv1.2 Record Layer: Handshake Protocol: Client Hello

645 2.607704800 91.194.146.65 192.168.0.215 TLSv1.2 1514 Server Hello
==> TLSv1.2 Record Layer: Handshake Protocol: Server Hello

676 2.613790500 91.194.146.65 192.168.0.215 TLSv1.2 1514 Certificate, Server Key Exchange
==> TLSv1.2 Record Layer: Handshake Protocol: Certificate
sowie TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange

677 2.613790500 91.194.146.65 192.168.0.215 TLSv1.2 87 Certificate Request, Server Hello Done
==> TLSv1.2 Record Layer: Handshake Protocol: Certificate Request
sowie TLSv1.2 Record Layer: Handshake Protocol: Server Hello Done

Den Begriff RAO gibt es im gesamten Mitschnitt nicht. Aber das Operatorzertifikat wurde von "SwissSign Private MPKI-Operators ICA 2020-1" ausgestellt und diese Zeichenkette erscheint und in Wirehsark wird noch die Info angezeigt ==> Distinguished Name of a CA that Server Trusts (tls.handshake.dname) 90 Bytes

Ich würde Dir ungern den kompletten Mitschnitt zukommen lassen, denn dort steht alles in Klartext drin ==> Firmenname, SwissSign-Kennung, Benutzerkennung, etc.

Viele Grüße

 

[JanJäschke]

Dann schaumal beim Client müsste in der Verbindung eine Client Identität / Zertifikat übergeben werden, ist das wirklich drin?
Das ist das RAO Zertifikat und du kannst es dir mehr oder weniger komplett anschauen.

Ich habe aber heute durch Stefan erfahren, dass die SwissSign wohl derzeit teilweise Probleme in der CMC Schnittstelle hat.
Ich denke es lohnt sich somit auf jeden Fall ein Ticket bei denen zu eröffnen.

Das du den Mitschnitt nicht teilen möchtest ist ok

 

[gjack]

Hallo Jan,
danke für die Rückmeldung.
Ich habe nun direkt an den MPKI-Support von SwissSign geschrieben und diese um Unterstützung gebeten.

Außerdem sollen die prüfen, ob bei denen meine Zertifikatsanfragen sichtbar sind und warum diese aus Sicht von SwissSign abgelehnt wurden.
Dann sehen wir weiter.

 

[gjack]

Der SwissSign-Support hat bereits eine Rückmeldung gegeben.

Es wurden zwei Probleme identifiziert:
1. In der MPKI wurde noch nicht die Domain validiert, für die Zertifikate ausgestellt werden sollen.
2. Das RAO-Zertifikat wird nicht übermittelt.

In den SwissSign-Logs steht aktuell die Meldung „client sent no required SSL certificate". Das bedeutet, dass bei der Anfrage kein Client-Zertifikat bei SwissSign ankommt. Für die Nutzung der CMC-Schnittstelle ist es jedoch zwingend erforderlich, dass ein gültiges Auto-RAO-Zertifikat als Client-Zertifikat mitgesendet wird. Ohne Übermittlung des Client-Zertifikats scheitert die Anfrage bereits auf TLS-Ebene, unabhängig vom eigentlichen Zertifikatsantragsprozess.

Die Validierung der Domain habe ich angestoßen. Damit wäre Punkt 1 vermutlich morgen oder übermorgen erledigt.

Punkt 2 macht mir aber Sorgen.

Warum wird das RAO-Zertifikat nicht übertragen, obwohl es in NSP korrekt implementiert ist?
Muss ich also doch auf 15.7 updaten und hoffen, dass es damit geht?

Oder hast Du noch andere Ansätze, Jan?