CAs stellen Support für TLS Client Authentifizierungs-Zertifikate ein

[JanJäschke]

Hallo zusammen,

der ein oder andere hat es vlt. schon mit bekommen: CAs stellen derzeit die Ausstellung von TLS Zertifikaten mit der Schlüsselverwendung "TLS CLient Auth" ein.
Wir haben dazu eben einen Blogbeitrag veröffentlicht:

Ende der TLS-Client-Authentifizierungszertifikate | NoSpamProxy

Ab sofort dürfen CAs in TLS-Zertifikaten nicht mehr gleichzeitig beide Extended Key Usages (EKU) id-kp-clientAuth und id-kp-serverAuth verwenden. Wer betroffen ist und was Sie jetzt tun sollten.

www.nospamproxy.de

Dieser Thread soll zum einen dazu dienen diese Information zu streuen und für Rückfragen da sein.

Beste Grüße,
Jan

 

[mabu]

Hallo Jan.

Schön, dass es diesen Beitrag hier gibt. Den ich auch gleich mal für Rückfragen zum Blogeintrag nutze.

Muss zugeben, dass ich nicht sicher bin, ob es irgendwie für uns von Relevanz ist - liegt hoffentlich an der heute nicht wirklich guten Tagesform bei mir. Verzeiht daher die möglicherweise technisch nicht absolut korrekte Beschreibung in der Frage, die nun folgt.

NSP ist On-Prem. Keine Nutzung von O365.

Es gibt für den NSP ein TLS-Zertifikat, welches für das Portal und auch auf den Konnektoren genutzt wird.

Bei diesen ist das im Blogeintrag beschriebene Szenario ja nicht zutreffend, oder? Wir benutzen das Zertifikat ja nicht direkt für die Authentifizierung.

Bin gerade nicht sicher, ob ich hier ein ToDo für uns übersehe. Glaube es aber nicht.

Danke vorab für die Antwort.

 

[Sören]

Glaube es aber nicht

Es betrifft lediglich Client Auth. Kein impact bei dir.

 

[M.Wichmann]

Hallo Jan,

ich habe nun bei dem ersten Kunden ein neues Sectigo Zertifikat angefordert und habe natürlich nur ein TLS Server-Authentifizierungszertifikat bekommen.
Dies kann ich beim ausgehenden Sendeconnector nicht auswählen, gibt es eine Möglichkeit das zu ändern?
Die Umgebung ist rein OnPrem. Es wird nur Protection genutzt.

Vielen Dank im Voraus.
M.Wichmann

 

[JanJäschke]

@M.Wichmann
Ich kann es leider grade nicht gegenprüfen, aber per PowerShell kannst du die aktuelle Konfiguration des Konnektors holen, in einer Variablen speichern, dann solltest du dein neues Zertifikat hitnerlegen können, glaube es ist nur der Thumbprint und kannst dann mittels Set das Objekt wieder schreiben
Die NCC filtert derzeit auf die TLS Client Auth Attribute.

 

[Thomas]

Die NCC filtert derzeit auf die TLS Client Auth Attribute.

Hhhmmm... mich erwischt es eben gerade: Mein neues Zertifikat (ohne Client Auth) wird im NCC nicht angezeigt. Sicherlich bin ich nicht der erste mit diesem Problem. Wie GENAU geht man jetzt vor?

 

[Fabian]

Ich stand vor den selben Problem und habe auf die Lösung von NSP und deren Angebot mit Let's Encrypt gewechselt.

Damit war der Server zufrieden (nach Beantragung und Zuweisung an den O365 Konnektor).

Nicht vergessen bei den EXO Konvektor den Filter anzupassen!

Für die anderen Konvektoren ist es ja optional, in Richtung ausgehend), sofern Bedarf besteht ein passendes besorgen, sonst weglassen!

LG
Fabian

 

[JanJäschke]

Hhhmmm... mich erwischt es eben gerade: Mein neues Zertifikat (ohne Client Auth) wird im NCC nicht angezeigt. Sicherlich bin ich nicht der erste mit diesem Problem. Wie GENAU geht man jetzt vor?

Ich habe für heute leider keinen Zugriff mehr auf meine Umgebung, falls du zwanghaft auf dem Konnektor eins brauchst:
Es gibt ein Get-NspOutboundConnector… CmdLet. Die Ausgabe in einer variable speichern. Dann anschauen, es ist glaube ich nur der thumbprint der drin steht, den in der variable überschrieben und dann mit dem Set-NspOitboundConnector… CmdLet setzen. Gleiches gilt auch für inbound.

LG

 

[Thomas]

@Fabian: how ist kein O365 im Spiel, alles On-Premises. Geht die Lösung mit lets-encrypt auch damit? Wenn ja, wo gibt es eine genaue Anleitung?

@Jan: ich habe schon einiges mit dem cmd-lets gemacht, scheitere aber daran, dass er das Zertifikat schlichtweg als "NotForUse" betitelt, weil die Client-Auth darin fehlt.

Aber mal im Ernst: Das Problem ist seit 5 Monaten bekannt und es gibt hier noch keine dokumentierte, saubere Lösung?? Ich hoffe ernsthaft, ich bin nur zu blöd zum Suchen... (Ach, ja, ich habe gerade noch zur Sicherheit das allerneueste 15.7er Update installiert.)

Viele Grüße
Thomas

 

[JanJäschke]

@Fabian: how ist kein O365 im Spiel, alles On-Premises. Geht die Lösung mit lets-encrypt auch damit? Wenn ja, wo gibt es eine genaue Anleitung?

@Jan: ich habe schon einiges mit dem cmd-lets gemacht, scheitere aber daran, dass er das Zertifikat schlichtweg als "NotForUse" betitelt, weil die Client-Auth darin fehlt.

Aber mal im Ernst: Das Problem ist seit 5 Monaten bekannt und es gibt hier noch keine dokumentierte, saubere Lösung?? Ich hoffe ernsthaft, ich bin nur zu blöd zum Suchen... (Ach, ja, ich habe gerade noch zur Sicherheit das allerneueste 15.7er Update installiert.)

Viele Grüße
Thomas

Wenn du on-prem bist:
Temporär vom Zertifikat weg wechseln?
In einer Single tenant Umgebung gibt es ja nur bedingt Mehrwert auf den SAN zu gehen.

Nein du bist nicht zu blöd. Es sollte schon längst ein Update dazu geben, dass Thema eskaliert auch derzeit intern.