ProHoster > Blogg > Administration > PÄ vÀg mot automatisering av SSL-publicering

PÄ vÀg mot automatisering av SSL-publicering

Ofta mÄste vi arbeta med SSL-certifikat.LÄt oss gÄ igenom processen för att skapa och installera ett certifikat (i allmÀnhet för de flesta).

 

  • Hitta en leverantör (en webbplats dĂ€r vi kan köpa SSL).
  • Generera CSR.
  • Skicka det till leverantören.
  • BekrĂ€fta Ă€gande av domĂ€nen.
  • FĂ„ certifikatet.
  • Omvandla certifikatet till önskat format (valfritt). Till exempel, frĂ„n pem till PKCS #12.
  • Installera certifikatet pĂ„ webbservern.

 

Relativt snabbt, inte svĂ„rt och förstĂ„eligt. Denna variant Ă€r helt okej om vi har högst ett tiotal projekt. Men om vi har fler, och minst tre miljöer? Klassisk dev — staging — production. I sĂ„dana fall bör man tĂ€nka pĂ„ att automatisera denna process. Jag föreslĂ„r att vi gĂ„r lite djupare in i problemet och hittar en lösning som i framtiden minimerar tidsĂ„tgĂ„ngen för att skapa och underhĂ„lla certifikat. Artikeln kommer att innehĂ„lla en analys av problemet och en liten guide för upprepning.

 

Jag vill pÄ förhand nÀmna: företagets huvudspecialisering Àr .net, och dÀrmed IIS och andra Windows-relaterade aspekter. DÀrför kommer ocksÄ ACME-klienten och alla ÄtgÀrder för den att beskrivas utifrÄn anvÀndning av Windows.

 

För vem detta Àr aktuellt och vissa grundlÀggande uppgifter.

Företag K med författaren. URL (som exempel): company.tld

 

Projekt X — ett av vĂ„ra projekt, dĂ€r jag kom fram till att man faktiskt mĂ„ste strĂ€va efter att spara tid vid arbete med certifikat. Detta projekt har fyra miljöer: dev, test, staging och production. Dev och test ligger pĂ„ vĂ„r sida, staging och production hos kunden.

 

En egenskap hos projektet Àr att det finns ett stort antal moduler, som Àr tillgÀngliga som underdomÀner.

 

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

 

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

 

För produktion anvĂ€nds ett inköpt wildcard-certifikat, sĂ„ det finns inga frĂ„gor dĂ€r. Men det tĂ€cker endast första nivĂ„n av underdomĂ€nen. Om det finns ett certifikat för *.projectX.tld — kommer det att fungera för staging.projectX.tld, men för module1.staging.projectX.tld gör det inte det. Och att köpa ett separat kĂ€nns inte sĂ„ lockande.

 

Och detta Àr bara ett exempel pÄ ett projekt frÄn ett företag. Och naturligtvis Àr projektet inte det enda.

 

AllmÀnna skÀl för alla att ta itu med denna frÄga ser ut ungefÀr sÄ hÀr:

 

  • Relativt nyligen har Google föreslagit att minska den maximala giltighetstiden för SSL-certifikat. Med alla följder som det innebĂ€r.
  • Att underlĂ€tta processen för utfĂ€rdande och underhĂ„ll SSL för interna behov av projekt och företaget i stort.
  • Centraliserad lagring av certifikatregister, som delvis löser problemet med domĂ€bekrĂ€ftelse via DNS och efterföljande automatisk uppdatering, samt löser frĂ„gan om kundens förtroende. Trots allt ger en CNAME-post pĂ„ företagets server partner/leverantör mer förtroende Ă€n pĂ„ en extern resurs.
  • Och till sist, i det hĂ€r fallet passar frasen "bĂ€ttre att ha Ă€n att inte ha" utmĂ€rkt.

 

Val av 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 nÄgra andra projekt) ligger pÄ cloudflare, men jag Àr inte en förkÀmpe för att anvÀnda deras certifikat. DÀrför beslutades det att anvÀnda letsencrypt.
För att skapa wildcard SSL certifikat mÄste bekrÀfta Àgande av domÀnen. Denna procedur innebÀr skapandet av en viss DNS-post (TXT eller CNAME), som sedan verifieras vid utfÀrdandet av certifikatet. I Linux finns det ett verktyg - certbot, som delvis (eller helt för vissa DNS-leverantörer) kan automatisera denna process. För Windows har jag av de hittade och verifierade alternativen för ACME-klienter valt WinACME.

 

Och posten för domÀnen Àr skapad, vi gÄr vidare till skapandet av certifikatet:

 

PÄ vÀg mot automatisering av SSL-publicering

 

Vi Àr intresserade av den sista utdata, nÀmligen - tillgÀngliga alternativ för bekrÀftelse av domÀnÀgande för utfÀrdande av wildcard-certifikat:

 

  1. Skapande av DNS-poster manuellt (automatisk uppdatering stöds inte)
  2. Skapande av DNS-poster med hjÀlp av acme-dns-server (lÀs mer kan man göra hÀr) ). Ett typiskt exempel pÄ anvÀndning:.
  3. Skapande av DNS-poster med hjÀlp av eget skript (liknande plugin för cloudflare för certbot).

 

Vid första anblicken verkar det tredje alternativet vara helt lÀmpligt, men om DNS-leverantören inte stödjer denna funktionalitet? Vi behöver ett allmÀnt fall. Och det allmÀnna fallet Àr CNAME-poster, som alla stöder. DÀrför stannar vi vid punkt 2 och gÄr för att konfigurera vÄr ACME-DNS-server.

 

Konfiguration av ACME-DNS-server och processen för utfÀrdande av certifikat

 

Som exempel skapade jag domÀnen 2nd.pp.ua och kommer att anvÀnda den framöver.

 

Ett obligatoriskt krav för att servern ska fungera korrekt Àr att skapa NS- och A-poster för dess domÀn. Och det första otrevliga problemet jag stötte pÄ Àr att Cloudflare (Ätminstone i gratislÀge) inte tillÄter att skapa bÄde NS- och A-poster för samma vÀrd samtidigt. Inte sÄ att det Àr ett problem, men i BIND gÄr det. Supporten svarade att deras panel inte tillÄter det. Ingen fara, vi skapar tvÄ poster:

 

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

 

I detta skede bör vÄr vÀrd acmens.2nd.pp.ua.

 

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

 

Och hÀr Àr acme.2nd.pp.ua kommer inte att kunna lösas, eftersom DNS-servern som hanterar den Ànnu inte Àr igÄng.

 

Poster skapade, nu gÄr vi vidare till konfigurering och start av ACME-DNS-servern. Den kommer att bo pÄ min Ubuntu-server i docker en behÄllare, men den kan köras var som helst dÀr Golang Àr installerat. Windows fungerar ocksÄ bra, men jag föredrar ÀndÄ Linux-server.

 

Skapa de nödvÀndiga katalogerna och filerna:

 

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

 

LÄt oss anvÀnda vim, din favorit textredigerare, och lÀgga in ett exempel i config.cfg konfiguration.

 

För att det ska fungera framgÄngsrikt rÀcker det att justera sektionerna general och api:

 

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



 

Som tillval kan vi skapa en docker-compose fil i huvudkatalogen för tjÀnsten:

 

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. Nu kan vi starta.

 

$ docker-compose up -d

 

I detta skede bör vÀrden börja lösas acme.2nd.pp.ua, och 404 bör dyka upp 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 sidan hittades inte

 

Om detta inte intrĂ€ffade — docker logs -f <container_name> för hjĂ€lp, som tur Ă€r Ă€r loggarna ganska lĂ€sbara.

 

Vi kan gĂ„ vidare till att skapa certifikatet. Öppna PowerShell som administratör och kör winacme. Vi Ă€r intresserade av följande val:

 

  • 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 vi fĂ„r frĂ„gan om lĂ€nken till ACME-DNS-servern skriver vi i svaret URL:en till den skapade servern (https). URL för acme-dns-servern: https://acme.2nd.pp.ua

 

Klienten ger en post som mÄste lÀggas till i den befintliga DNS-servern (proceduren Àr engÄngs):

 

[INFO] Skapar ny acme-dns registrering för domÀnen 1nd.pp.ua

DomÀn:              1nd.pp.ua
Post:                _acme-challenge.1nd.pp.ua
Typ:                    CNAME
InnehÄll:             c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Obs:                   Vissa DNS kontrollpaneler lÀgger automatiskt till den sista punkten.
                           Endast en Àr nödvÀndig.

 

PÄ vÀg mot automatisering av SSL-publicering

 

Skapar den nödvÀndiga posten och ser till att den har skapats korrekt:

 

PÄ vÀg mot automatisering av SSL-publicering

 

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

 

BekrÀftar att vi har skapat den nödvÀndiga posten i winacme och fortsÀtter processen med att skapa certifikatet:

 

PÄ vÀg mot automatisering av SSL-publicering

 

Hur man anvÀnder certbot som klient beskrivs ). Ett typiskt exempel pÄ anvÀndning:.

 

Nu Àr processen för att skapa certifikatet avslutad, vi kan installera det pÄ webbservern och anvÀnda det. Om man Àven skapar en uppgift i schemalÀggaren vid skapandet av certifikatet, kommer uppdateringsprocessen av certifikatet att ske automatiskt i framtiden.

KĂ€lla: habr.com

Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar đŸ”„ Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar | ProHoster