Die Webseite der Nordlicht Reisen GmbH läuft in App Service (Lektion 3.7). Jetzt soll sie unter www.example.com erreichbar sein, mit gültigem Zertifikat, regelmäßig gesichert, nur für bestimmte Netze offen und mit einer Vorstufe, auf der neue Versionen geprüft werden, bevor Kundschaft sie sieht. Die Prüfung nennt das: Zertifikate und TLS konfigurieren, einen eigenen DNS-Namen abbilden, die Sicherung einrichten, Netzwerkeinstellungen setzen und Deployment Slots verwenden.
Vorwissen: Wie TLS und Zertifikate funktionieren, steht in K3, Lektion 3.0.4 („TLS und PKI“). Was Front Door und eine Web Application Firewall davor leisten, steht in K3, Lektion 3.3.4. Hier steht, wie Sie das an einer App einstellen. Azure DNS und private Endpunkte behandeln die Lektionen 4.5 und 4.4.
Zertifikate und TLS
Für <app>.azurewebsites.net sorgt Azure selbst: Der Standardname ist durch ein Platzhalterzertifikat gesichert. Eine eigene Domäne braucht ein eigenes Zertifikat. Ihr Plan muss mindestens die Stufe Basic haben.
| Option | Beschreibung |
|---|---|
| App Service Managed Certificate | kostenlos, voll verwaltet, erneuert sich selbst; ausgestellt von DigiCert |
| App Service Certificate | gekauft (laut Microsoft von GoDaddy), liegt in Ihrem Key Vault, exportierbar |
| Import aus Key Vault | Sie verwalten ein PKCS12-Zertifikat im Key Vault (K3, Lektion 3.3.2) |
| PFX hochladen | Sie haben schon ein privates Zertifikat |
Das verwaltete Zertifikat hat Grenzen: keine Wildcards, nicht exportierbar, nicht für private DNS-Zonen, nicht in einer App Service Environment, nur Buchstaben, Ziffern, Bindestriche und Punkte, Domänenname bis 64 Zeichen. Voraussetzungen: Eine Subdomain braucht einen CNAME-Eintrag, der direkt auf <app>.azurewebsites.net zeigt; ein Zwischenziel blockiert Ausstellung und Erneuerung. Eine Apex-Domäne (example.com) braucht einen A-Eintrag auf die IP-Adresse der App, und die App darf keine IP-Beschränkungen haben, weil Ausstellung und Erneuerung die Erreichbarkeit aus dem Internet voraussetzen. Bei manchen Domänen muss ein CAA-Eintrag DigiCert zulassen (0 issue digicert.com). Aussteller und Schlüssel dürfen sich ändern; „pinnen“ Sie das Zertifikat deshalb nicht.
az webapp config ssl create --resource-group <gruppe> --name <app> --hostname www.example.com
az webapp config ssl bind --resource-group <gruppe> --name <app> --certificate-thumbprint <fingerabdruck> --ssl-type SNI
ssl create ist laut Referenz in der Vorschau (preview). Im Portal gehen Sie in der App unter Certificates zu Managed certificates und wählen Add certificate, oder unter Custom domains bei der Domäne Add binding und als Quelle Create App Service Managed Certificate. Erst die Bindung ordnet das Zertifikat der Domäne zu. Es gibt zwei Arten:
| SNI SSL | IP-basiertes SSL | |
|---|---|---|
| Zahl der Bindungen | beliebig viele, mehrere Zertifikate auf einer IP | nur eine; dedizierte IP-Adresse |
| Ab Stufe | Basic | Standard |
| Folgearbeit | keine | A-Eintrag auf die neue IP umstellen |
| Kosten | frei | stündliche Gebühr je IP-basierter Verbindung (manche Standard-Stufen schließen eine ein) |
HTTPS Only leitet HTTP auf HTTPS um (az webapp update --https-only true). Die minimale TLS-Version setzen Sie mit az webapp config set --min-tls-version 1.2. Es gibt zwei getrennte Einstellungen, eine für die App und eine für die Verwaltungsseite (SCM/Kudu); beide sollten 1.2 oder höher sein. Die SCM-Einstellung setzen Sie mit az resource update … --set properties.scmMinTlsVersion=1.2. Microsoft nennt als Frist den 31.05.2027, bis zu der Sie das tun sollten, weil TLS 1.0 und 1.1 dann von der Plattform entfernt werden. Slots haben eigene Einstellungen.