In die rigting van die outomatisering van die uitreiking van SSL

Ons moet gereeld met SSL-sertifikate werk. Kom ons onthou die proses om 'n sertifikaat te skep en te installeer (in die algemene geval vir die meeste).

• Vind 'n verskaffer ('n webwerf waar ons SSL kan koop).
• Genereer CSR.
• Stuur dit aan die verskaffer.
• Verifieer domeineienaarskap.
• Kry 'n sertifikaat.
• Skakel die sertifikaat om na die verlangde vorm (opsioneel). Byvoorbeeld, van pem na PKCS #12.
• Installeer die sertifikaat op die webbediener.

Relatief vinnig, maklik en verstaanbaar. Hierdie opsie is baie geskik as ons 'n maksimum van 'n dosyn projekte het. Wat as daar meer van hulle is, en hulle het ten minste drie omgewings? Klassieke dev - opvoering - produksie. In hierdie geval is dit die moeite werd om te dink oor die outomatisering van hierdie proses. Ek stel voor om 'n bietjie dieper in die probleem in te gaan en 'n oplossing te vind wat die tyd wat spandeer word aan die skep en instandhouding van sertifikate verder sal verminder. Die artikel sal 'n ontleding van die probleem en 'n klein gids tot herhaling bevat.

Ek sal vooraf 'n bespreking maak: die hoofspesialisasie van ons maatskappy is .net, en dienooreenkomstig IIS en ander skroefverwante. Daarom sal die ACME-kliënt en alle aksies daarvoor ook beskryf word in terme van die gebruik van vensters.

Vir wie dit relevant is en 'n paar agtergronddata

Maatskappy K verteenwoordig deur die skrywer. URL (byvoorbeeld): company.tld

Projek X is een van ons projekte, waarin ek tot die gevolgtrekking gekom het dat ons steeds moet beweeg na maksimum tydsbesparing wanneer ons met sertifikate werk. Hierdie projek het vier omgewings: ontwikkeling, toets, opvoering en produksie. Ontwikkeling en toets is aan ons kant, opvoering en produksie is aan die kliëntkant.

'n Kenmerk van die projek is dat dit 'n groot aantal modules het wat as subdomeine beskikbaar is.

Dit wil sê, ons het die volgende prentjie:

dev
Toets
Stellasies
produksie

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.projekX.tld

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

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

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

Vir produksie word 'n aangekoopte wildkaartsertifikaat gebruik, hier is geen vrae nie. Maar dit dek net die eerste vlak van die subdomein. Gevolglik, as daar 'n sertifikaat vir *.projectX.tld is, sal dit vir staging.projectX.tld werk, maar nie vir module1.staging.projectX.tld nie. Ek wil nie 'n aparte een koop nie.

En dit is slegs op die voorbeeld van een projek van een maatskappy. En die projek is natuurlik nie alleen nie.

Die algemene redes vir die aanpak van hierdie probleem lyk ongeveer soos volg:

• Onlangs Google het voorgestel om die maksimum geldigheidstydperk van SSL-sertifikate te verminder. Met al die gevolge.
• Om die proses van uitreiking en instandhouding van SSL vir die interne behoeftes van projekte en die maatskappy as geheel te vergemaklik.
• Gesentraliseerde berging van sertifikaatrekords, wat die probleem van domeinvalidering met behulp van DNS en daaropvolgende outomatiese hernuwing gedeeltelik oplos, en ook die kwessie van kliëntvertroue oplos. Nietemin, CNAME is meer betroubaar op die bediener van die vennoot/eksekuteurmaatskappy as op 'n derdeparty-hulpbron.
• Wel, uiteindelik, in hierdie geval, pas die frase "beter om te hê as om nie te hê nie" perfek.

Kies 'n SSL-verskaffer en voorbereidende stappe

Van die beskikbare opsies vir gratis SSL-sertifikate, is cloudflare en letsencrypt oorweeg. Die DNS vir hierdie (en sommige ander projekte) word deur cloudflare aangebied, maar ek is nie 'n aanhanger daarvan om hul sertifikate te gebruik nie. Daarom is besluit om letsencrypt te gebruik.
Om 'n jokerteken SSL-sertifikaat te skep, moet jy eienaarskap van die domein verifieer. Hierdie prosedure behels die skepping van een of ander DNS-rekord (TXT of CNAME), met die daaropvolgende verifikasie wanneer 'n sertifikaat uitgereik word. Linux het 'n nut − certbot, wat jou toelaat om hierdie proses gedeeltelik (of heeltemal vir sommige DNS-verskaffers) te outomatiseer. Vir Windows dieselfde vanaf gevind en getoets opsies vir ACME-kliënte waarop ek gevestig het WinACME.

En die rekord vir die domein is geskep, kom ons gaan voort met die skep van 'n sertifikaat:

Ons stel belang in die laaste gevolgtrekking, naamlik die beskikbare opsies om domeineienaarskap te verifieer vir die uitreiking van 'n wildkaartsertifikaat:

1. Skep DNS-rekords met die hand (outomatiese opdatering word nie ondersteun nie)
2. Skep DNS-rekords met behulp van die acme-dns-bediener (vir meer besonderhede, sien hier.
3. Skep DNS-rekords met jou eie skrip (soortgelyk aan die cloudflare-inprop vir certbot).

Met die eerste oogopslag is die derde punt baie geskik, maar as die DNS-verskaffer nie hierdie funksionaliteit ondersteun nie? En ons het 'n algemene saak nodig. En die algemene geval is CNAME-rekords, almal ondersteun dit. Daarom stop ons by punt 2 en gaan ons ACME-DNS-bediener instel.

ACME-DNS-bedieneropstelling en sertifikaat-uitreikingsproses

Ek het byvoorbeeld die 2nd.pp.ua-domein geskep, en ek sal dit in die toekoms gebruik.

Verpligte vereiste vir die korrekte werking van die bediener is die skepping van NS- en A-rekords vir sy domein. En die eerste onaangename oomblik wat ek teëgekom het, is dat cloudflare (ten minste in gratis modus) jou nie toelaat om gelyktydig 'n NS- en A-rekord vir dieselfde gasheer te skep nie. Nie dat dit 'n probleem is nie, maar dit is moontlik. Ondersteuning het geantwoord dat hul paneel dit nie toelaat nie. Dit maak nie saak nie, kom ons skep twee inskrywings:

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

Op hierdie stadium moet ons die gasheer oplos acmens.2nd.pp.ua.

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

Maar acme.2nd.pp.ua sal nie oplos nie, aangesien die DNS-bediener wat dit bedien, nog nie loop nie.

Die rekords is geskep, kom ons gaan voort met die opstel en begin van die ACME-DNS-bediener. Ek sal dit op ubuntu-bediener leef Docker houer, maar jy kan dit enige plek laat loop waar daar golang is. Windows is ook goed, maar ek verkies steeds 'n Linux-bediener.

Skep die nodige gidse en lêers:

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

Kom ons gebruik vim met jou gunsteling teksredigeerder en plak die voorbeeld in config.cfg opset.

Vir suksesvolle werk is dit genoeg om die algemene en API-afdelings reg te stel:

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

Skep ook opsioneel 'n docker-compose-lêer in die hoofgids van die diens:

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

Gereed. Jy kan hardloop.

$ docker-compose up -d

Op hierdie stadium moet die gasheer begin oplos acme.2nd.pp.ua, en verskyn 404 op 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

As dit nie verskyn nie - docker logs -f <container_name> om te help, goed, die logs is redelik leesbaar.

Ons kan begin om 'n sertifikaat te skep. Maak powershell oop as administrateur en hardloop winacme. Ons stel belang in die verkiesings:

• M: Skep nuwe sertifikaat (volledige opsies)
• 2: Handmatige invoer
• 2: [dns-01] Skep verifikasierekords met acme-dns (https://github.com/joohoi/acme-dns)
• As u gevra word oor 'n skakel na die ACME-DNS-bediener, voer die URL van die geskepde bediener (https) in as antwoord. URL van die acme-dns-bediener: https://acme.2nd.pp.ua

In reaksie hierop reik die kliënt 'n rekord uit wat by die bestaande DNS-bediener gevoeg moet word (eenmalige prosedure):

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

Ons skep die nodige inskrywing en maak seker dat dit korrek geskep is:

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

Ons bevestig dat ons die vereiste inskrywing in winacme geskep het, en gaan voort met die proses om 'n sertifikaat te skep:

Hoe om certbot as 'n kliënt te gebruik, word beskryf hier.

Dit voltooi die proses om 'n sertifikaat te skep, jy kan dit op 'n webbediener installeer en dit gebruik. As u, wanneer u 'n sertifikaat skep, ook 'n taak in die skeduleerder skep, sal die proses van opdatering van die sertifikaat in die toekoms outomaties plaasvind.

Bron: will.com