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
    Auch die Identifizierung eines eigenen Session Border Controllers für einen SIP-Trunk zu Microsoft Teams macht eine Authentifizierung mit der 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.

Ich habe noch nicht gesehen, dass ich in Exchange OnPremises oder Exchange Online so eine Ausnahme definieren kann. Es wäre sicher wünschenswert, wenn ich z.B. für explizit angegebene CNs oder vielleicht den Hashwert oder die IssuingCA so eine Ausnahme definieren könnte.

Produkt Informationen

Audiocodes

Bei Audiocodes habe ich in der Dokumentation schon einen Schalter gefunden, mit dem ich die Prüfung der EKU abschalten kann


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

Das hilft aber nur, wenn ein anderer SBC sich mit einem "ServerAuthentication"-Zertifikat an meinem SBC anmelden möchte. Es ist aber keine Lösung für den SIP-Trunk zu Microsoft.

 

 

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