Az SSL-kiadás automatizálása felé

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

• Keress egy szolgáltatót (olyan oldalt, ahol SSL-t vásárolhatunk).
• CSR generálása.
• Küldje el a szolgáltatónak.
• Ellenőrizze a domain tulajdonjogát.
• Szerezzen bizonyítványt.
• Alakítsa át a tanúsítványt a kívánt formára (opcionális). Például a pemtől a PKCS #12-ig.
• Telepítse a tanúsítványt a webszerverre.

Viszonylag gyors, egyszerű és érthető. Ez a lehetőség nagyon megfelelő, ha legfeljebb egy tucat projektünk van. Mi van, ha többen vannak, és legalább három környezetük van? Klasszikus dev - staging - produkció. Ebben az esetben érdemes elgondolkodni a folyamat automatizálásán. Azt javaslom, hogy elmélyüljünk egy kicsit a problémában, és találjunk olyan megoldást, amely tovább csökkenti a tanúsítványok létrehozására és karbantartására fordított időt. A cikk tartalmazza a probléma elemzését és egy kis útmutatót az ismétléshez.

Előzetesen foglalok: cégünk fő szakterülete a .net, és ennek megfelelően az IIS és egyéb csavarokkal kapcsolatos. Ezért az ACME klienst és az ezzel kapcsolatos összes műveletet a Windows használatának szempontjából is leírjuk.

Akik számára releváns és néhány háttéradat

A szerző által képviselt K cég. URL (például): company.tld

Az X projekt az egyik projektünk, amelyben arra a következtetésre jutottam, hogy a tanúsítványokkal való munka során továbbra is a maximális időmegtakarítás felé kell haladnunk. Ennek a projektnek négy környezete van: fejlesztői, tesztelési, staging és termelési. A fejlesztő és a tesztelés a mi oldalunkon, a kivitelezés és a gyártás az ügyfél oldalon áll.

A projekt sajátossága, hogy nagyszámú modullal rendelkezik, amelyek aldomainként érhetők el.

Vagyis a következő képünk van:

Dev
Teszt
Staging
Termelés

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 gyártáshoz vásárolt helyettesítő tanúsítványt használnak, itt nincs kérdés. De ez csak az aldomain első szintjét fedi le. Ennek megfelelően, ha van tanúsítvány a *.projectX.tld-hez, akkor az működik a staging.projectX.tld-hez, de nem a module1.staging.projectX.tld-hez. Nem akarok külön venni.

És ez csak egy vállalat egy projektjének példáján van. És a projekt természetesen nincs egyedül.

A probléma kezelésének általános okai valahogy így néznek ki:

• Nemrég A Google az SSL-tanúsítványok maximális érvényességi idejének csökkentését javasolta. Minden következménnyel együtt.
• Az SSL kiadási és karbantartási folyamatának megkönnyítése a projektek és a vállalat egészének belső igényei szerint.
• Tanúsítványrekordok központosított tárolása, amely részben megoldja a DNS segítségével történő tartományérvényesítés és az azt követő automatikus megújítás problémáját, valamint megoldja a kliens bizalom kérdését is. Ennek ellenére a CNAME megbízhatóbb a partner/végrehajtó cég szerverén, mint egy harmadik féltől származó erőforráson.
• Nos, végül ebben az esetben tökéletesen illik a „jobb, ha van, mint ha nincs” kifejezés.

Az SSL-szolgáltató kiválasztása és az előkészítő lépések

Az ingyenes SSL-tanúsítványok elérhető lehetőségei közül a cloudflare-t és a letsencryptet vették figyelembe. Ennek (és néhány más projektnek) a DNS-ét a cloudflare üzemelteti, de nem rajongok a tanúsítványaik használatáért. Ezért a letsencrypt használata mellett döntöttek.
Helyettesítő karakteres SSL-tanúsítvány létrehozásához igazolnia kell a domain tulajdonjogát. Ez az eljárás magában foglalja néhány DNS-rekord (TXT vagy CNAME) létrehozását, amelyet a tanúsítvány kibocsátásakor ellenőrizni kell. A Linuxnak van egy segédprogramja − certbot, amely lehetővé teszi ennek a folyamatnak a részleges (vagy egyes DNS-szolgáltatók esetében teljesen) automatizálását. Windows esetén is ugyanilyentől találtak és teszteltek opciók az ACME kliensek számára WinACME.

És létrejött a domain rekordja, folytassuk a tanúsítvány létrehozását:

Az utolsó következtetés érdekel bennünket, nevezetesen a domain tulajdonjogának megerősítésére rendelkezésre álló lehetőségek a helyettesítő karakter tanúsítvány kiadásához:

1. DNS rekordok manuális létrehozása (az automatikus frissítés nem támogatott)
2. DNS-rekordok létrehozása az acme-dns szerverrel (további részletekért lásd: itt.
3. DNS-rekordok létrehozása saját szkript használatával (hasonlóan a certbot cloudflare beépülő moduljához).

Első pillantásra a harmadik pont teljesen megfelelő, de ha a DNS-szolgáltató nem támogatja ezt a funkciót? És szükségünk van egy általános esetre. És az általános eset a CNAME rekordok, mindenki támogatja őket. Ezért megállunk a 2. pontnál, és áttérünk az ACME-DNS szerverünk konfigurálására.

Az ACME-DNS szerver beállítási és tanúsítványkiadási folyamata

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

Kötelező követelmény A szerver megfelelő működéséhez NS és A rekordok létrehozása szükséges a tartományához. És az első kellemetlen pillanat, amellyel találkoztam, az az, hogy a cloudflare (legalábbis szabad módban) nem teszi lehetővé, hogy egyidejűleg NS és A rekordot hozzon létre ugyanahhoz a gazdagéphez. Nem mintha ez probléma lenne, de kötésben lehetséges. A Support azt válaszolta, hogy a panelük ezt nem teszi lehetővé. Nem számít, hozzunk létre két bejegyzést:

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

Ebben a szakaszban meg kell oldanunk a fogadót acmens.2nd.pp.ua.

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

De acme.2nd.pp.ua nem oldódik meg, mivel az azt kiszolgáló DNS-kiszolgáló még nem fut.

A rekordok elkészültek, térjünk át az ACME-DNS szerver beállítására és elindítására. Ubuntu szerveren fogom élni dokkmunkás konténer, de bárhol futtathatod, ahol van golang. A Windows is rendben van, de én még mindig jobban szeretem a Linux szervert.

Hozza 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 kedvenc szövegszerkesztőjével, és illesszük be a mintát a config.cfg fájlba konfiguráció.

A sikeres munkához elegendő az általános és az api szakaszt kijavítani:

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

Opcionálisan hozzon létre 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. Futhatsz.

$ docker-compose up -d

Ebben a szakaszban a fogadónak el kell kezdenie a megoldást acme.2nd.pp.ua, és megjelenik a 404-en 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

Ha ez nem jelenik meg - docker logs -f <container_name> segíteni, jó, a naplók elég olvashatók.

Elkezdhetjük a tanúsítvány készítését. Nyissa meg a powershell-t rendszergazdaként, és futtassa a winacme-t. Érdekelnek minket a választások:

• M: Új tanúsítvány létrehozása (teljes opciók)
• 2: Kézi bevitel
• 2: [dns-01] Hozzon létre ellenőrző rekordokat az acme-dns (https://github.com/joohoi/acme-dns)
• Amikor az ACME-DNS szerverre mutató hivatkozásról kérdezik, válaszul adja meg a létrehozott szerver URL-jét (https). Az acme-dns szerver URL-je: https://acme.2nd.pp.ua

Válaszul az ügyfél kiad egy rekordot, amelyet hozzá kell adni a meglévő DNS-kiszolgálóhoz (egyszeri eljárás):

[INFO] Creating new acme-dns registration for domain 1nd.pp.ua

Domain:              1nd.pp.ua
Record:               _acme-challenge.1nd.pp.ua
Type:                   CNAME
Content:              c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Note:                   Some DNS control panels add the final dot automatically.
                           Only one is required.

Elkészítjük a szükséges bejegyzést, és megbizonyosodunk arról, hogy helyesen lett létrehozva:

$ 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-ban, és folytatjuk a tanúsítvány létrehozásának folyamatát:

Leírják, hogyan kell a certbotot kliensként használni itt.

Ezzel befejeződik a tanúsítvány létrehozásának folyamata, telepítheti egy webszerverre és használhatja. Ha a tanúsítvány létrehozásakor egy feladatot is létrehoz az ütemezőben, akkor a jövőben a tanúsítvány frissítése automatikusan megtörténik.

Forrás: will.com