🥇På vej mod automatisering af udstedelse af SSL

Vi arbejder ofte med SSL-certifikater.Lad os genopfriske processen for oprettelse og installation af et certifikat (generelt for de fleste).

Find en udbyder (en hjemmeside hvor vi kan købe SSL).
Generere CSR.
Send det til udbyderen.
Bekræft ejerskab af domænet.
Modtage certifikatet.
Konvertere certifikatet til den ønskede form (valgfrit). For eksempel fra pem til PKCS #12.
Installer certifikatet på webserveren.

Relativt hurtigt, ikke besværligt og forståeligt. Denne metode er helt passende, hvis vi har højst et dusin projekter. Men hvad hvis der er flere og hver har mindst tre miljøer? Klassisk dev — staging — production. I dette tilfælde er det værd at overveje automatisering af denne proces. Jeg foreslår, at vi dykker lidt ind i problemet og finder en løsning, som i fremtiden minimerer tidsforbruget på oprettelse og vedligeholdelse af certifikater. Artiklen vil indeholde en analyse af problemet og en lille guide til gentagelse.

Jeg vil på forhånd bemærke: vores virksomheds primære specialisering er .net, og derfor IIS og andre Windows-relaterede elementer. Derfor vil ACME-klienten og alle handlinger for den også blive beskrevet fra et Windows-brugers perspektiv.

Hvem er dette relevant for og nogle grunddata

Virksomhed K i person af forfatteren. URL (til eksempel): company.tld

Projekt X — et af vores projekter, hvor jeg kom til den konklusion, at vi virkelig skal bevæge os mod maksimal tidsbesparelse ved arbejde med certifikater. Dette projekt har fire miljøer: dev, test, staging og production. Dev og test ligger på vores side, staging og production hos kunden.

En særpræget ved projektet er, at det har mange moduler, som er tilgængelige som underdomæner.

Altså, vi har følgende billede:

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

For produktionen bruges et indkøbt wildcard-certifikat, der er ikke noget spørgsmål om det. Men det dækker kun det første niveau af underdomænet. Hvis der er et certifikat for *.projectX.tld, vil det fungere for staging.projectX.tld, men ikke for module1.staging.projectX.tld. At købe et separat certifikat virker ikke særlig tiltalende.

Og dette er kun et eksempel fra ét projekt fra et firma. Og projektet er naturligvis ikke det eneste.

Fælles grunde til at tage fat på dette problem ser omtrent sådan her ud:

Relativt for nylig foreslog Google at reducere den maksimale gyldighedsperiode for SSL-certifikater. Med alle de følger, det har.
At lette processen med udstedelse og vedligeholdelse SSL til interne behov for projekter og firmaet som helhed.
Centralt opbevaring af registreringer af certifikater, som delvist løser problemet med domænebekræftelse via DNS og efterfølgende automatisk opdatering, samt håndterer spørgsmålet om kundetillid. Alligevel, giver et CNAME på firmaets server partner/udbyder, mere tillid end en tredjepartsressource.
Og til sidst passer sætningen "bedre at have end ikke at have" perfekt i dette tilfælde.

Valg af SSL-udbyder og forberedende skridt

Blandt de tilgængelige muligheder for gratis SSL-certifikater blev cloudflare og letsencrypt overvejet. DNS for dette (og nogle andre projekter) ligger på cloudflare, men jeg er ikke tilhænger af at bruge deres certifikater. Derfor blev det besluttet at bruge letsencrypt.
For at oprette wildcard SSL certifikatet skal bekræfte ejerskabet af domænet. Denne procedure indebærer oprettelse af en bestemt DNS-post (TXT eller CNAME), som derefter kontrolleres ved udstedelse af certifikatet. I Linux findes der et værktøj — certbot, som delvist (eller fuldt for nogle DNS-udbydere) kan automatisere denne proces. For Windows blandt de fundne og kontrollerede muligheder for ACME-klienter valgte jeg WinACME.

Og domæneposten er oprettet, lad os gå videre til oprettelsen af certifikatet:

På vej mod automatisering af SSL-udstedelse

Vi er interesserede i den sidste output, nemlig— de tilgængelige muligheder for bekræftelse af ejerskab af domænet til udstedelse af wildcard-certifikatet:

Manuel oprettelse af DNS-poster (automatisk opdatering understøttes ikke)
Oprettelse af DNS-poster ved hjælp af acme-dns-server (du kan læse mere her.
Oprettelse af DNS-poster ved hjælp af eget script (analogt med cloudflare-plugin til certbot).

Ved første øjekast ser det tredje punkt ganske passende ud, men hvis DNS-udbyderen ikke understøtter denne funktionalitet? Vi har brug for en generel løsning. Og den generelle løsning er CNAME-posterne, dem understøtter alle. Derfor stopper vi ved punkt 2, og går videre med at konfigurere vores ACME-DNS-server.

Konfiguration af ACME-DNS-serveren og processen til udstedelse af certifikatet

For example, I created the domain 2nd.pp.ua, and I will use it further.

A mandatory requirement for the correct operation of the server is the creation of NS and A records for its domain. One unpleasant moment I ran into is that Cloudflare (at least in the free usage mode) does not allow the simultaneous creation of NS and A records for the same host. It's not that it was a problem, but this can be done in bind. Support replied that their panel does not allow this. No problem, let's create two records:

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

At this stage, our host must resolve acmens.2nd.pp.ua.

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

Og her acme.2nd.pp.ua will not resolve, as the DNS server servicing it has not yet started.

Records created, let's move on to the configuration and launch of the ACME-DNS server. It will run on my Ubuntu server in docker a container, but it can be launched anywhere Golang is available. Windows will also do just fine, but I still prefer a Linux server.

We create the necessary directories and files:

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

We will use vim, your favorite text editor, and insert a sample into config.cfg configuration.

For successful operation, it is enough to adjust the general and api sections:

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

Also, optionally, we will create a docker-compose file in the main directory of the service:

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

Done. You can start it.

$ docker-compose up -d

At this stage, the host should start resolving acme.2nd.pp.ua, and a 404 should appear at 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

If this does not appear — docker logs -f will help, fortunately, the logs are quite readable.

We can proceed to create the certificate. Open PowerShell as an administrator and run winacme. We are interested in selections:

M: Create new certificate (full options)
2: Manual input
2: [dns-01] Create verification records with acme-dns (https://github.com/joohoi/acme-dns)
For the question about the link to the ACME-DNS server, we enter in response the URL of the created server (https). URL of the acme-dns server: https://acme.2nd.pp.ua

I klienten vises en post, som skal tilføjes til den eksisterende DNS-server (proceduren er engangs):

[INFO] Opretter ny acme-dns-registrering for domæne 1nd.pp.ua

Domæne:              1nd.pp.ua
Post:                _acme-challenge.1nd.pp.ua
Type:                CNAME
Indhold:             c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Bemærk:              Nogle DNS kontrolpaneler tilføjer den afsluttende prik automatisk.
                       Kun én er nødvendig.

På vej mod automatisering af SSL-udstedelse

Opretter den nødvendige post og bekræfter, at den er oprettet korrekt:

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

Bekræfter, at vi har oprettet den nødvendige post i winacme, og fortsætter med processen for at oprette certifikatet:

På vej mod automatisering af SSL-udstedelse

Hvordan man bruger certbot som klient er beskrevet her.

Processen for at oprette certifikatet er nu afsluttet, og det kan installeres på webserveren og bruges. Hvis man også opretter en opgave i planlæggeren under oprettelsen af certifikatet, vil opdateringsprocessen for certifikatet fremover ske automatisk.

Kilde: habr.com