🥇Az SSL kiadásának automatizálása felé

Gyakran kell dolgoznunk SSL tanúsítványokkal. Emlékezzünk vissza a tanúsítvány létrehozásának és telepítésének folyamatára (általában a legtöbb esetben).

Keresni egy szolgáltatót (weboldal, ahol SSL-t vásárolhatunk).
Generálni egy CSR-t.
Elküldeni a szolgáltatónak.
Megerősíteni a domain tulajdonjogát.
Megkapni a tanúsítványt.
Átalakítani a tanúsítványt a szükséges formába (opcionális). Például, PEM-ből PKCS #12-be.
Telepíteni a tanúsítványt a webkiszolgálóra.

Viszonylag gyors, nem bonyolult és érthető. Ez a lehetőség teljesen megfelelő, ha maximum tíz projektünk van. De mi van, ha több projektünk van, mindhárom környezettel? Klasszikus dev — staging — production. Ebben az esetben érdemes elgondolkodni a folyamat automatizálásán. Javaslom, hogy mélyebben elemezzük a problémát és találjunk egy megoldást, amely a jövőben minimalizálja a tanúsítványok létrehozására és fenntartására fordított időt. A cikk tartalmazni fog egy problémaelemzést és egy kis útmutatót a megvalósításhoz.

Előre megjegyzem: cégünk fő specializációja a .net, és így az IIS és egyéb Windows-alapú következmények. Ezért az ACME kliens és minden hozzá kapcsolódó tevékenység is a Windows környezetének tükrében lesz leírva.

Kinek releváns ez és néhány alapadat

A K cég az író személyében. URL (példa): company.tld

X projekt — egyik projektünk, amellyel foglalkozva arra a következtetésre jutottam, hogy mindenképpen a tanúsítványokkal való munka során maximális időmegtakarítást kellene célozni. Ennek a projektnek négy környezete van: dev, test, staging és production. A dev és a test a mi oldalunkon van, a staging és a production pedig az ügyfél oldalán.

A projekt sajátossága, hogy számos modulja van, amelyek elérhetők alkövetkezőként.

Tehát az alábbi képet kapjuk:

Dev
Teszt
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

A production környezethez megvásárolt wildcard tanúsítványt használunk, itt nem merül fel kérdés. De ez csak az első szintű alkövetkezőket fedi le. Tehát ha van tanúsítványunk a *.projectX.tld-ra — akkor a staging.projectX.tld-n működni fog, de a module1.staging.projectX.tld-n már nem. Egy külön tanúsítványt megvenni pedig valahogy nem tűnik vonzó opciónak.

És ez csak egy projekt egy cég példáján alapul. Nyilvánvaló, hogy a projekt nem egyedülálló.

A problémával való foglalkozás általános okai körülbelül így néznek ki:

Viszonylag nemrégiben a Google javasolta az SSL tanúsítványok maximális érvényességi idejének csökkentését.Ebből következik minden.
Megkönnyíteni a kibocsátás és karbantartás folyamatát SSL a projektek és az egész cég belső igényeihez.
Központosított nyilvántartás a tanúsítványokról, amely részben megoldja a domain megerősítésének problémáját DNS segítségével és a későbbi automatikus frissítést, valamint megoldja az ügyfél bizalmának kérdését. Végül is, a CNAME a cég szerverén partnertől/szolgáltatótól több bizalmat kelt, mint egy külső forrástól.
Nos, és végül, ebben az esetben a „jobban birtokolni, mint nem birtokolni” mondás tökéletesen illik.

SSL szolgáltató választás és előkészítő lépések

A rendelkezésre álló ingyenes SSL tanúsítványok közül a Cloudflare és a LetsEncrypt került megfontolásra. A DNS ehhez (és néhány más projekthez) a Cloudflaren található, de nem vagyok a tanúsítványaik használatának híve. Ezért a LetsEncrypt használata mellett döntöttünk.
ajánlott a wildcard SSL A tanúsítvány birtoklásának megerősítéséhez DNS bejegyzés létrehozása szükséges (TXT vagy CNAME), amelyet a tanúsítvány kibocsátása során ellenőriznek. Linux alatt van egy segédprogram — certbot, amely lehetővé teszi ennek a folyamatnak a részleges (vagy bizonyos DNS szolgáltatók esetében teljes) automatizálását. Windows alatt pedig a talált és ellenőrzött ACME kliensek közül a WinACME.

Érdekel minket az utolsó kimenet, nevezetesen — a wildcard tanúsítvány kibocsátásához szükséges domain birtoklásának megerősítésére elérhető opciók:

Az SSL kiadásának automatizálásának útján

DNS bejegyzések kézi létrehozása (automatikus frissítés nem támogatott)

DNS bejegyzések létrehozása az acme-dns szerver segítségével (további olvasmány)
DNS bejegyzések létrehozása saját szkript segítségével (a certbot Cloudflare pluginjának analógja). itt.
Első pillantásra a harmadik pont teljesen megfelelő, de mi van, ha a DNS szolgáltató nem támogatja ezt a funkciót? Szükségünk van egy általános esetre. A közös esetek pedig a CNAME bejegyzések, ezeket ugyanis mindenki támogatja. Következésképpen a második pontra hagyatkozunk, és elkezdjük beállítani az ACME-DNS szerverünket.

ACME-DNS szerver beállítása és a tanúsítvány kibocsátási folyamata

A tanúsítvány kibocsátásának folyamata

Például létrehoztam a 2nd.pp.ua domaint, és a jövőben ezt fogom használni.

Kötelező követelmény a szerver megfelelő működéséhez, hogy NS és A rekordot készítsünk a domain számára. Az első kellemetlen probléma, amivel találkoztam — a Cloudflare (legalábbis ingyenes használat esetén) nem engedi, hogy egyszerre hozzunk létre NS és A rekordot ugyanazon host számára. Nem mintha ez problémát jelentett volna, de a bind ezt meg tudja csinálni. A támogatás azt válaszolta, hogy a paneljük ezt nem engedi. Nincs mit tenni, készítsünk két rekordot:

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

Ezen a ponton a hostnak kellene feloldódnia acmens.2nd.pp.ua.

$ ping acmens.2nd.pp.ua
PING acmens.2nd.pp.ua (35.237.128.147) 56(84) bájt adat

Here is acme.2nd.pp.ua nem fog feloldódni, mivel a DNS szerver, amely kiszolgálja még nem indult el.

A rekordok létrejöttek, áttérünk az ACME-DNS szerver beállítására és indítására. A szerverem Ubuntu szerveren fog működni docker konténerben, de bárhol elindítható, ahol van golang. A Windows is teljesen alkalmas, de én inkább Linux szervert preferálom.

Hozzuk létre a szükséges könyvtárakat és fájlokat:

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

Használjuk a vim-et, a kedvenc szövegszerkesztőnket, és illesszük be a config.cfg-be a mintát konfigurációnkra.

A sikeres működéshez elegendő a general és api szekciók módosítása:

[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"
…

Továbbá, igény szerint létrehozhatunk egy docker-compose fájlt a szolgáltatás fő könyvtárában:

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

Kész. Most már indíthatjuk.

$ docker-compose up -d

Ezen a ponton el kellene kezdődnie a host feloldódásának acme.2nd.pp.ua, és 404-es hibaüzenetnek kellene megjelennie a következőn: https://acme.2nd.pp.ua

$ ping acme.2nd.pp.ua
PING acme.2nd.pp.ua (35.237.128.147) 56(84) bájt adat.

$ curl https://acme.2nd.pp.ua
404 oldal nem található

Ha ez nem jelent meg - docker logs -f megtalálható, hála az égnek, a naplók eléggé olvashatóak.

Kezdhetjük a tanúsítvány létrehozását. Nyissuk meg a powershellt rendszergazdaként, és indítsuk el a winacme-t. Minket a következő választások érdekelnek:

M: Új tanúsítvány létrehozása (teljes opciók)
2: Kézi bevitel
2: [dns-01] Ellenőrző rekordok létrehozása acme-dns segítségével (https://github.com/joohoi/acme-dns)
A kérdésre az ACME-DNS szerver linkjéről válaszolva beírjuk a létrehozott szerver URL-jét (https). Az acme-dns szerver URL-je: https://acme.2nd.pp.ua

A kliens egy bejegyzést ad meg, amelyet hozzá kell adni a meglévő DNS szerverhez (ez az eljárás egyszeri):

[INFO] Új acme-dns regisztráció létrehozása a 1nd.pp.ua domainhoz

Domain:              1nd.pp.ua
Record:               _acme-challenge.1nd.pp.ua
Type:                   CNAME
Content:              c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Note:                   Néhány DNS kezelőpanel automatikusan hozzáadja a végső pontot.
                           Csak egy szükséges.

Az SSL kiadásának automatizálásának útján

Létrehozzuk a szükséges bejegyzést, és megbizonyosodunk róla, hogy helyesen jött létre:

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

Megerősítjük, hogy létrehoztuk a szükséges bejegyzést a winacme-ben, és folytatjuk a tanúsítvány létrehozásának folyamatát:

Az SSL kiadásának automatizálásának útján

A certbot kliensként való használatáról szóló leírás megtalálható itt.

Ezzel befejeződött a tanúsítvány létrehozásának folyamata, telepíthetjük azt a webszerverre és használhatjuk. Ha a tanúsítvány létrehozásakor ütemezett feladatot is létrehozunk, akkor a tanúsítvány frissítése a továbbiakban automatikusan fog történni.

Forrás: habr.com