Mot automatisering av SSL-utgivning

Ganska ofta måste vi arbeta med SSL-certifikat. Låt oss komma ihåg processen att skapa och installera ett certifikat (i det allmänna fallet för de flesta).

• Hitta en leverantör (en sida där vi kan köpa SSL).
• Generera CSR.
• Skicka den till din leverantör.
• Verifiera att du äger domänen.
• Få ett certifikat.
• Konvertera certifikatet till önskat formulär (valfritt). Till exempel från pem till PKCS #12.
• Installera certifikatet på webbservern.

Relativt snabbt, inte komplicerat och begripligt. Det här alternativet är ganska lämpligt om vi har högst tio projekt. Tänk om det finns fler av dem och de har minst tre miljöer? Klassisk dev - iscensättning - produktion. I det här fallet är det värt att tänka på att automatisera denna process. Jag föreslår att fördjupa mig lite djupare i problemet och hitta en lösning som ytterligare minimerar tiden som läggs på att skapa och underhålla certifikat. Artikeln kommer att innehålla en analys av problemet och en liten guide till upprepning.

Låt mig göra en reservation i förväg: vårt företags huvudsakliga specialisering är .net, och följaktligen IIS och andra Windows-relaterade produkter. Därför kommer ACME-klienten och alla åtgärder för den också att beskrivas med tanke på att använda Windows.

För vem är detta relevant och några inledande uppgifter

Företag K representeras av författaren. URL (till exempel): company.tld

Projekt X är ett av våra projekt, under arbetets gång kom jag fram till att vi fortfarande måste gå mot maximala tidsbesparingar när vi arbetar med certifikat. Detta projekt har fyra miljöer: dev, test, iscensättning och produktion. Dev och test är på vår sida, iscensättning och produktion är på kundsidan.

En speciell egenskap med projektet är att det har ett stort antal moduler som finns tillgängliga som underdomäner.

Det vill säga, vi har följande bild:

dev
Testa
Staging
Produktion

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

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

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

.
.
.
.

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

För produktion används ett köpt wildcard-certifikat, här uppstår inga frågor. Men det täcker bara den första nivån av underdomänen. Följaktligen, om det finns ett certifikat för *.projectX.tld, kommer det att fungera för staging.projectX.tld, men inte för module1.staging.projectX.tld. Men på något sätt vill jag inte köpa en separat.

Och detta är bara baserat på exemplet med ett projekt från ett företag. Och naturligtvis finns det mer än ett projekt.

Vanliga skäl för alla att ta itu med det här problemet ser ut ungefär så här:

• Nyligen Google föreslog att den maximala giltighetstiden för SSL-certifikat skulle minskas. Med alla konsekvenser.
• Underlätta processen att utfärda och underhålla SSL för projektens och företagets interna behov.
• Centraliserad lagring av certifikatposter, som delvis löser problemet med domänverifiering med DNS och efterföljande automatisk förnyelse, och löser även problemet med klientförtroende. Ändå är ett CNAME på servern hos ett partner-/utförandeföretag mer pålitligt än på en tredjepartsresurs.
• Tja, slutligen, i det här fallet passar frasen "det är bättre att ha än att inte ha" perfekt.

Välja en SSL-leverantör och förberedande steg

Bland de tillgängliga alternativen för gratis SSL-certifikat övervägdes cloudflare och letsencrypt. DNS för detta (och vissa andra projekt) är värd för cloudflare, men jag är inte ett fan av att använda deras certifikat. Därför beslutades det att använda letsencrypt.
För att skapa ett SSL-certifikat med jokertecken måste du bekräfta att du äger domänen. Denna procedur innebär att du skapar en DNS-post (TXT eller CNAME) och sedan verifierar den när du utfärdar ett certifikat. Linux har ett verktyg - certbot, vilket gör att du delvis (eller helt för vissa DNS-leverantörer) kan automatisera denna process. För Windows från hittat och verifierat ACME-klientalternativ jag slog mig på WinACME.

Och posten för domänen har skapats, låt oss gå vidare till att skapa ett certifikat:

Vi är intresserade av den sista slutsatsen, nämligen de tillgängliga alternativen för att bekräfta domänägande för att utfärda ett jokerteckencertifikat:

1. Skapa DNS-poster manuellt (automatisk uppdatering stöds inte)
2. Skapa DNS-poster med acme-dns server (du kan läsa mer om här.
3. Skapa DNS-poster med ditt eget skript (liknande cloudflare-plugin för certbot).

Vid första anblicken är den tredje punkten ganska lämplig, men vad händer om DNS-leverantören inte stöder denna funktionalitet? Men vi behöver ett allmänt fall. Och det allmänna fallet är CNAME-poster, eftersom alla stöder dem. Därför stannar vi vid punkt 2 och går för att konfigurera vår ACME-DNS-server.

Konfigurera ACME-DNS-server och certifikatutfärdandeprocess

Till exempel skapade jag domänen 2nd.pp.ua och kommer att använda den i framtiden.

Obligatoriskt krav För att servern ska fungera korrekt är det nödvändigt att skapa NS- och A-poster för dess domän. Och det första obehagliga ögonblicket som jag stötte på är att cloudflare (åtminstone i fritt användningsläge) inte tillåter dig att samtidigt skapa en NS- och A-post för samma värd. Inte för att detta är ett problem, men i bindning är det möjligt. Supporten svarade att deras panel inte tillåter detta. Inga problem, låt oss skapa två poster:

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

I det här skedet bör vår värd lösa det 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 kommer inte att lösas, eftersom DNS-servern som betjänar den inte körs ännu.

Posterna har skapats, vi fortsätter med att ställa in och starta ACME-DNS-servern. Den kommer att leva på min ubuntu-server i hamnarbetare container, men du kan köra den var som helst där golang är tillgänglig. Windows är också ganska lämpligt, men jag föredrar fortfarande en Linux-server.

Skapa nödvändiga kataloger och filer:

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

Låt oss använda vim med din favorittextredigerare och klistra in provet i config.cfg konfiguration.

För framgångsrik drift räcker det att korrigera de allmänna och api-sektionerna:

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

Om så önskas kommer vi också att skapa en docker-compose-fil i huvudtjänstkatalogen:

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

Redo. Du kan köra den.

$ docker-compose up -d

I detta skede bör värden börja lösa sig acme.2nd.pp.ua, och en 404 visas 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

Om detta inte visas - docker logs -f <container_name> för att hjälpa, lyckligtvis är loggarna ganska läsbara.

Vi kan börja skapa certifikatet. Öppna powershell som administratör och kör winacme. Vi är intresserade av valet:

• M: Skapa nytt certifikat (fullständiga alternativ)
• 2: Manuell inmatning
• 2: [dns-01] Skapa verifieringsposter med acme-dns (https://github.com/joohoi/acme-dns)
• När du tillfrågas om en länk till ACME-DNS-servern anger du URL:en för den skapade servern (https) i svaret. URL till acme-dns-servern: https://acme.2nd.pp.ua

I öppningen utfärdar klienten en post som måste läggas till den befintliga DNS-servern (engångsprocedur):

[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 skapar den nödvändiga posten och ser till att den skapades korrekt:

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

Vi bekräftar att vi har skapat den obligatoriska posten i winacme och fortsätter processen med att skapa ett certifikat:

Hur man använder certbot som klient beskrivs här.

Detta slutför processen med att skapa ett certifikat; du kan installera det på webbservern och använda det. Om du, när du skapar ett certifikat, även skapar en uppgift i schemaläggaren, kommer certifikatförnyelsen i framtiden att ske automatiskt.

Källa: will.com