-
Start
-
- Artikel in Kürze
-
Exchange Server
-
Exchange Hybrid
-
Exchange Online
-
- Artikel in Kürze
Selbstsigniertes Zertifikat für Entra App-Registrierung erstellen
Zweck
Dieser Artikel erklärt, wie du mit PowerShell ein selbstsigniertes Zertifikat für eine Entra App-Registrierung (zertifikatsbasierte Authentifizierung) erstellst und es für Export und Weitergabe vorbereitest. Er richtet sich an Situationen, in denen ein Client Secret aus Sicherheits- oder Compliance-Gründen durch ein Zertifikat ersetzt werden soll, beispielsweise für App-Only-Zugriffe auf Exchange Online oder Microsoft Graph.
Voraussetzungen
Um das Zertifikat zu erstellen, benötigst du lokale Administratorrechte auf dem System, da es üblicherweise im persönlichen Zertifikatsspeicher des Benutzers oder des Computers gespeichert wird. Für den Export als PFX ist außerdem ein starkes Passwort erforderlich, das den privaten Schlüssel schützt. PowerShell Version 5.1 oder höher reicht aus, da das Cmdlet New-SelfSignedCertificate im PKI-Modul enthalten ist und auf Windows-Systemen standardmäßig vorhanden ist. Für den Upload in Entra ID benötigst du entweder die Rolle Application Administrator oder Cloud Application Administrator, oder Besitzrechte an der jeweiligen App-Registrierung.
Schritte
Zertifikat erstellen
Erstelle das Zertifikat mithilfe von New-SelfSignedCertificate und achte dabei besonders auf den Subject-Namen, den Schlüsselalgorithmus und die Gültigkeitsdauer.
$certParams = @{
Subject = "CN=EntraApp-GraphAccess"
CertStoreLocation = "Cert:\CurrentUser\My"
KeyExportPolicy = "Exportable"
KeySpec = "Signature"
KeyLength = 2048
KeyAlgorithm = "RSA"
HashAlgorithm = "SHA256"
NotAfter = (Get-Date).AddMonths(12)
}
$cert = New-SelfSignedCertificate @certParams
$cert.Thumbprint
Namensschema für den CN
Der Subject-Name (Common Name, CN) sollte nicht willkürlich gewählt werden. Er muss erkennen lassen, wer das Zertifikat erstellt hat und wofür es bestimmt ist. Das ist besonders wichtig, wenn du als externer Dienstleister bei einem Kunden arbeitest und dort mehrere Admins und Dienstleister gleichzeitig Zertifikate für unterschiedliche App-Registrierungen erstellen. Ein aussagekräftiger CN erleichtert die spätere Zuordnung erheblich, insbesondere wenn im Entra Admin Center nur der Anzeigename ohne zusätzlichen Kontext sichtbar ist.
Ein übliches Schema verbindet das persönliche Kürzel oder den Namen des Admins mit dem Firmennamen des Dienstleisters und optional dem Verwendungszweck. Für John Doe von Varunagroup könnte der CN beispielsweise so gestaltet sein:
$certParams = @{
Subject = "CN=Varunagroup-JDoe-GraphAccess"
CertStoreLocation = "Cert:\CurrentUser\My"
KeyExportPolicy = "Exportable"
KeySpec = "Signature"
KeyLength = 2048
KeyAlgorithm = "RSA"
HashAlgorithm = "SHA256"
NotAfter = (Get-Date).AddMonths(12)
}
$cert = New-SelfSignedCertificate @certParams
$cert.Thumbprint
Alternativ reicht je nach Umgebung auch nur der Firmenname im CN, etwa CN=Varunagroup-EntraApp-GraphAccess, wenn die Zuordnung zu einer einzelnen Person weniger relevant ist als die Zuordnung zum Dienstleister als Ganzes. Wichtig ist vor allem, dass das gewählte Schema innerhalb eines Kundenumfelds konsistent verwendet wird, damit beim Blick in die Zertifikatsliste einer App-Registrierung sofort klar ist, wer für die Erstellung und Rotation verantwortlich ist.
Laufzeit bewusst wählen
Die Gültigkeitsdauer eines selbstsignierten Zertifikats liegt ganz in deiner Verantwortung. Dabei solltest du beachten, dass ein zu langes Ablaufdatum, wie fünf oder zehn Jahre, zwar im Alltag bequem ist, weil man sich lange nicht um eine Erneuerung kümmern muss, in der Praxis jedoch oft dazu führt, dass niemand mehr weiß, wofür das Zertifikat verwendet wird, wenn es irgendwann abläuft oder erneuert werden muss. Hingegen verursacht ein zu kurzes Ablaufdatum unnötigen Aufwand und erhöht das Risiko von Produktionsausfällen, falls die Rotation im laufenden Betrieb vergessen wird.
Ein optimaler Kompromiss für produktive App-Registrierungen liegt meist zwischen zwölf und vierundzwanzig Monaten, abgestimmt auf einen dokumentierten Rotationsprozess und idealerweise unterstützt durch einen Kalendereintrag oder eine Monitoring-Regel, die rechtzeitig vor Ablauf alarmiert. Nutze NotAfter, um das Ablaufdatum explizit festzulegen, anstatt dich auf den Standardwert von einem Jahr zu verlassen, den New-SelfSignedCertificate ohne diesen Parameter verwendet. Die Laufzeit sollte zusammen mit dem Verwendungszweck direkt bei der Zertifikatserstellung dokumentiert werden, damit spätere Administratoren nachvollziehen können, warum genau dieser Zeitraum gewählt wurde.
Public-Zertifikat exportieren
Für den Upload in die Entra-App-Registrierung wird ausschließlich der öffentliche Schlüssel im CER-Format benötigt. Exportiere ihn mit Export-Certificate.
Export-Certificate -Cert $cert -FilePath "C:\Temp\EntraApp-GraphAccess.cer"
Diese Datei enthält keinen privaten Schlüssel und kann gefahrlos weitergegeben werden, etwa an ein Entra-Team, das den Upload in eine App-Registrierung vornimmt, auf die du selbst keinen Zugriff hast.
PFX mit privatem Schlüssel exportieren
Für die Nutzung auf der Client-Seite, beispielsweise in einem Automatisierungsskript oder in einer Runbook-Umgebung, ist der private Schlüssel erforderlich. Exportiere dazu die PFX-Datei mit einem sicheren Passwort. Dieser Export dient auch der Sicherung des Zertifikates.
$pfxPassword = ConvertTo-SecureString -String "EinStarkesPasswort!23" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath "C:\Temp\EntraApp-GraphAccess.pfx" -Password $pfxPassword
Das PFX-Passwort sollte niemals im Klartext in Skripten oder Tickets gespeichert werden. In Produktionsumgebungen empfiehlt es sich, das Passwort in einem Passwort-Tresor oder Key Vault zu verwalten, anstatt es direkt im Skript, wie hier zum Demonstrationszweck gezeigt, einzugeben.
Verifikation
Nach dem Upload zeigt Entra ID im Abschnitt ‚Zertifikate und Geheimnisse‘ der App-Registrierung den Fingerabdruck und das Ablaufdatum des hochgeladenen Zertifikats an. Stelle sicher, dass der Fingerabdruck mit dem lokal erzeugten Zertifikat übereinstimmt.
Get-ChildItem -Path "Cert:\CurrentUser\My" | Where-Object { $_.Subject -eq "CN=Varunagroup-JDoe-GraphAccess" } | Select-Object Thumbprint, NotAfter
Führe anschließend einen Testaufruf mit dem Zertifikat durch, etwa eine Authentifizierung gegen Microsoft Graph mit Connect-MgGraph, um zu bestätigen, dass die zertifikatsbasierte Authentifizierung tatsächlich funktioniert und nicht nur der Upload erfolgreich war.
Connect-MgGraph -ClientId "ENTRA_APP_CLIENT_ID" -TenantId "TENAT_ID" -CertificateThumbprint $cert.Thumbprint
Bekannte Probleme und Hinweise
Ein häufige Fehler besteht darin, bei der Erstellung die Einstellung KeyExportPolicy = „Exportable“ zu vergessen. Das Zertifikat kann dann problemlos als CER exportiert werden, doch ein PFX-Export schlägt fehl, da eine Fehlermeldung zum privaten Schlüssel erscheint. In solchen Fällen muss das Zertifikat neu erstellt werden, da eine nachträgliche Änderung der Exportierbarkeit nicht möglich ist.
Wenn das Zertifikat im Computer-Store statt im Benutzer-Store abgelegt wird, muss die Automatisierung, die es nutzt, auch die entsprechenden Zugriffsrechte auf diesen Store haben. Das gilt besonders für geplante Aufgaben oder Dienste, die unter einem anderen Konto laufen als das Benutzerkonto, mit dem das Zertifikat erstellt wurde.
Wenn du die CER-Datei an ein anderes Entra-Team weitergibst, solltest du vorher klären, ob dort ein bestimmtes Namensschema für Zertifikatsanzeigenamen erforderlich ist, um die korrekte Zuordnung zur App-Registrierung später sicherzustellen.