Mot automatisering av SSL-utstedelse

Ganske ofte må vi jobbe med SSL-sertifikater. La oss huske prosessen med å opprette og installere et sertifikat (i det generelle tilfellet for de fleste).

• Finn en leverandør (et nettsted hvor vi kan kjøpe SSL).
• Generer CSR.
• Send den til leverandøren din.
• Bekreft domeneeierskap.
• Få et sertifikat.
• Konverter sertifikatet til det nødvendige skjemaet (valgfritt). For eksempel fra pem til PKCS #12.
• Installer sertifikatet på webserveren.

Relativt raskt, ikke komplisert og forståelig. Dette alternativet er ganske egnet hvis vi har maksimalt ti prosjekter. Hva om det er flere av dem, og de har minst tre miljøer? Klassisk dev - iscenesettelse - produksjon. I dette tilfellet er det verdt å tenke på å automatisere denne prosessen. Jeg foreslår å gå litt dypere inn i problemet og finne en løsning som ytterligere vil minimere tiden brukt på å opprette og vedlikeholde sertifikater. Artikkelen vil inneholde en analyse av problemstillingen og en liten guide til repetisjon.

La meg gjøre en reservasjon på forhånd: hovedspesialiseringen til selskapet vårt er .net, og følgelig IIS og andre Windows-relaterte produkter. Derfor vil ACME-klienten og alle handlinger for den også bli beskrevet fra synspunktet om bruk av Windows.

For hvem er dette relevant og noen innledende data

Firma K representert ved forfatteren. URL (for eksempel): company.tld

Prosjekt X er et av prosjektene våre, mens jeg arbeidet med kom jeg til den konklusjonen at vi fortsatt må bevege oss mot maksimal tidsbesparelse når vi jobber med sertifikater. Dette prosjektet har fire miljøer: dev, test, iscenesettelse og produksjon. Dev og test er på vår side, iscenesettelse og produksjon er på klientsiden.

Et særtrekk ved prosjektet er at det har et stort antall moduler som er tilgjengelige som underdomener.

Det vil si at vi har følgende bilde:

dev
Test
Iscenesettelse
Produksjon

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

modul1.projectX.dev.company.tld
module1.projectX.test.company.tld
modul1.staging.projectX.tld
modul1.prosjektX.tld

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

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

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

Til produksjon benyttes kjøpt jokertegn, her oppstår ingen spørsmål. Men det dekker bare det første nivået av underdomenet. Følgelig, hvis det er et sertifikat for *.projectX.tld, vil det fungere for staging.projectX.tld, men ikke for modul1.staging.projectX.tld. Men på en eller annen måte vil jeg ikke kjøpe en separat.

Og dette er kun basert på eksemplet med ett prosjekt fra ett selskap. Og selvfølgelig er det mer enn ett prosjekt.

Vanlige grunner for alle til å ta opp dette problemet ser omtrent slik ut:

• Nylig Google foreslo å redusere den maksimale gyldighetsperioden for SSL-sertifikater. Med alle konsekvensene.
• Tilrettelegge prosessen med å utstede og vedlikeholde SSL for de interne behovene til prosjekter og selskapet som helhet.
• Sentralisert lagring av sertifikatposter, som delvis løser problemet med domeneverifisering ved bruk av DNS og påfølgende automatisk fornyelse, og løser også problemet med klienttillit. Likevel er en CNAME på serveren til et partner-/utøverselskap mer pålitelig enn på en tredjepartsressurs.
• Vel, til slutt, i dette tilfellet passer uttrykket "det er bedre å ha enn ikke å ha" perfekt.

Velge en SSL-leverandør og forberedende trinn

Blant de tilgjengelige alternativene for gratis SSL-sertifikater ble cloudflare og letsencrypt vurdert. DNS for dette (og noen andre prosjekter) er hostet av cloudflare, men jeg er ikke en fan av å bruke sertifikatene deres. Derfor ble det besluttet å bruke letsencrypt.
For å opprette et jokertegn SSL-sertifikat må du bekrefte domeneeierskap. Denne prosedyren innebærer å opprette en DNS-post (TXT eller CNAME), og deretter bekrefte den når du utsteder et sertifikat. Linux har et verktøy - certbot, som lar deg delvis (eller fullstendig for noen DNS-leverandører) automatisere denne prosessen. For Windows fra funnet og verifisert ACME-klientalternativer jeg slo meg til ro med WinACME.

Og posten for domenet er opprettet, la oss gå videre til å lage et sertifikat:

Vi er interessert i den siste konklusjonen, nemlig de tilgjengelige alternativene for å bekrefte domeneeierskap for å utstede et jokertegnsertifikat:

1. Opprett DNS-poster manuelt (automatisk oppdatering støttes ikke)
2. Opprette DNS-poster ved hjelp av acme-dns server (du kan lese mer om her.
3. Opprette DNS-poster ved hjelp av ditt eget skript (ligner på cloudflare-pluginen for certbot).

Ved første øyekast er det tredje punktet ganske passende, men hva om DNS-leverandøren ikke støtter denne funksjonaliteten? Men vi trenger en generell sak. Men det generelle tilfellet er CNAME-poster, siden alle støtter dem. Derfor stopper vi ved punkt 2 og går for å konfigurere vår ACME-DNS-server.

Sette opp ACME-DNS-server og sertifikatutstedelsesprosess

For eksempel opprettet jeg domenet 2nd.pp.ua, og vil bruke det i fremtiden.

Obligatorisk krav For at serveren skal fungere riktig, er det nødvendig å opprette NS- og A-poster for domenet. Og det første ubehagelige øyeblikket jeg møtte er at cloudflare (i det minste i gratis bruksmodus) ikke lar deg lage en NS- og A-post samtidig for samme vert. Ikke at dette er et problem, men det er mulig. Supporten svarte at panelet deres ikke tillater å gjøre dette. Ikke noe problem, la oss opprette to poster:

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

På dette stadiet bør verten vår løse seg 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 det vil ikke løse seg, siden DNS-serveren som betjener den ikke kjører ennå.

Postene er opprettet, vi fortsetter med å sette opp og starte ACME-DNS-serveren. Den vil leve på ubuntu-serveren min Docker container, men du kan kjøre den hvor som helst der golang er tilgjengelig. Windows er også ganske egnet, men jeg foretrekker fortsatt en Linux-server.

Lag de nødvendige katalogene og filene:

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

La oss bruke vim med din favoritt tekstredigerer og lime inn prøven i config.cfg konfigurasjon.

For vellykket drift er det nok å korrigere de generelle og api-delene:

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

Hvis ønskelig, vil vi også opprette en docker-compose-fil i hovedtjenestekatalogen:

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

Klar. Du kan kjøre den.

$ docker-compose up -d

På dette stadiet bør verten begynne å løse acme.2nd.pp.ua, og en 404 vises 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 å hjelpe, heldigvis, er loggene ganske lesbare.

Vi kan begynne å lage sertifikatet. Åpne powershell som administrator og kjør winacme. Vi er interessert i valget:

• M: Opprett nytt sertifikat (fullstendige alternativer)
• 2: Manuell inngang
• 2: [dns-01] Opprett verifiseringsposter med acme-dns (https://github.com/joohoi/acme-dns)
• Når du blir spurt om en kobling til ACME-DNS-serveren, skriv inn URL-en til den opprettede serveren (https) i svaret. URL til acme-dns-serveren: https://acme.2nd.pp.ua

I åpningen utsteder klienten en post som må legges til den eksisterende DNS-serveren (engangsprosedyre):

[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 oppretter den nødvendige posten og sørger for at den ble opprettet på riktig måte:

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

Vi bekrefter at vi har opprettet den nødvendige oppføringen i winacme, og fortsetter prosessen med å lage et sertifikat:

Hvordan du bruker certbot som klient er beskrevet her.

Dette fullfører prosessen med å lage et sertifikat; du kan installere det på webserveren og bruke det. Hvis du, når du oppretter et sertifikat, også oppretter en oppgave i planleggeren, vil sertifikatfornyelsesprosessen i fremtiden skje automatisk.

Kilde: www.habr.com