MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

ClientAuthentication in Zertifikaten

Mit Zertifikaten können sich Server ausweisen und Clients bei MTLS ebenfalls. Allerdings entfällt bei Zertifikaten für Webserver die Nutzung "ClientAuthentication". Das hat Auswirkungen auf andere Dienste

Worum geht es?

Das "Certification Authority Browser Forum (https://cabforum.org/), in dem Zertifizierungsstellen und Browser-Hersteller (Microsoft, Google, Apple, Mozilla) sich abstimmen, möchten natürlich ein "sicheres Web" ermöglichen. Das bedeutet leider nicht, das die Browser nun Werbetracker unterbinden aber ein Webserver muss sich gegenüber einem Client als Server ausweisen und daher sind die Browser-Hersteller übereingekommen, dass ein Zertifikat auch nur die "Verwendungen" anbieten sollte, die für die Nutzung benötigt werden. Eine Kontrolle der Zertifikate von www.msxfaq.de und support.Microsoft.com am 19. März 2026 zeigt schön den Unterschied:

Die MSXFAQ nutzt noch ein "altes" Zertifikat, welches sowohl "Serverauthentifizierung (1.3.6.1.5.5.7.3.1)" als auch "Clientauthentifizierung (1.3.6.1.5.5.7.3.2)" enthält und die Gültigkeit ist mit 13 Monate auch noch lange. Das Microsoft-Zertifikat hingegen ist nur noch 7 Monate (180 Tage) gültig und hat als "Erweiterte Schlüsselverwendung" nur noch "Serverauthentifizierung (1.3.6.1.5.5.7.3.1)". Die Browser haben damit kein Problem, denn Sie können damit problemlos die Identität des Webservers prüfen. Mehr wird von einem Webserver nicht erwartet.

Vorreiter ist hier wohl Google Chrome, aber Microsoft und Apple folgen in der Regel den Empfehlungen des CA/Browser-Forums.

Öffentliche PKIs

Mit der Ankündigung von Chrome haben sich die PKIs auch entsprechend positioniert und werden die Ausstellung ihrer Zertifikate entsprechend anpassen. Einige PKIs haben  schon einen klaren Zeitplan veröffentlicht. 

CA Name  Default-Zertifikate sind ohne ClientAuthentication Deadline Eraatz

Let’s Encrypt 

Anfang 2026

08. Jul 2026

KEIN

Sectigo

15. Sep 2025

15. Mai 2026

 

DigiCert

01 Okt 2025

01. Mai 2026

 

Trustico

15. Sep 2025

15. Mai 2026

 

SwissSign

?

2 HJ 2026

 

SSL.COM

 

15. Sep 2025

 

Das bedeutet aber nicht, dass diese PKI nicht auch noch Computer-Zertifikate ausstellen würde. Sie müssen bei der Beantragung nur explizit dann diese Zertifikate anfordern und eventuell kostet diese dann etwas mehr als ein reines Webserver-Zertifikat.

Achtung:
Es könnte sein, dass PKIs auch reine Client-Zertifikate ohne ServerAuthentication ausstellen.

Achtung:
Let's Encrypt will gar keine "ClientAuthentication"-Zertifikate mehr ausstellen.
Ending TLS Client Authentication Certificate Support in 2026 https://letsencrypt.org/2025/05/14/ending-tls-client-authentication 

Einfache Webserver-Zertifikate können Sie ja schon länger kostenfrei von Let's Encrypt beziehen aber Let's Encrpt stellt nach dem 8. Juli keine Computerzertifikate mehr aus.

Probleme

Wenn Sie zukünftig ein Zertifikat für einen Webserver beantragen und erhalten, dann wird es ebenfalls nur noch die Schlüsselverwendung "Serverauthentifizierung (1.3.6.1.5.5.7.3.1)" enthalten. Das ist für Webserver auch vollkommen in Ordnung. Allerdings haben die Administratoren und Consultants in den vergangen Jahrzehnten bei einer PKI einfach nur ein "Zertifikat" für Computer gekauft, welche in dem meisten Fällen für Webserver verwendet wurden aber natürlich auch für andere Zwecke genutzt wurden, die nichts mit HTTP/HTTPS zu tun haben. ich denken dabei an

  • Exchange Server mit SMTP-Connectoren
    Wer Zertifikate (empfohlen) statt der Source-IP-Adresse zur Identifizierung des lokalen Exchange Hybrid Servers nutzt, muss darauf achten, dass im Zertifikat auch die ClientAuthentication-EKU enthalten ist. Sonst nimmt Exchange Online die Verbindung nicht an.
  • Direct Routing SIP-Trunks mit Microsoft Teams
    Die Identifizierung eines eigenen Session Border Controllers für einen SIP-Trunk zu Microsoft Teams erfolgt er MTLMS und früher war eine ClientAuthentication-EKU erforderlich.
  • IMAP4/POP3-Server
    Die Vorgaben/Empfehlungen der CA/Browser-Forums beziehen sich primär auf HTTP. Ich erwarte keine Probleme, wenn ein IMAP4/POP3-Client nur eine TLS-Verbindung nutzen möchte aber sich dann normal per Benutzername/Kennwort oder Token anmelden.
  • Radius-Server für 802.1x-Authentifizierung
    Hier wird es wieder interessant, wenn sich Clients mit einem Computer-Zertifikat am Access-Point oder Switch legitimieren. Dann muss die ClientAuthentication-EKU enthalten sein. Allerdings werden die meisten Firmen hier kaum "öffentliche" Zertifikate nutzen, sondern die Client-Zertifikate über eine eigene PKI ausstellen und hier muss der Administrator dann das passende Template bereitstellen.

Bei einer ein internen Kommunikation dürften die meisten Firmen dazu eine Zertifikatsstelle in der eigenen Firma aufgebaut haben. Aber sobald eine externe Kommunikation dazu kommt, müssen Sie quasi öffentliche Zertifikate nutzen. Wer dann sein Exchange Hybrid Mail Routing über Zertifikate absichern will, muss ein Zertifikat mit "Client Authentifizierung" haben.

Schlüsselverwendung ignorieren?

Ein Zertifikat ist im Grund nur eine Datei mit einem öffentlichen Schlüssel, einem Namen, einer Gültigkeitsdauer, einige weitere Daten und einer digitalen Signatur. Der Verwendungszweck ist ebenfalls enthalten aber letztlich entscheiden die Kommunikationspartner, ob sie sich streng an die Vorgaben halten. Wenn ich auf eine Webseite mit einem abgelaufenen oder falschen Zertifikat surfe, dann meldet mit das der Browser und warnt mich aber lässt mir doch die Wahl, ihn zu überstimmen.

Wer die RFCs eng auslegt, wird beim Zertifikat natürlich nicht nur den Namen/SAN-Namen, Aussteller und Gültigkeitszeitraum prüfen, sondern auch die CRL und den KeyUsage. Aber letztlich entscheidet der Empfänger, wie streng er die Prüfung durchführt.

Auch wenn ein Zertifikate ohne ClientEKU eigentlich nicht für MTLS akzeptiert werden sollte, sehe ich das nicht als großes Risiko an.

Produkt Status Informationen

Teams Direct Routing

  

Im Februar 2026 hat Microsoft folgende Änderung veröffentlicht:

Das bedeutet, dass Sie auf ihrem Session Border Controller problemlos auch weiter ein "WebServer-Zertifikat" nutzen können. Microsoft ignoriert seit Feb 2026 einfach die EKU. 

Exchange Hybrid SMTP

  

Beim hybriden Mailrouting können Sie den lokalen Server über ein Zertifikat bei Exchange Online identifizieren. Das ist auch mein bevorzugter Weg. Als Alternative gibt es noch IP-Adressen, was aber knifflig ist, wenn die von Exchange OnPremises verwendete IP-Adresse nicht exklusiv von Exchange genutzt wird. Wenn ihr Exchange Server nun ein neues "Webserver"-Zertifikate ohne Client-EKU bekommt, dann wird das weiter funktionieren.


https://learn.Microsoft.com/en-us/purview/exchange-online-uses-tls-to-secure-email-connections#tls-and-hybrid-exchange-server-deployments

Auch hier besteht also kein Risiko, weil Exchange Online keine ClientEKU erzwingt. Der Exchange OnPremises-Server sendet also auch ein Zertifikate ohne "ClientEKU" an die Gegenstelle und Exchange Online akzeptiert das auch. 

Audiocodes

  

Bei Audiocodes habe ich in der Dokumentation schon einen Schalter gefunden, mit dem ich die Prüfung der EKU abschalten kann. Diese Einstellung gibt es erst ab der Version 7.40A.600.627.

 


Quelle: https://techdocs.audiocodes.com/session-border-controller-sbc/mediant-software-sbc/user-manual/version-740/Content/UM/Configuring-TLS-Certificate-Contexts.htm?Highlight=AllowClientAuthKeyUsage

So können Sie einstellen, dass bei einer eingehenden Verbindung ihr eigener SBC das von der Gegenseite gelieferte Zertifikat zwar weiter hin hinsichtlich Name, Zeitraum, Aussteller, CRl etc. prüft, aber die Key Usage ignoriert wird. Für eine ausgehende Verbindung z.B. zu Teams Direct Routing ist diese Einstellung nicht relevant.

NoSpamProxy 

   Bei SMTP ist die Nutzung von TLS weit verbreitet aber MTLS mit Client-Authentifizierung eigentlich nur ein Thema, wenn ein Server sich so authentifizieren möchte, damit er erweiterte Funktionen nutzen kann. Ansonsten haben meine Kollegen aus dem NoSpamProxy-Team eher die Erfahrung gemacht, dass viele Mailserver auch bei der anonymen Einlieferung per SMTP manchmal ein Zertifikat mitliefern, welches aber oft falsch ist. Eine strenge Prüfung führt hier eher zu "False Positive"-Meldungen und verbessert selten die Spamerkennungsrate.
Daher wird hier die Client-EKU nicht geprüft und selbst der Name u.a. nur, wenn dies explizit vorgegeben wurde, z.B. durch SMTP MTA-STS.

Weitere 

 

Die Liste führe ich gerne weiter. Rückmeldungen und Ergänzungen nehme ich gerne an.

Wenn Sie weitere Produkte kennen, dann addiere ich diese gerne. Bitte aber mit Quellenangabe und Informationen, wie diese Produkte die abweichende Prüfung handhaben.
Kontakt

Gültigkeitsdauer

Auch wenn es nicht der Schwerpunkt dieser Seite ist, möchte ich noch mal daran erinnern, dass sich in den nächsten Jahren auch die Gültigkeitsdauer von Zertifikaten immer weiter bis auf 47 Tage reduziert. Zertifikate für IP-Adressen will Let's Encrypt sogar nur mit 7 Tagen Gültigkeit versehen. Hier werden wir also einen Rund auf ein Zertifikatsmanagement oder AutoEnrollment sehen.

Alternative SelfSigned

Es ist gar nicht mal so abwegig, statt einem öffentlichen Zertifikat oder Zertifikate einer internen PKI einfach ein selbst ausgestelltes Zertifikat zu verwenden. Solche Zertifikate sind natürlich nirgendwo vertrauenswürdig, aber das ist kein Problem, wenn das Zertifikat manuell auf die andere Seite hochgeladen und als vertrauenswürdig klassifiziert werden. Sie glauben das kommt nicht oft vor? Dann Irren sie gewaltig:

  • Entra ID Federation mit ADFS
    Wenn Sie die Anmeldung an Entra ID mit einem lokalen ADFS-Server durchführen, dann laden Sie bei der Einrichtung das "ADFS Signing-Certificate" in ihren Tenant hoch. Das kann problemlos ein selbstsigniertes Zertifikat sein.
  • Exchange Dedicated Hybrid App
    Seit Okt 2025 fragt Exchange OnPremises mittels EWS und später Graph die Frei/Belegt-Zeiten bei Exchange Online an. Auch hier authentifiziert er sich mit dem selbstsignierte "Exchange Server Authentication Certificate"
  • Entra ID Connect DirSync Service Account
    Auch der Nachfolger von ADSync meldet sich mittlerweile nicht mehr mit Benutzername/Kennwort ab, sondern nutzt ein Service principal mit einem Zertifkat
  • Generische Entra ID App
    Die Anmeldung per Zertifikat ist sogar der von Microsoft empfohlene Weg Prozesse zu automatisieren

Allerdings muss die Gegenseite natürlich diesen Weg anbieten und sie müssen zumindest das Zertifikat mit dem öffentlichen Schlüssel der Gegenseite überlassen und dort als "trusted" eintragen.

Weitere Links