🥇Auf dem Weg zur Automatisierung der SSL-Ausstellung

Oft sind wir mit SSL-Zertifikatenkonfrontiert. Lassen Sie uns den Prozess der Erstellung und Installation eines Zertifikats (im Allgemeinen für die meisten) in Erinnerung rufen.

Einen Anbieter finden (eine Website, auf der wir SSL kaufen können).
CSR generieren.
Dieses an den Anbieter senden.
Besitz des Domains bestätigen.
Zertifikat erhalten.
Das Zertifikat in das benötigte Format umwandeln (optional). Zum Beispiel von pem in PKCS #12.
Das Zertifikat auf dem Webserver installieren.

Relativ schnell, nicht kompliziert und verständlich. Diese Methode ist durchaus geeignet, wenn wir maximal ein Dutzend Projekte haben. Aber was ist, wenn es mehr sind und jedes mindestens drei Umgebungen umfasst? Klassisch dev — staging — production. In diesem Fall sollten wir über die Automatisierung dieses Prozesses nachdenken. Lassen Sie uns das Problem etwas genauer betrachten und eine Lösung finden, die in Zukunft den Zeitaufwand für die Erstellung und Wartung von Zertifikaten minimiert. Der Artikel wird eine Problemanalyse und eine kleine Anleitung zur Replikation enthalten.

Ich möchte gleich zu Beginn klarstellen: Unsere Hauptspezialisierung liegt auf .net, insbesondere IIS und anderen Windows-bezogenen Technologien. Daher wird der Kunde ACME und alle damit verbundenen Aktionen aus der Perspektive der Nutzung von Windows beschrieben.

Für wen ist das relevant und einige Ausgangsdaten

Unternehmen K, in der Person des Autors. URL (zum Beispiel): company.tld

Projekt X ist eines unserer Projekte, bei dem ich zu dem Schluss kam, dass wir uns zwingend in Richtung maximaler Zeitersparnis im Umgang mit Zertifikaten bewegen müssen. Dieses Projekt hat vier Umgebungen: dev, test, staging und production. Dev und test befinden sich auf unserer Seite, staging und production auf der Seite des Kunden.

Eine Besonderheit des Projekts ist, dass es eine große Anzahl von Modulen gibt, die als Subdomains verfügbar sind.

Das bedeutet, wir haben folgendes Bild:

Dev
Test
Staging
Production

projectX.dev.company.tld
projectX.test.company.tld
staging.projectX.tld
projectX.tld

module1.projectX.dev.company.tld
module1.projectX.test.company.tld
module1.staging.projectX.tld
module1.projectX.tld

module2.projectX.dev.company.tld
module2.projectX.test.company.tld
module2.staging.projectX.tld
module2.projectX.tld

…
…
…
…

moduleN.projectX.dev.company.tld
moduleN.projectX.test.company.tld
moduleN.staging.projectX.tld
moduleN.projectX.tld

Für die Produktion wird ein erworbener Wildcard-Zertifikat verwendet, was unproblematisch ist. Es deckt jedoch nur die erste Ebene der Subdomain ab. Das bedeutet, dass ein Zertifikat für *.projectX.tld zwar für staging.projectX.tld funktioniert, aber nicht für module1.staging.projectX.tld. Ein separates Zertifikat zu kaufen, ist nicht besonders attraktiv.

Und das ist nur ein Beispiel für ein Projekt eines Unternehmens. Natürlich gibt es nicht nur ein Projekt.

Die allgemeinen Gründe, sich mit dieser Angelegenheit zu befassen, sehen ungefähr so aus:

Relativ kürzlich hat Google vorgeschlagen, die maximalen Gültigkeitsdauer von SSL-Zertifikaten zu verkürzen. Mit allen daraus resultierenden Konsequenzen.
Den Prozess der Ausstellung und Wartung zu vereinfachen SSL für interne Bedürfnisse der Projekte und des Unternehmens insgesamt.
Zentralisierte Speicherung von Zertifikatsaufzeichnungen, die teilweise das Problem der Domainvalidierung durch DNS und die anschließende automatische Erneuerung löst, sowie das Vertrauensverhältnis des Kunden stärkt. Schließlich vermittelt ein CNAME auf dem Server des Unternehmens des Partners/Ausführenden mehr Vertrauen als auf eine externe Ressource.
Und schließlich passt in diesem Fall der Satz „Lieber haben als nicht haben“ perfekt.

Die Auswahl des SSL-Anbieters und die vorbereitenden Schritte

Unter den verfügbaren Optionen für kostenlose SSL-Zertifikate wurden Cloudflare und Let's Encrypt betrachtet. DNS für dieses (und einige andere Projekte) befindet sich bei Cloudflare, aber ich bin kein Fan von deren Zertifikaten. Daher wurde beschlossen, Let's Encrypt zu verwenden.
Zur Erstellung eines Wildcard-SSL Zertifikats muss die Inhaberschaft der Domäne bestätigt werden. Dieser Prozess erfordert die Erstellung eines bestimmten DNS-Eintrags (TXT oder CNAME), der bei der Ausstellung des Zertifikats überprüft wird. Unter Linux gibt es ein Tool — certbot, das es ermöglicht, diesen Prozess teilweise (oder vollständig für einige DNS-Anbieter) zu automatisieren. Für Windows habe ich mich für eine der gefundenen und geprüften Optionen für ACME-Clients entschieden: WinACME..

Der Eintrag für die Domäne wurde erstellt, nun gehen wir zur Zertifikatserstellung über:

Auf dem Weg zur Automatisierung der SSL-Ausstellung

Uns interessiert die letzte Ausgabe, nämlich die verfügbaren Optionen zur Bestätigung der Inhaberschaft der Domäne zur Ausstellung eines Wildcard-Zertifikats:

Manuelle Erstellung von DNS-Einträgen (automatische Aktualisierung wird nicht unterstützt)
Erstellung von DNS-Einträgen mithilfe eines acme-dns-Servers (weiterführende Informationen können gelesen werden hier.
Erstellung von DNS-Einträgen durch ein eigenes Skript (analog zu dem Cloudflare-Plugin für certbot).

Auf den ersten Blick scheint der dritte Punkt ganz passend zu sein, aber was, wenn der DNS-Anbieter diese Funktionalität nicht unterstützt? Wir benötigen jedoch einen allgemeinen Fall. Und der allgemeine Fall sind CNAME-Einträge, die überall unterstützt werden. Daher bleiben wir bei Punkt 2 und gehen dazu über, unseren ACME-DNS-Server einzurichten.

Einrichtung des ACME-DNS-Servers und Prozess zur Ausstellung des Zertifikats

Zur Veranschaulichung habe ich die Domain 2nd.pp.ua erstellt und werde diese im Folgenden verwenden.

Eine zwingende Voraussetzung für den ordnungsgemäßen Betrieb des Servers ist die Erstellung von NS- und A-Einträgen für seine Domain. Der erste unangenehme Punkt, auf den ich gestoßen bin, ist, dass Cloudflare (zumindest im kostenlosen Modus) es nicht erlaubt, gleichzeitig NS- und A-Einträge für denselben Host zu erstellen. Es ist zwar kein wirkliches Problem, aber in BIND ist das möglich. Der Support antwortete, dass ihr Panel das nicht zulässt. Kein Problem, wir erstellen zwei Einträge:

acmens.2nd.pp.ua. IN A 35.237.128.147
acme.2nd.pp.ua. IN NS acmens.2nd.pp.ua.

An diesem Punkt sollte der Host acmens.2nd.pp.ua.

$ ping acmens.2nd.pp.ua
PING acmens.2nd.pp.ua (35.237.128.147) 56(84) Bytes Daten

Aber acme.2nd.pp.ua wird nicht aufgelöst, da der DNS-Server, der ihn betreut, noch nicht gestartet ist.

Die Aufzeichnungen wurden erstellt, nun geht es an die Einrichtung und den Start des ACME-DNS-Servers. Er wird bei mir auf einem Ubuntu-Server laufen docker in einem Container, aber man kann ihn überall dort starten, wo Golang verfügbar ist. Windows funktioniert ebenfalls gut, jedoch bevorzuge ich Linux-Server.

Wir erstellen die benötigten Verzeichnisse und Dateien:

$ mkdir config
$ mkdir data
$ touch config/config.cfg

Wir nutzen vim, Ihren bevorzugten Texteditor, um das Beispiel in config.cfg einzufügen. Konfiguration.

Für den erfolgreichen Betrieb reicht es, die Abschnitte general und api anzupassen:

[general]
listen = "0.0.0.0:53"
protocol = "both"
domain = "acme.2nd.pp.ua"
nsname = "acmens.2nd.pp.ua" 
nsadmin = "admin.2nd.pp.ua" 
records = 
    "acme.2nd.pp.ua. A 35.237.128.147",
    "acme.2nd.pp.ua. NS acmens.2nd.pp.ua.",                                                                                                                                                                                                  ]
...
[api]
...
tls = "letsencrypt"
…

Zusätzlich erstellen wir auf Wunsch eine docker-compose-Datei im Hauptverzeichnis des Dienstes:

version: '3.7'
services:
  acmedns:
    image: joohoi/acme-dns:latest
    ports:
      - "443:443"
      - "53:53"
      - "53:53/udp"
      - "80:80"
    volumes:
      - ./config:/etc/acme-dns:ro
      - ./data:/var/lib/acme-dns

Fertig. Jetzt kann gestartet werden.

$ docker-compose up -d

An diesem Punkt sollte der Host aufgelöst werden acme.2nd.pp.ua, und eine 404-Meldung erscheinen auf https://acme.2nd.pp.ua

$ ping acme.2nd.pp.ua
PING acme.2nd.pp.ua (35.237.128.147) 56(84) bytes of data.

$ curl https://acme.2nd.pp.ua
404 page not found

Wenn das nicht erscheint — docker logs -f Zur Hilfe, die Protokolle sind durchaus lesbar.

Wir können mit der Erstellung des Zertifikats beginnen. Öffnen Sie PowerShell als Administrator und starten Sie winacme. Wir interessieren uns für die Optionen:

M: Neues Zertifikat erstellen (vollständige Optionen)
2: Manuelle Eingabe
2: [dns-01] Überprüfungseinträge mit acme-dns erstellen (https://github.com/joohoi/acme-dns)
Auf die Frage nach dem Link zum ACME-DNS-Server geben wir die URL des erstellten Servers ein (https). URL des acme-dns-Servers: https://acme.2nd.pp.ua

Der Client gibt einen Eintrag aus, den wir in den vorhandenen DNS-Server hinzufügen müssen (dieser Vorgang ist einmalig):

[INFO] Erstellen einer neuen acme-dns-Registrierung für die Domain 1nd.pp.ua

Domain:              1nd.pp.ua
Eintrag:               _acme-challenge.1nd.pp.ua
Typ:                   CNAME
Inhalt:              c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Hinweis:                   Einige DNS-Steuerungsoberflächen fügen den letzten Punkt automatisch hinzu.
                           Nur einer ist erforderlich.

Auf dem Weg zur Automatisierung der SSL-Ausstellung

Wir erstellen den erforderlichen Eintrag und stellen sicher, dass er korrekt erstellt wurde:

$ dig CNAME _acme-challenge.1nd.pp.ua +short
c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.

Wir bestätigen, dass wir den benötigten Eintrag in winacme erstellt haben und fahren mit dem Prozess zur Erstellung des Zertifikats fort:

Auf dem Weg zur Automatisierung der SSL-Ausstellung

Wie man certbot als Client verwendet, wird beschrieben. hier.

Der Prozess zur Erstellung des Zertifikats ist abgeschlossen. Sie können es jetzt auf dem Webserver installieren und verwenden. Wenn Sie bei der Erstellung des Zertifikats auch einen Task im Taskplaner anlegen, erfolgt die Aktualisierung des Zertifikats künftig automatisch.

Quelle: habr.com