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.

 

[JanJäschke]

@Thomas hier der funktionierende PowerShell part:

# NSP Verbindung aufbauen
Connect-Nsp -IgnoreServerCertificateErrors

# auflisten aller ausgehenden Konnektoren - Name und ID nachfolgend benötigt
Get-NspOutboundSendConnector

# holen der Dispatcher LISTE für einen Konnektor
$dispatchers = (Get-NspOutboundSendConnector -Name "Default connector for outbound mails").Dispatchers

# setzen des TLS Thumbprints für den ersten Dispatcher - DNS Zustellung hat nur einen
($dispatchers[0]).TlsCertificateThumbprint = "MY_THUMBPRINT"

# prüfen ob korrekt gesetzt
$dispatchers

# updaten der NSP Konfiguration
Set-NspOutboundSendConnector -Id 1 -Dispatchers $dispatchers -Smtp

 

[Thomas]

Das kam für mich leider zu spät. Ich habe nun in Verzweiflung (und weil mir euer Sven Lippe auch nur den Fehler bestätigen aber keine Lösung nennen konnte) ein teures DigiCert Zertifikat gekauft, das Client Auth noch beinhaltet. Damit war die Sache in 5 Minuten erledigt. Ob das Script funktioniert, habe ich daher nicht ausprobiert. Ich habe es aber ohnehin mit 3 Konnektoren zu tun: ein- und ausgehende Sendekonnektoren sowie den Empfangskonnektor - so einfach wäre es dann wohl ohnehin nicht geworden.

In jedem Fall ist eine geharnischte Mail an euch unterwegs - die Zusatzkosten für das Zertifikat und die Stunden an Diagnoseaufwand wären echt vermeidbar gewesen. Spätestens, wenn ab 1. Mai auch DigiCert keine Zertifikate mit Client Auth mehr ausstellt und Kunden mit ihren ausgelaufenen Zertifikaten an die Wand rennen, dürfte bei euch die Bude brennen. Vielleicht bekommt die Sache dann die nötige Eskalationsstufe und Aufmerksamkeit des Produktmanagements.... (Hallo, Herr Cink... long time no speak . Früher hatten wir solche Sachen noch unkompliziert am Telefon gelöst... da waren Sie noch PM und es lief gut...)

Ich bin jetzt seit 20 Jahren Kunde, Partner und Anwender von NoSpamProxy, aber so ein ignorantes Vorgehen habe ich bislang nicht erlebt.

 

[JanJäschke]

Hallo Thomas,

schade das es zeitlich aus deiner Sicht nicht mehr gereicht hat.
Zur Aufarbeitung deiner Punkte habe ich mir grade einmal alle notwendigen Informationen angeschaut.
Ich muss gestehen bis auf den Punkt das UI seitig das Problem nach 5 Monaten noch nicht in der veröffentlichten Version behoben wurde, kann ich deine Punkte beim besten Willen nicht nachvollziehen.

Ich erkläre dir auch sehr gerne warum:
Wir haben über den Blogbeitrag welcher im initialen Post verlinkt ist den Grundstein für die Informationswelle an unsere Kunden gelegt.
Mit dem Beitrag hier im Forum wurde die Information umgehend auf einem zweiten Kanal weiter gestreut.
Dieser Blogbeitrag wird per RSS Feed in der NCC angezeigt, damit konntest du ab dem 24.10.2025 in der NCC im RSS Feed dies bereits sehen. Ab dem 28.11.2025 wurden dann unsere Partner/Reseller ebenfalls mit über diesen Blogbeitrag informiert - du stehst auf der Newsletter Liste und hast unseren Informationen nach die E-Mail entsprechend empfangen.
Damit gibt es ein breites Spektrum, über welches wir explizit dich informiert haben.
Gegenüber unseres Supports hast du den Blogbeitrag als nicht hilfreich eingestuft da sich dieser ausschließlich an "M365 bzw. NSP Cloud Lösungen" richte. Hier solltest du den Beitrag bitte noch einmal in Ruhe lesen denn es wird ausdrücklich über "[...] NoSpamProxy Cloud-Kunden als auch NoSpamProxy Server-Kunden [...]" gesprochen und wir gehen auch explizit auf "Alle Kunden, die ihre O365-Zertifikate nicht automatisch über NoSpamProxy beziehen oder in eigenen Konnektoren auf TLS-Client-Authentifizierung angewiesen sind, sollten prüfen, welche der folgenden Optionen für sie in Frage kommt [...]" ein.

Anhand des Support Tickets welches du gestern Nachmittag eröffnet hast kann ich nachvollziehen, dass dein altes Zertifikat noch bis zum 20.02.2026 gültig ist. Da ich dir gestern Abend mitgeteilt habe (wohl bemerkt in meiner Freizeit, auf einer keinem offiziellen Support Weg), dass ich keinen Zugriff mehr auf einen NSP habe und grob abgerissen habe was zu tun bzw. wie du dein Problem potenziell erst einmal umgehen kannst, hättest du auch reagieren können und fragen können, ob du heute entsprechende Hilfe von mir oder wem anderes erwarten kannst. Der gefragt PowerShell Code kam dann ja auch heute Morgen um 07:55 Uhr. Das Snippet ist für Ein-, Aus- und Empfangs Konnektoren gültig und sollte dies beispielhaft darlegen. Da du nichts weiter beschrieben hast bin ich erst einmal vom Ausgehenden Konnektor ausgegangen und die CmdLets für Inbound sind identisch. Unter der Annahme, dass dein Problem wirklich zeitkritisch ist (Ablauf des Zertifikates gestern/heute) hatte ich dir Sogar noch einen temporären Lösungsvorschlag aufgezeigt, da es im On-Prem Segment wenig Grund gibt auf ein Client Zertifikat zu setzen, dies scheinst du aber schlicht ignoriert zu haben.

Deine Vorwürfe des "schuldhafte Verschlampen" (Ticket) des "nicht warnen, still ignoriert" (Ticket) der anscheinend fehlenden Eskalationsstufe und Aufmerksamkeit (Beitrag oben) konnte ich nun hoffentlich aus dem Wege räumen.
Viel mehr solltest du deine eigene Struktur hinterfragen: Wo ist das Monitoring deiner Zertifikate? Warum hast du den RSS-Feed nicht gelesen? Warum hast du den Newsletter nicht gelesen? (Für den man sich separate anmelden muss wohl bemerkt)
Herr Cink hat in diesem Thema noch gar nichts verloren, es freut mich, dass du langjähriger Kunde bist und ihr euch lange kennt, aber das Thema ist bei mir als Produktmanager wohl früh genug angebracht worden und ich hoffe an dieser Stelle auch mehr als ausreichend aufgearbeitet worden. Anbei hattest du versucht unseren Support auch gestern telefonisch zu erreichen?

Ich gebe an dieser Stelle gerne mit, dass kein Kunde im Mai Angst haben muss, denn in Q1 wird v16 veröffentlicht und in dieser ist in der NCC die Umstellung wieder machbar.
Außerdem nehme ich diesen Beitrag von dir zum Anlass den RSS Feed noch einmal nach oben pushen zu lassen.
Zudem werde ich mich dafür einsetzen, dass deine Kosten nicht übernommen werden.
Ich denke jeder unserer Kunde, grade die langjährigen, wissen, dass man mit uns sprechen kann und auch, dass wenn es eng wird wir den Schritt weiter gehen. Aber die Art die du hier angebracht hast, finde ich dem Produkt, Unternehmen und auch den Kollegen gegenüber nicht gerechtfertigt.

Deine Meinung ist gerne gesehen. Im Ticket wirst du noch eine schriftliche Antwort zum Thema, der Aufarbeitung sowie der Kostenübernahme bekommen.


Beste Grüße und einen schönen Abend,
Jan
Produkt Manager NoSpamProxy

 

[Thomas]

Hallo Jan,

ich will den Thread hier nicht ausufern lassen, deshalb antworte ich außerhalb des Forums. Vielleicht telefonieren wir auch einfach mal oder treffen uns auf ein Bier - ich denke, dann lassen sich die Standpunkte und Ansichten schnell wieder aufeinander einpendeln

Herzliche Grüße
Thomas