Zertifikatsmanagement mit Azure Automation und Let's Encrypt
Das Projekt Let’s Encrypt hat die Internet Landschaft nachhaltig geprägt. Kostenlose SSL-Zertifikate für Jedermann lassen sich automatisiert erstellen und durch Let’s Encrypt signieren. Durch die breite Akzeptanz durch Browser Hersteller und Cross-Signierung sind die Zertifikate fast überall gültig.
Eine Automatisierungslösung ist durch die kurze Laufzeit von drei Monaten jedoch zwingend erforderlich. Mittels PowerShell in Azure Automation lässt sich ein Workflow erstellen der sich um die Zertifikats-Erneuerung und sichere zentrale Speicherung kümmert. Dieser Workflow ist die optimale Grundlage um die Zertifikate an den eigentlichen Service weiter zu verteilen.
Die Grundlage für eine solche Automatisierungslösung bietet AzAutomation-PoshACME
AzAutomation-PoshACME baut auf mehreren bestehenden Komponenten auf und nutzt diese für einen komplett automatisierten Zertifikatsworkflow.
- Let’s Encrypt
Signiert die erstellten Zertifikate - Azure Automation
Als Basis der Automatisierung in einer server-less Umgebung - Posh-ACME
Die unglaublich tolle Implementierung des ACME Protokolls von Ryan Bolger @rmbolger - Azure DNS
Ohne einen DNS Service der API Unterstützung anbietet ist dieses Vorhaben nicht zu realisieren.
DNS Infrastruktur
Leider gibt es in der sogenannten Enterprise IT immer noch sehr viele Gründe warum eine DNS Zone nicht per API geändert werden kann.
Diese Gründe reichen von organisatorischen Hürden wer die Zone verwaltet, bis hin zu technischen Problemen, wenn der DNS Provider leider keine API anbietet.
Um diese Querelen von Anfang an aus dem Weg zu gehen, hat AzAutomation-PoshACME volle Unterstützung für CNAME Redirection eingebaut.
CNAME Redirection
Unter CNAME Redirection versteht man bei der ACME Validierung das Umleiten der Validierungsanfrage in eine andere DNS Zone. Dies kann eine Subzone des bestehenden DNS Servers sein oder eine komplett andere DNS Zone.
Subzone
In diesem Beispiel wurde unterhalb der DNS Zone “cloudbrothers.info” eine zusätzliche Subzone “levalidation.cloudbrothers.info” angelegt. Der Nameserver Record für diese Zone wurde auf den Azure DNS geändert.
Für die Domain “test.cloudbrothers.info” soll ein Zertifikat erstellt werden. Bei der Validierung wird Let’s Encrypt prüfen ob die Challenge im DNS TXT Record “_acme-challenge.test.cloudbrothers.info” korrekt ist.
Der DNS Eintrag wird mittels eines CNAME Records umgeleitet auf “_acme-challenge.test.cloudbrothers.info.levalidation.cloudbrothers.info”, einem Eintrag in der von Azure verwalteten Subzone.
Dieses Verhalten ermöglicht es für einzelne Records Zertifikate auszustellen ohne die gesamte Root DNS Zone des Unternehmens unter die Kontrolle des Zertifikatsaustellenden zu geben. Jedoch muss für jedes Domäne die ein Zertifkat erhalten soll manuell ein CNAME Record für die ACME Challenge angelegt werden. Dies ist jedoch eine einmalige Aktion.
Andere DNS Zone
In diesem Fall wird nicht eine Subzone unter die Kontrolle des Azure DNS gegeben, sondern eine komplett eigene Domäne.
Die Funktionsweise ist dieselbe, jedoch wird so verhindert das unterhalb der Root Zone des Unternehmens weitere DNS Einträge erstellt werden können.
Azure Komponenten
Die Azure Komponenten beschränken sich auf ein Minimum:
- Resource Group
- DNS Zone
- Storage Account
- Azure Automation Account
- Runbooks
Da für die Automatisierung Azure Automation genutzt wird, sind keine eigenen Compute Ressourcen notwendig
Aufbau der Umgebung
Alle notwendigen Ressourcen können über das Git Repository des Projekts bezogen werden. https://github.com/f-bader/AzAutomation-PoshACME
git clone https://github.com/f-bader/AzAutomation-PoshACME
cd .\AzAutomation-PoshACME\
code .
Hinweis:
Aktuell wird aufgrund der genutzten signierten Zertifikate ausschließlich Windows PowerShell unterstützt!
Deploy Ressources
Das Skript “DeployRessources.ps1” enthält alle notwendigen Kommandos um die notwendigen Ressourcen zu erstellen. Das Skript hat einen Workshop Character und ist Schritt für Schritt zu auszuführen und nicht in einem Rutsch.
Umgebungsvariablen
Im oberen Bereich müssen die Umgebungsvariablen für deine Umgebung angepasst werden.
- ResourceGroupName
Der Name der zu erstellenden Resource Group - Location
In welcher Azure Region die Ressourcen erstellt werden sollen. Der Standard ist West Europa - DNSZoneRootDomain
Welche DNS Zone soll für die Validierung genutzt werden. Für diese Zone wird eine Azure DNS Zone angelegt - MailContact
An welche E-Mail Adresse soll Let’s Encrypt Informationen bei ablaufenden Zertifikaten senden. - BlobStorageName
Der Name des Storage Accounts. Er darf nur Kleinbuchstaben und Zahlen enthalten und muss Weltweit eindeutig sein. - AutomationAccountName
Der Name des Azure Automation Accounts. Standard ist “LetsEncryptAutomation” - PfxPass
Welches Kennwort soll für die exportierten PFX Dateien genutzt werden? Dieser Wert wird verschlüsselt im Azure Automation Account hinterlegt.
Aufbau der Umgebung
Nachdem die Umgebungsvariablen initialisiert sind und der Block PowerShell Code mit F8 ausgeführt wurde ist es an der Zeit sich mit Azure zu verbinden.
|
Der nächste Befehl erstellt die notwendige Resource Group
|
Im nächsten Schritt wird die DNS Zone angelegt.
|
Dabei ist wichtig, dass die DNS Nameserver für diese Zone beim Registrar der Zone oder in der Subzone hinterlegt werden. Nur so weiß Let’s Encrypt das Azure DNS diese Zone verwaltet.
Insgesamt werden vier Nameserver ausgegeben
Für die Speicherung der Zertifikate wird nun ein Storage Account angelegt und der Zugriff auf HTTPS only beschränkt. Außerdem wird ein SASToken für den späteren Zugriff auf den Storage Account aus Azure Automation erstellt.
|
Damit die Runbooks des Automation Account später auch die DNS Zone verwalten erstellt das Skript eine Entra ID (Azure AD) Applikation und einen Service Principal.
|
Im Azure Portal wird diese Applikation als “Let’s Encrypt Certificate Automation” geführt
Der Service Principal erhält die Rolle “DNS Zone Contributor” auf die erstellte DNS Zone.
|
Der Automation Account wird mit diesem Befehl erstellt
|
Für die Authentifizierung von Azure Automation an Azure erstellt das Skript ein selbst signiertes Zertifikat und speichert es im Kontext des aktuell angemeldeten Benutzer.
|
Dieses Zertifikat wird als PFX (Private + Public Key) exportiert.
|
Der public Teil des Zertifikats wird als Teil einer Entra ID (Azure AD) Application Credential in der Applikation “Let’s Encrypt Certificate Automation” für die Authentifizierung hinterlegt.
|
Jetzt wird der private Schlüssel als Automation Certificate im Azure Automation Account hinterlegt
|
Mit diesem Zertifikat kann sich Azure Automation gegenüber Azure authentifizieren
Für die vereinfachte Anmeldung innerhalb der Runbooks wird eine Azure Automation Connection erstellt. Diese enthält alle notwendigen Informationen für die Anmeldung.
Das sind die Application Id, die TenantId, der Zertifikats-Thumbprint und die SubscriptionId.
|
Die nächste Code Region, nicht hier abgebildet, installiert die notwendigen Module in den Azure Automation Account.
- Az.Accounts
- Az.Resources
- Az.Storage
- Posh-ACME
|
Wenn gewünscht kann der folgende Code in ein Runbook kopiert werden und damit der Verbindungsaufbau und die Modulverfügbar geprüft werden.
|
Damit die Runbooks später auch die definierten Standardwerte nutzen können werden diese in Azure Automation Variablen gespeichert.
- PAServer
Dieser Wert definiert welche Let’s Encrypt Umgebung genutzt werden soll. Der Standard ist die Staging Umgebung (LE_STAGE)
Wenn gültige Zertifikate ausgestellt werden sollen, muss dieser Wert auf “LE_PROD” geändert werden! - ACMEContact
Der definierte Standard E-Mail Kontakt - StorageContainerSASToken
Der verschlüsselte Wert für den Zugriff auf den Storage Account - BlobStorageName
Der Name des Blob Storage - PfxPass
Das verschlüsselte Passwort für die PFX Dateien - WriteLock
Standard ist “$false”. Diese Variable verhindert das mehr als ein Runbook schreibenden Zugriff auf die Konfigurationsdaten erhalten.
|
Die letzte Code Region kopiert alle Runbooks aus dem Unterordner “runbooks” in den Azure Automation Account. Unbedingt darauf achten das die PowerShell Session im richtigen Ordner ist.
|
Im nächsten Teil dieser Blogreihe werden die zwei Runbooks “New-LetsEncryptCertificate” und “Update-LetsEncryptCertificates” besprochen.