Mod automatisering af udstedelse af SSL

Ganske ofte skal vi arbejde med SSL-certifikater. Lad os huske processen med at oprette og installere et certifikat (i det generelle tilfælde for de fleste).

• Find en udbyder (et websted, hvor vi kan købe SSL).
• Generer CSR.
• Send det til udbyderen.
• Bekræft domæneejerskab.
• Få et certifikat.
• Konverter certifikatet til den ønskede form (valgfrit). For eksempel fra pem til PKCS #12.
• Installer certifikatet på webserveren.

Relativt hurtigt, nemt og forståeligt. Denne mulighed er ganske velegnet, hvis vi maksimalt har et dusin projekter. Hvad hvis der er flere af dem, og de har mindst tre miljøer? Klassisk dev - iscenesættelse - produktion. I dette tilfælde er det værd at tænke på at automatisere denne proces. Jeg foreslår at gå lidt dybere ind i problemet og finde en løsning, der yderligere vil minimere tiden brugt på at oprette og vedligeholde certifikater. Artiklen vil indeholde en analyse af problemet og en lille guide til gentagelse.

Jeg vil reservere på forhånd: vores virksomheds hovedspecialisering er .net, og derfor IIS og andre skruerelaterede. Derfor vil ACME-klienten og alle handlinger for den også blive beskrevet i forhold til brug af windows.

For hvem det er relevant og nogle baggrundsdata

Firma K repræsenteret af forfatteren. URL (for eksempel): company.tld

Projekt X er et af vores projekter, hvor jeg kom frem til, at vi stadig skal bevæge os mod maksimale tidsbesparelser, når vi arbejder med certifikater. Dette projekt har fire miljøer: dev, test, iscenesættelse og produktion. Dev og test er på vores side, iscenesættelse og produktion er på klientsiden.

Et kendetegn ved projektet er, at det har et stort antal moduler, der er tilgængelige som underdomæner.

Det vil sige, vi har følgende billede:

dev
Test
Iscenesættelse
produktion

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

modul1.projectX.dev.company.tld
modul1.projectX.test.company.tld
modul1.staging.projectX.tld
modul1.projektX.tld

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

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

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

Til produktion anvendes et købt wildcard-certifikat, her er ingen spørgsmål. Men det dækker kun det første niveau af underdomænet. Følgelig, hvis der er et certifikat for *.projectX.tld, vil det fungere for staging.projectX.tld, men ikke for modul1.staging.projectX.tld. Jeg vil ikke købe en separat.

Og dette er kun på eksemplet med et projekt i en virksomhed. Og projektet er selvfølgelig ikke alene.

De generelle grunde til at tackle dette problem ser sådan ud:

• For nylig Google foreslog at reducere den maksimale gyldighedsperiode for SSL-certifikater. Med alle konsekvenserne.
• At lette processen med at udstede og vedligeholde SSL til de interne behov i projekter og virksomheden som helhed.
• Centraliseret lagring af certifikatposter, som delvist løser problemet med domænevalidering ved hjælp af DNS og efterfølgende automatisk fornyelse, og løser også problemet med klienttillid. Ikke desto mindre er CNAME mere troværdig på serveren hos partneren/eksekutorfirmaet end på en tredjepartsressource.
• Nå, endelig, i dette tilfælde passer udtrykket "bedre at have end ikke at have" perfekt.

Valg af SSL-udbyder og forberedende trin

Af de tilgængelige muligheder for gratis SSL-certifikater blev cloudflare og letsencrypt overvejet. DNS'en til dette (og nogle andre projekter) hostes af cloudflare, men jeg er ikke fan af at bruge deres certifikater. Derfor blev det besluttet at bruge letsencrypt.
For at oprette et jokertegn SSL-certifikat skal du bekræfte ejerskabet af domænet. Denne procedure involverer oprettelse af en eller anden DNS-post (TXT eller CNAME) med efterfølgende verifikation ved udstedelse af et certifikat. Linux har et hjælpeprogram − certbot, som giver dig mulighed for delvist (eller helt for nogle DNS-udbydere) at automatisere denne proces. Til Windows samme fra fundet og testet muligheder for ACME-klienter, jeg slog mig ned på WinACME.

Og registreringen for domænet er blevet oprettet, lad os gå videre til at oprette et certifikat:

Vi er interesserede i den sidste konklusion, nemlig de tilgængelige muligheder for at bekræfte domæneejerskab for at udstede et wildcard-certifikat:

1. Oprettelse af DNS-poster manuelt (automatisk opdatering understøttes ikke)
2. Oprettelse af DNS-poster ved hjælp af acme-dns-serveren (for flere detaljer, se her.
3. Oprettelse af DNS-poster ved hjælp af dit eget script (svarende til cloudflare-plugin til certbot).

Ved første øjekast er det tredje punkt ret passende, men hvis DNS-udbyderen ikke understøtter denne funktionalitet? Og vi har brug for en generel sag. Og den generelle sag er CNAME-poster, alle støtter dem. Derfor stopper vi ved punkt 2, og går til at konfigurere vores ACME-DNS server.

ACME-DNS-serveropsætning og certifikatudstedelsesproces

For eksempel oprettede jeg domænet 2nd.pp.ua, og jeg vil bruge det i fremtiden.

Obligatorisk krav for den korrekte drift af serveren er oprettelsen af ​​NS- og A-poster for dens domæne. Og det første ubehagelige øjeblik, jeg stødte på, er, at cloudflare (i det mindste i fri tilstand) ikke tillader dig samtidig at oprette en NS- og A-record for den samme vært. Ikke at dette er et problem, men i bund er det muligt. Support svarede, at deres panel ikke tillader at gøre dette. Det er lige meget, lad os oprette to poster:

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

På dette stadium bør vi løse værten acmens.2nd.pp.ua.

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

Men acme.2nd.pp.ua vil ikke løses, da den DNS-server, der betjener den, ikke kører endnu.

Posterne er blevet oprettet, lad os gå videre til opsætning og start af ACME-DNS-serveren. Jeg lever det på ubuntu server i havnearbejder container, men du kan køre den overalt, hvor der er golang. Windows er også fint, men jeg foretrækker stadig en Linux-server.

Opret de nødvendige mapper og filer:

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

Lad os bruge vim med din foretrukne teksteditor og indsætte prøven i config.cfg konfiguration.

For vellykket arbejde er det nok at rette de generelle og api-sektioner:

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

Du kan også oprette en docker-compose-fil i tjenestens hovedbibliotek:

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

Parat. Du kan løbe.

$ docker-compose up -d

På dette stadium bør værten begynde at løse problemet acme.2nd.pp.ua, og vises 404 på 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

Hvis dette ikke vises - docker logs -f <container_name> for at hjælpe, godt, logfilerne er ret læsbare.

Vi kan begynde at oprette et certifikat. Åbn powershell som administrator og kør winacme. Vi er interesserede i valget:

• M: Opret nyt certifikat (fulde muligheder)
• 2: Manuel input
• 2: [dns-01] Opret verifikationsposter med acme-dns (https://github.com/joohoi/acme-dns)
• Når du bliver spurgt om et link til ACME-DNS-serveren, skal du indtaste URL'en på den oprettede server (https) som svar. URL på acme-dns-serveren: https://acme.2nd.pp.ua

Som svar udsteder klienten en post, der skal tilføjes til den eksisterende DNS-server (engangsprocedure):

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

Vi opretter den nødvendige post og sikrer os, at den er oprettet korrekt:

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

Vi bekræfter, at vi har oprettet den påkrævede post i winacme, og fortsætter processen med at oprette et certifikat:

Hvordan man bruger certbot som klient er beskrevet her.

Dette fuldender processen med at oprette et certifikat, du kan installere det på en webserver og bruge det. Hvis du, når du opretter et certifikat, også opretter en opgave i skemalæggeren, vil processen med at opdatere certifikatet i fremtiden ske automatisk.

Kilde: www.habr.com