🥇Auf dem Weg zur Automatisierung der SSL-Ausstellung

Es kommt ziemlich häufig vor, dass wir mit SSL-Zertifikatenarbeiten müssen. Lassen Sie uns den Prozess der Erstellung und Installation eines Zertifikats (im Allgemeinen für die meisten) noch einmal durchgehen.

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

Relativ schnell, nicht kompliziert und verständlich. Diese Methode ist durchaus geeignet, wenn wir höchstens ein paar Dutzend Projekte haben. Aber was ist, wenn es mehr sind und jedes mindestens drei Umgebungen hat? Klassisch dev — staging — production. In diesem Fall sollte man über die Automatisierung dieses Prozesses nachdenken. Ich schlage vor, etwas tiefer in das Problem einzutauchen und eine Lösung zu finden, die in Zukunft den zeitlichen Aufwand für die Erstellung und Wartung von Zertifikaten minimiert. Der Artikel enthält eine Problem-Analyse und eine kleine Anleitung zur Wiederholung.

Vorweg sei gesagt: Die Hauptspezialisierung unseres Unternehmens ist .net, also IIS und andere Windows-Spezifika. Daher werden der ACME-Client und alle Aktionen dafür ebenfalls aus der Perspektive der Nutzung von Windows beschrieben.

Für wen das relevant ist und einige Ausgangsdaten

Firma K als Autor. URL (zur Veranschaulichung): company.tld

Projekt X — eines unserer Projekte, bei dem ich zu dem Schluss kam, dass wir definitiv in Richtung einer maximalen Zeiteinsparung bei der Arbeit mit Zertifikaten gehen sollten. Dieses Projekt hat vier Umgebungen: dev, test, staging und production. Dev und test liegen auf unserer Seite, staging und production auf der Kundenseite.

Das Besondere an dem Projekt 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 gekaufter Wildcard-Zertifikat verwendet, dazu gibt es keine Fragen. Aber es deckt nur die erste Ebene der Subdomain ab. Das bedeutet, wenn es ein Zertifikat für *.projectX.tld gibt — dann funktioniert es für staging.projectX.tld, aber nicht für module1.staging.projectX.tld. Ein separates zu kaufen ist irgendwie nicht gewünscht.

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 Frage zu beschäftigen, sehen ungefähr so aus:

Relativ kürzlich hat Google vorgeschlagen, die maximale Gültigkeitsdauer von SSL-Zertifikaten zu verkürzen. Mit allen Konsequenzen.
Den Prozess der Ausstellung und Verwaltung zu erleichtern SSL für interne Bedürfnisse der Projekte und des Unternehmens insgesamt.
Zentralisierte Speicherung von Zertifikatsdaten, die teilweise das Problem der Domainvalidierung über DNS und die anschließende automatische Erneuerung löst, sowie das Vertrauen des Kunden sicherstellt. Immerhin weckt ein CNAME auf dem Server des Unternehmens des Partners / Dienstleisters mehr Vertrauen als auf einer externen Ressource.
Nun, und schließlich passt in diesem Fall der Satz „besser haben als nicht haben“ ausgezeichnet.

Die Wahl des SSL-Anbieters und die vorbereitenden Schritte

Von den verfügbaren Optionen für kostenlose SSL-Zertifikate wurden cloudflare und letsencrypt in Betracht gezogen. DNS dafür (und einige andere Projekte) sind auf cloudflare gespeichert, aber ich bin kein Anhänger der Verwendung ihrer Zertifikate. Daher wurde beschlossen, letsencrypt zu verwenden.
Um zu erstellen wildcard SSL Zertifikat muss die Domaininhaberschaft bestätigen. Dieses Verfahren erfordert die Erstellung eines bestimmten DNS-Eintrags (TXT oder CNAME), der anschließend bei der Ausstellung des Zertifikats überprüft wird. In Linux gibt es ein Dienstprogramm — certbot, das diesen Prozess teilweise (oder vollständig für einige DNS-Anbieter) automatisieren kann. Für Windows habe ich bei den gefundenen und geprüften Optionen für ACME-Clients zu WinACME gewechselt. Die Eintragung für die Domain wurde erstellt, jetzt gehen wir zur Erstellung des Zertifikats über:.

Wir interessieren uns für die letzte Ausgabe, nämlich die verfügbaren Optionen zur Bestätigung der Domaininhaberschaft zur Ausstellung des wildcard Zertifikats:

Auf dem Weg zur Automatisierung der SSL-Veröffentlichung.

Manuelle Erstellung von DNS-Einträgen (automatische Aktualisierung wird nicht unterstützt)

Erstellung von DNS-Einträgen mit einem acme-dns-Server (detaillierteres Lesen ist möglich)
Erstellung von DNS-Einträgen mit einem eigenen Skript (analog zum cloudflare-Plugin für certbot). hier.
Auf den ersten Blick scheint der dritte Punkt recht geeignet, aber was, wenn der DNS-Anbieter diese Funktionalität nicht unterstützt? Wir brauchen einen allgemeinen Fall. Und der allgemeine Fall sind die CNAME-Einträge, die alle unterstützen. Folglich bleiben wir bei Punkt 2 und konfigurieren unseren ACME-DNS-Server.

Einrichtung des ACME-DNS-Servers und der Prozess der Ausstellung des Zertifikats.

Einrichtung des ACME-DNS-Servers und der Prozess der Zertificateausstellung

Zum Beispiel habe ich die Domain 2nd.pp.ua erstellt und werde sie künftig verwenden.

Eine zwingende Anforderung für den ordnungsgemäßen Betrieb des Servers ist die Erstellung von NS- und A-Records für dessen Domain. Das erste ungelöste Problem, auf das ich gestoßen bin, ist, dass Cloudflare (zumindest im kostenlosen Modus) nicht erlaubt, gleichzeitig einen NS- und A-Record für denselben Host zu erstellen. Es wäre nicht das Problem, aber das geht mit BIND. Der Support hat mir mitgeteilt, dass ihr Panel dies nicht erlaubt. Kein Problem, erstellen wir zwei Records:

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

In diesem Schritt 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

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

Die Records wurden erstellt, jetzt gehen wir zur Konfiguration und dem Start des ACME-DNS-Servers über. 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 eignet sich ebenfalls gut, aber ich bevorzuge dennoch einen Linux-Server.

Erstellen wir die benötigten Verzeichnisse und Dateien:

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

Wir verwenden vim, euren Lieblings-Texteditor, und fügen im config.cfg das Beispiel ein Konfiguration.

Für ein erfolgreiches Funktionieren reicht es aus, 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"
…

Außerdem können wir auf Wunsch eine docker-compose-Datei im Hauptverzeichnis des Dienstes erstellen:

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. Man kann starten.

$ docker-compose up -d

In diesem Schritt sollte der Host beginnen sich aufzulösen acme.2nd.pp.ua, und ein 404 erscheinen auf https://acme.2nd.pp.ua

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

$ curl https://acme.2nd.pp.ua
404 Seite nicht gefunden

Wenn dies nicht erscheint — docker logs -f hilft, zum Glück sind die Logs ganz lesbar.

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

M: Neues Zertifikat erstellen (alle Optionen)
2: Manuelle Eingabe
2: [dns-01] Bestätigungs-Records 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 (https) ein. URL des acme-dns-Servers: https://acme.2nd.pp.ua

Der Client gibt einen Datensatz aus, den man zu einem bestehenden DNS-Server hinzufügen muss (dieser Vorgang ist einmalig):

[INFO] Erstelle eine neue acme-dns Registrierung für die Domain 1nd.pp.ua

Domain:              1nd.pp.ua
Datensatz:           _acme-challenge.1nd.pp.ua
Typ:                CNAME
Inhalt:             c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Hinweis:            Einige DNS-Verwaltungspanels fügen den abschließenden Punkt automatisch hinzu.
                    Nur einer ist erforderlich.

Auf dem Weg zur Automatisierung der SSL-Veröffentlichung.

Wir erstellen den erforderlichen Datensatz 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 Datensatz in winacme erstellt haben, und setzen den Zertifikatserstellungsprozess fort:

Auf dem Weg zur Automatisierung der SSL-Veröffentlichung.

Wie man certbot als Client verwendet, ist beschrieben hier.

Damit ist der Prozess zur Erstellung des Zertifikats abgeschlossen, und es kann auf dem Webserver installiert und verwendet werden. Wenn man bei der Erstellung des Zertifikats auch einen Task im Scheduler erstellt, wird der Aktualisierungsprozess des Zertifikats künftig automatisch ablaufen.

Quelle: habr.com