Konfiguration von SSL-Zertifikaten in SharePoint (Schritt für Schritt)
In diesem strukturierten Blogartikel wird für IT-Administratoren, der Schritt für Schritt erklärt, wie SSL-Zertifikate in Microsoft SharePoint konfiguriert werden. Der Fokus liegt auf einer typischen On-Premises Farm (z. B. SharePoint 2016 / 2019 / Subscription Edition).

Einleitung
In modernen Unternehmensumgebungen ist die Absicherung von Webdiensten über HTTPS heute Standard. Auch bei einer SharePoint-Farm sollte der Zugriff ausschliesslich über verschlüsselter Verbindungen erfolgen.

SSL/TLS schützt:

• Authentifizierungsdaten
• Session-Cookies
• Dokumente und Unternehmensdaten
• API-Kommunikation zwischen Client und Server

Dieser Artikel zeigt praxisnah, wie ein SSL-Zertifikat korrekt in einer SharePoint-Umgebung installiert und konfiguriert wird.

Architekturüberblick
Bevor mit der Konfiguration begonnen wird, ist es wichtig zu verstehen, wo SSL in einer SharePoint Umgebung implementiert wird.
Die TLS-Terminierung erfolgt in der Regel im Webserver (IIS).

Typische Architektur:

Client Browser │ HTTPS (443) │ Load Balancer / Reverse Proxy (optional) │ IIS Web Front End (WFE) │SharePoint Web Application

SSL muss daher primär auf den Web Front End Servern (WFE) eingerichtet werden.

Voraussetzungen
Bevor mit der Konfiguration begonnen wird, müssen folgende Punkte erfüllt sein:

1. Zertifikat vorhanden

   Ein Zertifikat muss von einer Trusted Certificate Authority (CA) ausgestellt sein.

Typische Quellen

• interne Unternehmens-PKI
• öffentliche CA (z. B. Digicert)

Das Zertifikat wird meist als PFX-Datei bereitgestellt.

portal.company.com.pfx

 

2. DNS-Eintrag vorhanden

Der DNS-Name muss existieren:

portal.company.com

Test:

nslookup portal.company.com

3. Firewall Port
   Port 443 muss erreichbar sein.

Schritt 1 – Zertifikat auf dem Server importieren

Das Zertifikat muss im Windows Zertifikatsspeicher installiert werden.

Methode über MMC

1. mmc.exe starten
2. Certificates Snap-in hinzufügen
3. Computer Account auswählen
4. Navigieren zu:

Certificates (Local Computer) → Certificates → Personal

Danach importieren:

Right Click → Import

PFX-Datei auswählen und Passwort eingeben.

Schritt 2 – Zertifikat überprüfen

Kontrollieren:

• Zertifikat ist gültig
• Private Key vorhanden
• Zertifikatkette vollständig

Test über PowerShell:

Get-ChildItem Cert:\LocalMachine\My

Wichtig:

HasPrivateKey : True

Schritt 3 – IIS Binding konfigurieren

Nun wird das Zertifikat mit der Website verbunden.

IIS Manager öffnen

Inetmgr

Navigation:

Sites → SharePoint – 80

oder

SharePoint Web Application

Dann:

Bindings → Add

Konfiguration:

Type: https Port: 443 Host Name: portal.company.com SSL Certificate: auswählen

Schritt 4 – SharePoint Alternate Access Mapping prüfen
SharePoint muss wissen, dass HTTPS verwendet wird. Central Administration öffnen:

Application Management → Configure Alternate Access Mappings

URL prüfen:

https://portal.company.com

Falls nötig bearbeiten.

Schritt 5 – Web Application auf HTTPS umstellen
Falls die Web Application noch auf HTTP läuft:

Central Administration:

Manage Web Applications

Web Application auswählen.

Dann:

Extend Web Application

Neue Zone erstellen:

Zone: Default URL: https://portal.company.com Port: 443

Schritt 6 – HTTP auf HTTPS weiterleiten

Damit Benutzer automatisch auf HTTPS umgeleitet werden, empfiehlt sich eine Redirect Regel.

In IIS:

HTTP-Redirect

oder via URL Rewrite.

Beispiel:

HTTP-Redirect

http://portal.company.com ↓ https://portal.company.com

Schritt 7 – Funktionstest

Jetzt sollte HTTPS funktionieren.

Test im Browser:

https://portal.company.com

Kontrollpunkte:

• Schloss Symbol sichtbar
• Zertifikat gültig
• keine Mixed Content Warnungen

Schritt 8 – Zertifikat Ablauf überwachen
Ein häufiger Betriebsfehler ist ein abgelaufenes Zertifikat.

Empfehlung
Monitoring einrichten.
Beispiel PowerShell:

Get-ChildItem Cert:\LocalMachine\My |
Select Subject, NotAfter Oder Monitoring über:

• System Center Operations Manager
• Azure Monitor
• PRTG

Typische Fehlerquellen
Symptom: Zertifikat besteht ohne Private Key

SSL Binding nicht möglich

falscher Hostname
Zertifikat:
Symptom:

portal.company.com

Aufruf:

sharepoint.company.com

→ Zertifikatsfehler.

Zertifikatkette fehlt
Intermediate CA fehlt → Browser Warnung.

Best Practices
Erprobte Empfehlungen aus Enterprise-Umgebungen:

• Wildcard Zertifikate nur wenn nötig
• dedizierte Zertifikate für kritische Portale
• automatisiertes Zertifikatsmonitoring
• Zertifikatserneuerung 30 Tage vorher planen
• HTTPS erzwingen (kein HTTP)

Fazit
Die Konfiguration eines SSL-Zertifikats in SharePoint ist technisch nicht kompliziert, erfordert jedoch saubere Abstimmung zwischen:

• DNS
• Zertifikatsverwaltung
• IIS-Konfiguration
• SharePoint Alternate Access Mapping

Wird dies strukturiert umgesetzt, erhält man eine sichere und stabile HTTPS-Infrastruktur für SharePoint.

Wie wird das Zertifikat auf dem SharePoint GUI eingebunden?
In diesem Kapitel wird beschrieben wie auf dem klassischen GUI-Weg in SharePoint, als wie man ein Zertifikat für eine WebApplication direkt über die SharePoint Central Administration einbindet. Das ist die Methode, die man im GUI sieht, wenn z.B. «Alternate Access Mappings» oder HTTPS konfiguriert wird.

1️⃣ SharePoint Central Administration öffnen

• Öffne Central Administration
• Gehe zu “Application Management” → “Manage web applications”

2️⃣ WebApplication auswählen

• Klicke die gewünschte WebApplication an (z. B. via-versicherung-config)
• Oben in der Ribbon-Leiste “Bindings” auswählen

3️⃣ HTTPS Binding hinzufügen

• Klicke “Add HTTPS Binding” (oder „Edit“ für bestehendes)
• Dialogfeld:

Feld	Beschreibung
IP Address	Feste IP oder All Unassigned
Port	Standard 443
Host Header	z. B. via-versicherung-config.grctoolbox.ch
SSL Certificate	Zertifikat auswählen aus Local Computer → Personal → Certificates
Require Server Name Indication (SNI)	Haken setzen → entspricht SSLFlags 64

• Klicke OK / Save

4️⃣ Änderungen übernehmen

• SharePoint schreibt die Änderungen in IISSettings der WebApplication
• IIS erhält das Binding automatisch
• SNI wird gesetzt, das Zertifikat wird direkt in SYS registriert

5️⃣ Prüfen im IIS

• Öffne IIS-Manager → Sites → WebApplication
• Unter Bindings sieht man:
  • IP
  • Port
  • Host Header
  • SSL-Zertifikat
  • Eventuell SNI Flag

Tipp: Wenn du mehrere HTTPS-Sites auf demselben Port laufen hast, muss SNI aktiviert sein, sonst liefert IIS immer das erste Zertifikat.

6️⃣ Praktischer Hinweis

• Legacy TLS wird hier nicht gesetzt – dafür muss man auf der Server-Ebene die Registry oder DSC/PowerShell nutzen.
• Das GUI erlaubt nur bestehende Zertifikate aus LocalMachine → Personal.
• SharePoint verwaltet selbst keine neuen Zertifikate, sie müssen vorher importiert sein.

🔹 SharePoint Binding – interne Struktur

In diesem Kapitel wird die Visualisierung gezeigt, wie SharePoint das Zertifikat intern in WebApp → IISSettings → Bindings speichert, inklusive SSLFlags und Thumbprint.
Da sieht man genau, wie die GUI hinter den Kulissen auf die IIS- und SNI-Ebene abbildet.

SharePoint WebApplication │ ├─ IISSettingsCollection │ ├─ IISSetting (z.B. für Server1) │ │ ├─ Bindings │ │ │ ├─ Binding 1 │ │ │ │ ├─ IPAddress : 10.10.10.20 oder AllUnassigned │ │ │ │ ├─ Port : 443 │ │ │ │ ├─ HostHeader : via-versicherung-config.grctoolbox.ch │ │ │ │ ├─ CertificateThumb : A1B2C3D4… │ │ │ │ ├─ CertificateStore : My │ │ │ │ └─ SSLFlags : 64 (SNI) │ │ │ │ │ │ │ └─ Binding 2 │ │ │ └─ … (z.B. default site, SSLFlags 84) │ │ │ │ │ └─ Other IISSetting Properties │ │ │ └─ IISSetting (für Server2) │ └─ Bindings … │ └─ WebApp Properties (Name, URL, AAM, etc.)

 

🔹 Ablauf beim GUI-Zertifikat-Einbinden

1. WebApplication auswählen → Bindings öffnen
2. GUI schreibt das Binding in IISSettings → Bindings
   • Hier wird die IP, Port, HostHeader, Thumbprint, Store gesetzt
3. SSLFlags setzen
   • SNI → sslFlags = 64
   • Legacy TLS Flags → ggf. 84 für default
4. IIS erhält Binding über Central Admin
   • Intern wird das Binding in applicationHost.config angelegt
   • HTTP.SYS registriert das Zertifikat
5. IIS liefert beim Aufruf der URL das richtige Zertifikat
   • HostHeader + SNI entscheiden, welches Zertifikat verwendet wird

Hinweis: Wird das Zertifikat über den IIS oder PowerShell eingebunden, wird der SNI standardmässig auf 0 gesetzt und die Konfiguration wäre somit nicht richtig angesetzt.

🔹 Zusammenhang GUI ↔ IIS ↔ HTTP.SYS

Ebene	Zuständigkeit
SharePoint GUI	definiert Binding → schreibt in SharePoint Config DB
IIS-Manager	zeigt Binding → spiegelt SharePoint-Einstellung wider
HTTP.SYS	Kernel Listener → liefert Zertifikat aus LocalMachine\My auf Port 443

<🔹 Praktische Beobachtung

• Wenn du Legacy TLS deaktivierst oder SSLFlags anpasst, wirkt das nur auf IIS/HTTP.SYS
• GUI aktualisiert nur die WebApp-Definition, nicht die TLS-Flags
• Darum ist es in vielen Farms üblich, GUI + PowerShell/DSC zu kombinieren

💡 Merksatz:

GUI = SharePoint Config → SNI / Zertifikat hinterlegt
IIS = Umsetzung auf Site-Level → zeigt Binding
HTTP.SYS = liefert Zertifikat → final für Browser

Zu welchem Zeitpunkt aktualisiert die GUI, die Einträge in der WebApplikation?

In diesem Kapitel wird beschrieben wie das Timing und die Art, SharePoint die Bindings in der Konfigurationsdatenbank speichert und an IIS überträgt.

🔹 Zeitpunkt der GUI-Aktualisierung

1. Du änderst etwas im GUI (z. B. HTTPS Binding oder Zertifikat)
2. Beim Klick auf “OK” / “Save”:
   • SharePoint speichert die Änderung sofort in der Config DB der WebApplication
   • Gleichzeitig wird ein IIS-Update angestoßen für die entsprechende WebApp
3. IIS übernimmt das Binding
   • Intern wird applicationHost.config angepasst
   • HTTP.SYS registriert das Zertifikat für den Listener
4. Browser kann noch altes Zertifikat sehen, wenn:
   • IIS noch nicht vollständig aktualisiert wurde
   • HTTP.SYS noch das alte Binding cached
   • DNS/Proxy/Caching auf Client-Seite das alte Zertifikat liefert

🔹 Warum manchmal noch das alte Zertifikat auftaucht SharePoint GUI allein erzwingt keinen Flush des HTTP.SYS Cache Alte Bindings bleiben temporär aktiv, bis IIS den Listener aktualisiert Browser kann Zertifikat cachen → besonders bei Edge / IE

🔹 Praxis-Tipps, damit GUI-Änderungen sofort greifen

IIS Reset vermeiden, nur App Pool neu starten

iisreset /noforce

oder nur AppPool neu starten:

Stop-WebAppPool -Name "SharePoint WebApp Pool"
Start-WebAppPool -Name "SharePoint WebApp Pool"

HTTP.SYS Cache flushen

net stop http /y
net start http

→ nur auf Testservern; produktiv vorsichtig!

1. Browser-Cache leeren oder neues Private-Window nutzen
2. Optional: Bindings via PowerShell setzen
   • Dann ist man sicher, dass SSLFlags und Thumbprint korrekt übernommen wurden
   • GUI zeigt nur die Config, PowerShell / DSC schreibt direkt in IIS + HTTP.SYS

⚠️Vorsicht:
Bei manchen Schritten, wenn man direkt in den Kernel-Layer von Windows (http.SYS) eingreift oder IIS kurzfristig stoppt – kann das produktive Webseiten oder Dienste kurzzeitig unerreichbar machen.

Konkret bedeutet das:

🔹 Risiken auf produktiver Umgebung

1. Stoppen mittels PowerShell Kommando

net stop http
net start http

• Stoppt alle HTTP-Listener auf dem Server
• Alle Websites und Services, die HTTP/S nutzen, gehen kurz offline
• In einer SharePoint-Farm könnten z.  auch Service Applications oder Central Admin betroffen sein

1. iisreset /noforce

iisreset /noforce

• Stoppt und startet alle IIS-Websites
• Kurzzeitiger Ausfall aller WebApps

1. Registry oder SSLFlags direkt ändern

• Falsche Werte → IIS kann Bindings nicht laden
• Browser zeigt Zertifikatfehler oder HTTP 503

🔹 Best Practice

• Änderungen zuerst auf Testserver durchführen
• Nur gezielt den betroffenen App Pool neu starten

Restart-WebAppPoool -Name „SharePoint – WebApp Pool“

• Browser Cache / DNS Flush testen, bevor produktiv gearbeitet wird
• Bei Farmen: Änderungen nur auf einem Server testen → dann auf andere Nodes replizieren

💡 Merksatz:

Eingriffe in HTTP.SYS oder SSLFlags wirken global auf alle Sites. Ein Fehler kann temporär den gesamten SharePoint-Webzugriff blockieren. Im allgemeinen «SharePoint GUI speichert sofort, aber der Kernel (HTTP.SYS) liefert das alte Zertifikat noch, bis Listener/Cache aktualisiert ist»

🔹 Schritt-für-Schritt Methode (Produktionssicher)

1️⃣ GUI-Änderung durchführen

• In Central Admin → Manage Web Applications → Bindings
• HTTPS Binding auswählen oder erstellen
• Zertifikat auswählen aus Local Computer → Personal
• SNI aktivieren wenn nötig → GUI speichert in SharePoint Config DB

2️⃣ Nur betroffenen App Pool neu starten

• Anstatt IIS oder HTTP.SYS global zu resetten:

  # Beispiel um einen spezifischen WebApp Pool zu starten:
  $AppPool = "SharePoint - WebApp Pool"Restart-WebAppPool -Name $AppPool
  Write-Host "Spezifischer WebApp Pool '$AppPool' wurde neu gestartet und steht wieder zur Verfügung"

• Vorteil: nur diese WebApp kurz nicht erreichbar, andere Sites laufen weiter

3️⃣ SSLFlags kontrollieren & ggf. korrigieren

Möchte man die bestehenden gesetzten SSLFlags kontrollieren kann man folgende PowerShell Kommandozeilen verwenden.

Import-Module WebAdministration

$site   = "SharePoint2019SE - config"
$host = "compedia-config.sharepoint.one"
$ip     = "10.10.10.10" # oder AllUnassigned

# aktuelles Binding auslesen
$binding = Get-WebBinding -Name $site -Protocol https -HostHeader $host

# SSLFlags setzen (64 = SNI SharePoint-kompatibel)
if ($binding.sslFlags -ne 64) {
Set-ItemProperty "IIS:\SslBindings\$ip!443!$host" -Name sslFlags -Value 64
Write-Host "SSLFlags für $site/$host auf 64 gesetzt"
} else {
Write-Host "SSLFlags für $site/$host korrekt"
}

4️⃣ Zertifikat prüfen

• Optional: sicherstellen, dass Thumbprint + Store korrekt sind

  (Get-WebBinding -Name $site -Protocol https -HostHeader $host).certificateHash
  (Get-WebBinding -Name $site -Protocol https -HostHeader $host).certificateStoreName

5️⃣ Browser testen

• Private/Inkognito-EDGE Window verwenden
• URL aufrufen → Browser zeigt das neue Zertifikat
• Kein globaler IIS-Reset nötig → Sites bleiben online

✅ Vorteil dieser Methode

• Keine globale Unterbrechung (IIS oder HTTP.SYS bleibt aktiv)
• SSLFlags und Zertifikat direkt gesetzt → garantiert, dass Browser korrekt das neue Zertifikat nimmt
• Minimaler Eingriff, farm-sicher

🔹 Zertifikat Prüfskript – nur lesen

Was liefert dieses Script?

• Tabellarische Übersicht aller WebApps + HTTPS-Bindings
• HostHeader, IP, Port, SSLFlags
• Zertifikat Thumbprint + Store
• Warnungen, wenn SSLFlags oder Zertifikat nicht korrekt vorhanden sind

Import-Module WebAdministration

$results = @()

# Alle HTTPS Bindings durchlaufen
Get-WebBinding -Protocol https | ForEach-Object {

    $site   = $_.ItemXPath.Split("'")[1]
    $host   = $_.HostHeader
    $ip     = $_.bindingInformation.Split(':')[0]
    $port   = $_.bindingInformation.Split(':')[1]

    # Zertifikat aus IIS SslBindings ermitteln
    $cert = Get-ChildItem "IIS:\SslBindings" | Where-Object {
        $_.IPAddress -eq $ip -and $_.Port -eq $port -and $_.Sites -match $site
    }

    $certThumb = if ($cert) { $cert.Thumbprint } else { "Kein Zertifikat gefunden" }
    $certStore = if ($cert) { $cert.Store } else { "-" }

    $results += [PSCustomObject]@{
        Site        = $site
        HostHeader  = $host
        IP          = $ip
        Port        = $port
        SSLFlags        = $_.sslFlags
        CertThumb   = $certThumb
        CertStore       = $certStore
    }
}

# Übersicht ausgeben
$results | Sort-Object Site, HostHeader | Format-Table -AutoSize

# Warnungen markieren (nur lesen, keine Änderungen!)
$results | ForEach-Object {
    if ($_.HostHeader -like "*default*" -and $_.SSLFlags -ne 84) {
        Write-Host "⚠️ SSLFlags für default ungewöhnlich:" $_.Site $_.HostHeader $_.SSLFlags -ForegroundColor Yellow
    }
    elseif ($_.HostHeader -like "*config*" -and $_.SSLFlags -ne 64) {
        Write-Host "⚠️ SSLFlags für config ungewöhnlich:" $_.Site $_.HostHeader $_.SSLFlags -ForegroundColor Yellow
    }
    if ($_.CertThumb -eq "Kein Zertifikat gefunden") {
        Write-Host "⚠️ Kein Zertifikat gefunden:" $_.Site $_.HostHeader -ForegroundColor Red
    }
}

💡 Hinweis:

Dieses Script verändert nichts, es liest nur die Konfiguration aus SharePoint + IIS.
So kann vor jeder Änderung geprüft werden, ob alles richtig eingerichtet ist, bevor z. B. SSLFlags oder Zertifikate aktiv korrigiert werden.

 

Weitere Blogartikel über: Automatisierte SSL-Prüfung mit PowerShell für SharePoint Farms Zero-Downtime Zertifikatswechsel in SharePoint Troubleshooting SSL Fehler in SharePoint (Real-World Cases)

 

Verwandte Beiträge

Keine verwandten Beiträge gefunden.