K avtomatizaciji izdaje SSL

Pogosto moramo delati s SSL certifikati. Spomnimo se postopka ustvarjanja in namestitve certifikata (za večino v splošnem primeru).

• Poiščite ponudnika (stran, kjer lahko kupimo SSL).
• Ustvari CSR.
• Pošljite ga svojemu ponudniku.
• Preverite lastništvo domene.
• Pridobite potrdilo.
• Pretvorite potrdilo v zahtevano obliko (neobvezno). Na primer iz pem v PKCS #12.
• Namestite potrdilo na spletni strežnik.

Relativno hitro, nezapleteno in razumljivo. Ta možnost je zelo primerna, če imamo največ deset projektov. Kaj pa če jih je več in imajo vsaj tri okolja? Klasični razvoj - uprizarjanje - produkcija. V tem primeru je vredno razmisliti o avtomatizaciji tega procesa. Predlagam, da se malo poglobimo v problem in poiščemo rešitev, ki bo še dodatno zmanjšala čas, porabljen za izdelavo in vzdrževanje certifikatov. Članek bo vseboval analizo problema in majhen vodnik za ponavljanje.

Naj rezerviram vnaprej: glavna specializacija našega podjetja je .net in s tem IIS in drugi izdelki, povezani z Windows. Zato bo odjemalec ACME in vsa dejanja zanj opisana tudi z vidika uporabe sistema Windows.

Za koga je to relevantno in nekaj začetnih podatkov

Podjetje K, ki ga zastopa avtor. URL (na primer): company.tld

Projekt X je eden izmed naših projektov, med delom na katerem sem ugotovil, da se moramo pri delu s certifikati še premakniti v smeri maksimalnega prihranka časa. Ta projekt ima štiri okolja: razvojno, preizkusno, uprizoritveno in produkcijsko. Dev in test sta na naši strani, staging in produkcija pa na strani stranke.

Posebnost projekta je, da ima veliko število modulov, ki so na voljo kot poddomene.

Se pravi, imamo naslednjo sliko:

dev
Test
Uprizoritev
proizvodnja

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
modul1.projectX.tld

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

...
...
...
...

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

Za proizvodnjo se uporablja kupljeno potrdilo z nadomestnimi znaki, tu se ne pojavijo vprašanja. Vendar pokriva le prvo raven poddomene. V skladu s tem, če obstaja potrdilo za *.projectX.tld, bo delovalo za staging.projectX.tld, ne pa tudi za module1.staging.projectX.tld. Ampak nekako ne želim kupiti ločenega.

In to samo na primeru enega projekta enega podjetja. In seveda obstaja več kot en projekt.

Pogosti razlogi, zakaj se vsi lotijo ​​te težave, so videti nekako takole:

• Pred kratkim Google je predlagal skrajšanje najdaljše veljavnosti certifikatov SSL. Z vsemi posledicami.
• Olajšati proces izdaje in vzdrževanja SSL za interne potrebe projektov in podjetja kot celote.
• Centralizirano shranjevanje zapisov certifikatov, ki delno rešuje problem preverjanja domene z uporabo DNS in kasnejšega avtomatskega obnavljanja ter rešuje tudi vprašanje zaupanja odjemalcev. Kljub temu je CNAME na strežniku partnerskega/izvajalskega podjetja bolj vreden zaupanja kot na viru tretje osebe.
• No, končno, v tem primeru izraz "bolje je imeti kot ne imeti" popolnoma ustreza.

Izbira ponudnika SSL in pripravljalni koraki

Med razpoložljivimi možnostmi za brezplačne SSL certifikate sta bila upoštevana cloudflare in letsencrypt. DNS za ta (in nekatere druge projekte) gosti cloudflare, vendar nisem navdušen nad uporabo njihovih potrdil. Zato je bilo odločeno, da uporabimo letsencrypt.
Če želite ustvariti potrdilo SSL z nadomestnimi znaki, morate potrditi lastništvo domene. Ta postopek vključuje ustvarjanje zapisa DNS (TXT ali CNAME) in njegovo nato preverjanje pri izdaji potrdila. Linux ima pripomoček - certbot, ki omogoča delno (ali v celoti pri nekaterih ponudnikih DNS) avtomatizacijo tega procesa. Za Windows od najden in preverjen Možnosti odjemalca ACME, za katere sem se odločil WinACME.

In zapis za domeno je ustvarjen, preidimo na ustvarjanje certifikata:

Zanima nas zadnja ugotovitev, in sicer razpoložljive možnosti potrditve lastništva domene za izdajo nadomestnega certifikata:

1. Ustvari zapise DNS ročno (samodejna posodobitev ni podprta)
2. Ustvarjanje DNS zapisov s pomočjo strežnika acme-dns (več o tem lahko preberete tukaj.
3. Ustvarjanje zapisov DNS z lastnim skriptom (podobno vtičniku cloudflare za certbot).

Na prvi pogled je tretja točka povsem primerna, a kaj, če ponudnik DNS ne podpira te funkcionalnosti? Vendar potrebujemo splošen primer. In splošni primer so zapisi CNAME, saj jih vsi podpirajo. Zato se ustavimo pri točki 2 in gremo na konfiguracijo našega strežnika ACME-DNS.

Nastavitev strežnika ACME-DNS in postopka izdaje certifikata

Na primer, ustvaril sem domeno 2nd.pp.ua in jo bom uporabljal v prihodnje.

Obvezna zahteva Za pravilno delovanje strežnika je potrebno ustvariti NS in A zapisa za svojo domeno. In prvi neprijeten trenutek, na katerega sem naletel, je, da vam Cloudflare (vsaj v načinu brezplačne uporabe) ne omogoča hkratnega ustvarjanja zapisa NS in A za istega gostitelja. Ne, da je to težava, vendar je v vezavi možno. Podpora je odgovorila, da njihov panel tega ne dovoljuje. Ni problema, ustvarimo dva zapisa:

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

Na tej stopnji bi moral naš gostitelj rešiti acmens.2nd.pp.ua.

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

Vendar acme.2nd.pp.ua ne bo rešil, ker strežnik DNS, ki ga služi, še ne deluje.

Zapisi so ustvarjeni, nadaljujemo z nastavitvijo in zagonom strežnika ACME-DNS. Živel bo na mojem strežniku ubuntu v Docker vsebnik, vendar ga lahko zaženete kjer koli, kjer je golang na voljo. Windowsi so tudi čisto primerni, vendar imam vseeno raje Linux strežnik.

Ustvarite potrebne imenike in datoteke:

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

Uporabimo vim z vašim najljubšim urejevalnikom besedil in prilepimo vzorec v config.cfg konfiguracijo.

Za uspešno delovanje je dovolj, da popravite splošne in api razdelke:

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

Po želji bomo ustvarili tudi datoteko docker-compose v glavnem storitvenem imeniku:

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

pripravljena Lahko ga zaženeš.

$ docker-compose up -d

Na tej stopnji bi moral gostitelj začeti reševati acme.2nd.pp.uain 404 se pojavi na 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

Če se to ne pojavi - docker logs -f <container_name> v pomoč, na srečo so dnevniki precej berljivi.

Lahko začnemo z izdelavo certifikata. Odprite powershell kot skrbnik in zaženite winacme. Zanimajo nas volitve:

• M: Ustvari novo potrdilo (vse možnosti)
• 2: Ročni vnos
• 2: [dns-01] Ustvari zapise za preverjanje z acme-dns (https://github.com/joohoi/acme-dns)
• Na vprašanje o povezavi do strežnika ACME-DNS v odgovor vnesite URL ustvarjenega strežnika (https). URL strežnika acme-dns: https://acme.2nd.pp.ua

V odprtju odjemalec izda zapis, ki ga je treba dodati na obstoječi DNS strežnik (enkratni postopek):

[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.

Ustvarimo potreben zapis in poskrbimo, da je pravilno ustvarjen:

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

Potrjujemo, da smo ustvarili zahtevani vnos v winacme, in nadaljujemo postopek ustvarjanja potrdila:

Opisan je način uporabe certbota kot odjemalca tukaj.

S tem je postopek izdelave certifikata zaključen, lahko ga namestite na spletni strežnik in uporabljate. Če pri ustvarjanju potrdila ustvarite tudi nalogo v razporejevalniku, se bo v prihodnosti postopek obnavljanja potrdila zgodil samodejno.

Vir: www.habr.com