Wie man einen CSR unter Office 365 erstellt

Diese Anleitung erklärt wie man eine CSR (Certificate Signing Request) für Microsoft 365 (Office 365) erstellt. Die ehrliche Antwort vorab: Sie erzeugen keine CSR für die Microsoft 365 Cloud selbst. Microsoft 365 ist eine gehostete SaaS-Plattform, daher besitzt und verwaltet Microsoft die TLS-Zertifikate für outlook.office365.com, die *.mail.protection.outlook.com Mail-Endpunkte, *.sharepoint.com und die anderen von Microsoft gehosteten Dienste. Es gibt keine Portalseite, die ein vom Kunden bereitgestelltes Zertifikat für diese URLs akzeptiert.

Eine CSR kommt nur dann ins Spiel, wenn Sie zusätzlich einen lokalen oder cloudgehosteten Server betreiben, der sich in Microsoft 365 integriert. Die CSR wird auf diesem Server erzeugt, nicht im Microsoft 365 Admin-Portal. Die folgenden Abschnitte behandeln die Szenarien, in denen das tatsächlich vorkommt.

In welchem Szenario befinden Sie sich?

Wählen Sie die Zeile, die zu dem passt, was Sie tatsächlich absichern möchten, und springen Sie zum entsprechenden Abschnitt:

Was Sie absichern möchten	Wo die CSR erzeugt wird	Abschnitt
Die Microsoft 365 Cloud-Dienste selbst (Exchange Online, SharePoint Online, Teams, outlook.office365.com)	Nirgendwo. Microsoft verwaltet diese Zertifikate.	Warum es keine CSR für die Cloud gibt
Ein lokaler Exchange Server in einer Hybridkonfiguration mit Exchange Online	Auf dem lokalen Exchange-Server (PowerShell oder das EAC bei unterstützten Builds)	Hybrid-Exchange-CSR
Ein AD-FS-Server, der die Anmeldung mit Microsoft 365 / Entra ID föderiert	Auf dem AD-FS-Server (Windows-Zertifikatanforderung)	AD FS / Entra-Föderations-CSR
Eine Azure App Service Web-App, Funktion oder API, die sich mit Microsoft 365 verbindet	Extern erzeugt (mit einem beliebigen Tool), dann zu Azure hochgeladen	Azure App Service CSR
Ein eigenständiger Windows-Webserver (IIS), der nicht Exchange ist, aber zufällig mit Microsoft 365 integriert ist (zum Beispiel ein Portal, ein Hook-Empfänger oder ein Relay)	Im IIS-Manager auf diesem Server	CSR für einen eigenständigen IIS-Server

Warum es keine CSR für die Microsoft 365 Cloud gibt

Microsoft 365 ist eine vollständig gehostete, mandantenfähige Cloud-Plattform. Die TLS-Zertifikate für Exchange Online, SharePoint Online, OneDrive for Business, Microsoft Teams und alle anderen von Microsoft gehosteten Endpunkte werden von Microsoft ausgestellt, bereitgestellt und erneuert. Es gibt keine Seite im Admin Center, kein PowerShell-Cmdlet und keine API, die es einem Mandanten erlaubt, ein Zertifikat eines Drittanbieters für outlook.office365.com, die *.mail.protection.outlook.com Mail-Flow-Endpunkte oder einen anderen von Microsoft besessenen Hostnamen hochzuladen. Das gilt auch dann, wenn Sie eine eigene Vanity-Domain wie contoso.com hinzugefügt haben: Sobald die Domain verifiziert ist, terminiert Microsoft weiterhin TLS für die zugrunde liegenden SMTP-, IMAP-, POP- und HTTPS-Endpunkte, sodass auf Ihrer Seite keine CSR erforderlich ist.

Wenn Ihr Ziel darin besteht, TLS für den Mail-Flow zwischen Microsoft 365 und einem externen Partner zu erzwingen, erreichen Sie das über einen Exchange-Online-Connector, der vom Partner ein gültiges öffentliches Zertifikat verlangt. Auf Ihrer Seite wird kein Zertifikat hochgeladen. Die Schritte für den Connector finden Sie in unserer Microsoft 365 SSL-Installationsanleitung.

CSR für Hybrid-Exchange erzeugen (Exchange Server lokal)

Wenn Sie Ihre CSR bereits auf Ihrem lokalen Exchange-Server erzeugt haben, springen Sie direkt zur Microsoft 365 / Exchange SSL-Installationsanleitung. Andernfalls: Dies ist der häufigste Grund, warum Kunden nach einer „Microsoft 365 CSR“ fragen. In einer Hybridbereitstellung kommuniziert Ihr lokaler Exchange Server (2016, 2019 oder Subscription Edition) über OAuth, EWS und Autodiscover mit Exchange Online, und diese Verbindungen müssen mit einem öffentlich vertrauenswürdigen Zertifikat abgesichert werden. Sie erzeugen die CSR auf dem lokalen Exchange-Server, nicht auf etwas in Microsoft 365.

Auf jedem unterstützten Exchange-Build (und als einziger unterstützter Weg auf Exchange 2016 CU23+ und Exchange 2019 CU12 bis CU14, wo Microsoft die EAC-Zertifikatoptionen entfernt hat) wird die CSR mit PowerShell erzeugt. Führen Sie Exchange Management Shell als Administrator auf dem Server aus, der den privaten Schlüssel enthalten wird, und führen Sie dann Folgendes aus:

New-ExchangeCertificate `
  -GenerateRequest `
  -SubjectName "C=US, S=California, L=San Francisco, O=Example Inc, OU=IT, CN=mail.example.com" `
  -DomainName mail.example.com, autodiscover.example.com `
  -KeySize 2048 `
  -PrivateKeyExportable $true `
  | Set-Content -Path "C:certsexchange.req"

Die zweistufige Verwendung (die Ausgabe des Cmdlets wird an Set-Content weitergeleitet) ist bei aktuellen Builds erforderlich: Das Sicherheitsupdate KB5014278 hat den älteren Parameter -RequestFile aus New-ExchangeCertificate auf Exchange 2016 CU23 und Exchange 2019 CU12 entfernt. Passen Sie die Werte an Ihre Umgebung an:

• C ist der zweistellige Ländercode (US, GB, DE usw.).
• S ist der vollständige Name des Bundeslands oder der Provinz, nicht die Abkürzung.
• L ist die vollständige Stadt oder Ortschaft.
• O ist der rechtlich eingetragene Firmenname.
• OU ist die Abteilung, häufig „IT“. Optional.
• CN ist der primäre vollqualifizierte Hostname, den das Zertifikat absichern soll, zum Beispiel mail.example.com.
• -DomainName ist die durch Kommas getrennte Liste der Subject Alternative Names (SAN). Für eine Hybridbereitstellung sollten Sie mindestens mail.example.com und autodiscover.example.com angeben, plus alle weiteren von Ihnen verwendeten Namensräume (OWA, EWS, Hybrid-Hostnamen).
• -KeySize 2048 entspricht den Basisanforderungen des CA/Browser Forums. Verwenden Sie 4096 nur, wenn Ihre Sicherheitsrichtlinie dies vorschreibt. Microsoft dokumentiert für -KeySize nur die Werte 1024, 2048 und 4096 als gültig, verwenden Sie hier also nicht 3072.
• -PrivateKeyExportable $true ermöglicht es Ihnen, den Schlüssel später für ein Backup zu exportieren oder mit den anderen Knoten in einer DAG zu teilen.

Bei Exchange Server Subscription Edition und Exchange 2019 CU15 ist der EAC-Zertifikatassistent unter Server > Zertifikate wieder als alternativer GUI-Ablauf verfügbar. Die vollständige Schritt-für-Schritt-Anleitung (PowerShell plus EAC-Assistent, mit versionsspezifischen Hinweisen) finden Sie in unserer begleitenden Microsoft Exchange CSR-Anleitung. Verwenden Sie diese Seite für den kanonischen Hybrid-Exchange-CSR-Ablauf; dieselbe CSR funktioniert für das Zertifikat, das Sie den lokalen Exchange-Diensten zuweisen, die sich mit Microsoft 365 verbinden.

Nachdem das Cmdlet ausgeführt wurde, öffnen Sie die Datei .req in Notepad und stellen Sie sicher, dass sie wie ein normaler PEM-Block aussieht:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIC6TCCAdECAQAwgaMxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh
...
-----END NEW CERTIFICATE REQUEST-----

Kopieren Sie den gesamten Block einschließlich der BEGIN- und END-Zeilen (fünf Bindestriche auf jeder Seite) und fügen Sie ihn in das CSR-Feld Ihrer SSL-Bestellung ein. Entschlüsseln Sie ihn zunächst mit unserem CSR-Decoder, um den Common Name, die SANs und die Schlüssellänge vor dem Absenden zu überprüfen.

CSR für AD FS / Entra ID-Föderation mit Microsoft 365 erzeugen

Wenn Sie AD FS (Active Directory Federation Services) verwenden, um die Anmeldung zwischen Ihrem lokalen Active Directory und Microsoft Entra ID (früher Azure AD) für Microsoft 365 Single Sign-On zu föderieren, benötigt der AD-FS-Dienst ein öffentlich vertrauenswürdiges TLS-Zertifikat für seinen Föderationsdienstnamen (zum Beispiel sts.example.com). Dieses Zertifikat wird an den AD-FS-Dienst und an den optionalen Web Application Proxy davor gebunden.

Die CSR wird auf dem AD-FS-Server (oder einem beliebigen Windows-Server) mit dem Zertifikat-Snap-In der Microsoft Management Console oder mit PowerShell erzeugt und dann bei einer öffentlichen CA eingereicht. Erzeugen Sie die CSR entweder mit unserem CSR-Generator (und kombinieren Sie später das ausgestellte Zertifikat und den Schlüssel zu einer .pfx-Datei), oder folgen Sie unserer Windows CSR-Anleitung, um die Anforderung direkt auf dem Server zu erzeugen. Dasselbe Zertifikat wird dann dem AD-FS-Dienst mit Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint <thumb> zugewiesen.

Token-Signierungs- und Token-Entschlüsselungszertifikate innerhalb von AD FS sind ein separates Thema. Sie sind in der Regel selbstsigniert und werden von AD FS selbst automatisch erneuert, sodass Sie dafür keine CSR erzeugen.

CSR für einen Azure App Service erzeugen, der sich mit Microsoft 365 integriert

Wenn Sie eine Web-App, eine Funktion oder eine API auf Azure App Service hosten, die sich mit Microsoft 365 verbindet (ein individuelles Portal, ein SSO-Endpunkt, ein Webhook-Empfänger), sichern Sie deren benutzerdefinierte Domain mit einem Zertifikat ab, das Sie zu Azure hochladen. Azure App Service erzeugt selbst keine CSRs: Sie erzeugen die Anforderung außerhalb von Azure und laden die resultierende .pfx-Datei hoch.

Der einfachste Weg ist unser CSR-Generator: Geben Sie Ihre Daten ein, laden Sie die CSR und den passenden privaten Schlüssel herunter, reichen Sie die CSR bei der CA ein und kombinieren Sie anschließend das ausgestellte Zertifikat, die Zwischenzertifikate und den privaten Schlüssel zu einer .pfx-Datei (PKCS#12). Laden Sie diese .pfx-Datei unter App Service > Zertifikate > Eigene Zertifikate mitbringen (.pfx) hoch und binden Sie sie an Ihre benutzerdefinierte Domain. Wenn Sie einen vollständig serververwalteten Ablauf bevorzugen, erzeugen Sie die CSR auf einer Windows-Admin-Arbeitsstation mit unserer Windows CSR-Anleitung und exportieren Sie das Ergebnis vor dem Hochladen in eine .pfx-Datei. Azure verlangt, dass das Zertifikat die erweiterte Schlüsselverwendung Server-Authentifizierung (OID 1.3.6.1.5.5.7.3.1) enthält, was bei jedem kommerziellen SSL-Zertifikat bereits der Fall ist.

CSR auf einem eigenständigen Windows-/IIS-Server erzeugen

Wenn „Office 365“ in Ihrem Fall eigentlich „ein Windows-Server mit IIS in derselben Umgebung wie Microsoft 365“ bedeutet (zum Beispiel ein Portal, eine Intranet-Site oder ein Nicht-Exchange-Relay), dann erzeugen Sie die CSR im IIS-Manager auf diesem Server. Das ist der Ablauf, den das ursprüngliche Tutorial beschrieben hat. Er ist der richtige Weg für einen generischen IIS-Host, erzeugt aber kein Zertifikat für die Microsoft 365 Cloud, sondern nur für die von Ihnen verwaltete IIS-gehostete Site.

1. Öffnen Sie Start > Windows Verwaltungstools > Internetinformationsdienste (IIS) Manager, oder drücken Sie Win + R, geben Sie inetmgr ein und drücken Sie die Eingabetaste.
2. Wählen Sie im linken Bereich Verbindungen Ihren Servernamen aus.
3. Doppelklicken Sie im mittleren Bereich auf Serverzertifikate.
4. Klicken Sie im rechten Bereich Aktionen auf Zertifikatanforderung erstellen.
5. Füllen Sie im Assistenten Zertifikat anfordern die Felder unter Eigenschaften des definierten Namens wie folgt aus:
   • Allgemeiner Name: der vollqualifizierte Domainname, den Sie absichern möchten, zum Beispiel portal.example.com. Geben Sie nicht outlook.office365.com oder einen anderen von Microsoft besessenen Hostnamen ein.
   • Organisation: der vollständige rechtliche Name Ihres Unternehmens (zum Beispiel Example Inc.).
   • Organisationseinheit: die Abteilung, häufig IT.
   • Stadt/Ort: die Stadt, in der Ihr Unternehmen registriert ist (nicht abkürzen).
   • Bundesland/Provinz: der vollständige Name des Bundeslands oder der Provinz (nicht abkürzen).
   • Land/Region: der zweistellige ISO-Ländercode (US, GB, DE usw.).
6. Klicken Sie auf Weiter.
7. Belassen Sie auf dem Bildschirm Eigenschaften des Kryptografiedienstanbieters den Anbieter bei Microsoft RSA SChannel Cryptographic Provider, setzen Sie die Bitlänge auf 2048 (oder 3072 / 4096, falls Ihre Richtlinie dies erfordert), und klicken Sie dann auf Weiter.
8. Geben Sie einen Dateinamen für die CSR an (zum Beispiel C:certsportal.req) und klicken Sie auf Fertig stellen.

IIS erzeugt über diesen Assistenten keine Subject Alternative Names. Für ein SAN- oder Multi-Domain-Zertifikat erzeugen Sie die CSR mit PowerShell mithilfe einer benutzerdefinierten INF-Datei mit certreq, oder verwenden Sie unseren CSR-Generator und kombinieren Sie später das ausgestellte Zertifikat und den Schlüssel zu einer .pfx-Datei für den Import. Den vollständigen IIS-spezifischen Ablauf mit Screenshots finden Sie in unserer Microsoft IIS CSR-Anleitung.

Öffnen Sie die gespeicherte Datei .req in Notepad und kopieren Sie den vollständigen Block einschließlich der Zeilen -----BEGIN NEW CERTIFICATE REQUEST----- und -----END NEW CERTIFICATE REQUEST----- in das Bestellformular Ihrer CA.

CSR vor dem Absenden überprüfen

Bevor Sie die CSR in das Bestellformular einfügen, entschlüsseln Sie sie, um zu bestätigen, dass die Angaben korrekt sind. Ein Tippfehler im Common Name, ein fehlender SAN oder eine zu kurze Schlüssellänge führt zur Ablehnung der Bestellung oder erzwingt später eine erneute Ausstellung. Fügen Sie die CSR in unseren CSR-Decoder ein, um den Common Name, die vollständige SAN-Liste, die Organisation, das Land, den Signaturalgorithmus und die Schlüssellänge einzusehen.

Sobald die CA die Anforderung validiert und das Zertifikat ausgestellt hat, fahren Sie mit unserer Microsoft 365 SSL-Installationsanleitung für den passenden Installationsschritt fort (Import bei Hybrid-Exchange, AD-FS-Bindung, Azure App Service-Upload oder IIS-Bindung).