ProHoster > blog > administratie > Op weg naar automatisering van SSL-uitgifte

Op weg naar automatisering van SSL-uitgifte

Vaak moeten we werken met SSL-certificaten. Laten we het proces van het maken en installeren van een certificaat onthouden (in het algemeen voor de meeste).

  • Zoek een provider (een site waar we SSL kunnen kopen).
  • Creëer MVO.
  • Stuur het naar uw provider.
  • Domeineigendom verifiëren.
  • Diploma halen.
  • Converteer het certificaat naar het gewenste formulier (optioneel). Bijvoorbeeld van pem naar PKCS #12.
  • Installeer het certificaat op de webserver.

Relatief snel, niet ingewikkeld en begrijpelijk. Deze optie is redelijk geschikt als we maximaal tien projecten hebben. Wat als er meer zijn en ze minstens drie omgevingen hebben? Klassieke ontwikkeling - enscenering - productie. In dit geval is het de moeite waard om na te denken over het automatiseren van dit proces. Ik stel voor om wat dieper in het probleem te duiken en een oplossing te vinden die de tijd die wordt besteed aan het maken en onderhouden van certificaten verder zal minimaliseren. Het artikel bevat een analyse van het probleem en een kleine handleiding voor herhaling.

Laat ik vooraf een reservering maken: de belangrijkste specialisatie van ons bedrijf is .net, en dienovereenkomstig IIS en andere Windows-gerelateerde producten. Daarom zullen de ACME-client en alle acties daarvoor ook worden beschreven vanuit het oogpunt van het gebruik van Windows.

Voor wie is dit relevant en enkele eerste gegevens

Bedrijf K vertegenwoordigd door de auteur. URL (bijvoorbeeld): bedrijf.tld

Project X is een van onze projecten, waarbij ik tijdens het werken tot de conclusie kwam dat we nog steeds toe moeten naar maximale tijdsbesparing bij het werken met certificaten. Dit project kent vier omgevingen: dev, test, staging en productie. Dev en test staan ​​aan onze kant, enscenering en productie staan ​​aan de kant van de klant.

Bijzonder aan het project is dat het een groot aantal modules heeft die als subdomeinen beschikbaar zijn.

Dat wil zeggen, we hebben het volgende beeld:

Dev
test
Regie
productie

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

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

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

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

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

Voor de productie wordt gebruik gemaakt van een aangekocht wildcardcertificaat, hier rijzen geen vragen. Maar het bestrijkt alleen het eerste niveau van het subdomein. Dienovereenkomstig, als er een certificaat is voor *.projectX.tld, dan zal dit werken voor staging.projectX.tld, maar niet voor module1.staging.projectX.tld. Maar op de een of andere manier wil ik geen aparte kopen.

En dit is alleen gebaseerd op het voorbeeld van één project van één bedrijf. En er is natuurlijk meer dan één project.

Veelvoorkomende redenen voor iedereen om dit probleem aan te pakken, zien er ongeveer als volgt uit:

  • осительно едавно Google stelde voor om de maximale geldigheidsduur van SSL-certificaten te verkorten. Met alle gevolgen van dien.
  • Faciliteer het proces van het uitgeven en onderhouden van SSL voor de interne behoeften van projecten en het bedrijf als geheel.
  • Gecentraliseerde opslag van certificaatrecords, waardoor het probleem van domeinverificatie met behulp van DNS en daaropvolgende automatische verlenging gedeeltelijk wordt opgelost, en ook het probleem van het vertrouwen van klanten wordt opgelost. Toch is een CNAME op de server van een partner/performerbedrijf betrouwbaarder dan op een externe bron.
  • Welnu, ten slotte past in dit geval de uitdrukking ‘het is beter om te hebben dan niet te hebben’ perfect.

Een SSL-provider selecteren en voorbereidende stappen

Onder de beschikbare opties voor gratis SSL-certificaten werden cloudflare en letencrypt overwogen. De DNS hiervoor (en enkele andere projecten) wordt gehost door cloudflare, maar ik ben geen fan van het gebruik van hun certificaten. Daarom werd besloten om Letsencrypt te gebruiken.
Om een ​​wildcard SSL-certificaat aan te maken, moet u het domeineigendom bevestigen. Deze procedure omvat het maken van een DNS-record (TXT of CNAME) en het vervolgens verifiëren ervan bij het uitgeven van een certificaat. Linux heeft een hulpprogramma - certbot, waarmee u dit proces gedeeltelijk (of volledig bij sommige DNS-providers) kunt automatiseren. Voor Windows vanaf gevonden en geverifieerd ACME-clientopties waar ik voor gekozen heb WinACME.

En de record voor het domein is aangemaakt, laten we verder gaan met het maken van een certificaat:

Op weg naar automatisering van SSL-uitgifte

We zijn geïnteresseerd in de laatste conclusie, namelijk de beschikbare opties voor het bevestigen van domeineigendom voor het uitgeven van een wildcardcertificaat:

  1. DNS-records handmatig aanmaken (automatische update wordt niet ondersteund)
  2. DNS-records maken met behulp van de acme-dns-server (u kunt meer lezen over hier.
  3. DNS-records maken met behulp van uw eigen script (vergelijkbaar met de cloudflare-plug-in voor certbot).

Op het eerste gezicht is het derde punt redelijk passend, maar wat als de DNS-provider deze functionaliteit niet ondersteunt? Maar we hebben een algemeen geval nodig. En in het algemeen zijn dit CNAME-records, aangezien iedereen deze ondersteunt. Daarom stoppen we bij punt 2 en gaan we onze ACME-DNS-server configureren.

ACME-DNS-server en certificaatuitgifteproces instellen

Ik heb bijvoorbeeld het domein 2nd.pp.ua gemaakt en zal dit in de toekomst gebruiken.

Verplichte eis Om de server correct te laten werken, is het noodzakelijk om NS- en A-records voor zijn domein aan te maken. En het eerste onaangename moment dat ik tegenkwam, is dat cloudflare (althans in de gratis gebruiksmodus) je niet toestaat tegelijkertijd een NS- en A-record voor dezelfde host te maken. Niet dat dit een probleem is, maar in de praktijk kan het wel. De steun antwoordde dat hun panel dit niet toestaat. Geen probleem, laten we twee records maken:

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

In dit stadium zou onze gastheer een oplossing moeten vinden 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 het zal niet worden opgelost, omdat de DNS-server die het bedient nog niet actief is.

De records zijn aangemaakt, laten we verder gaan met het instellen en starten van de ACME-DNS-server. Het zal op mijn ubuntu-server staan havenarbeider container, maar u kunt het overal gebruiken waar golang beschikbaar is. Windows is ook prima geschikt, maar toch geef ik de voorkeur aan een Linux-server.

Maak de benodigde mappen en bestanden:

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

Laten we vim gebruiken met uw favoriete teksteditor en het voorbeeld in config.cfg plakken configuratie.

Voor een succesvolle werking volstaat het om de algemene en API-secties te corrigeren:

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

Indien gewenst zullen we ook een docker-compose-bestand maken in de hoofdservicemap:

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

Klaar. Je kunt het uitvoeren.

$ docker-compose up -d

In dit stadium zou de host moeten beginnen met oplossen acme.2nd.pp.uaen er verschijnt een 404 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

Als dit niet verschijnt - docker logs -f <container_name> om te helpen zijn de logboeken gelukkig goed leesbaar.

We kunnen beginnen met het maken van het certificaat. Open powershell als beheerder en voer winacme uit. Wij zijn geïnteresseerd in de verkiezingen:

  • M: Nieuw certificaat aanmaken (volledige opties)
  • 2: Handmatige invoer
  • 2: [dns-01] Maak verificatierecords aan met acme-dns (https://github.com/joohoi/acme-dns)
  • Wanneer u wordt gevraagd naar een link naar de ACME-DNS-server, voert u in het antwoord de URL van de aangemaakte server (https) in. URL van de acme-dns-server: https://acme.2nd.pp.ua

In de opening geeft de client een record af dat moet worden toegevoegd aan de bestaande DNS-server (eenmalige procedure):

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

Op weg naar automatisering van SSL-uitgifte

We maken de benodigde record aan en zorgen ervoor dat deze correct is aangemaakt:

Op weg naar automatisering van SSL-uitgifte

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

We bevestigen dat we de vereiste invoer in winacme hebben aangemaakt en gaan door met het aanmaken van een certificaat:

Op weg naar automatisering van SSL-uitgifte

Er wordt beschreven hoe u certbot als client kunt gebruiken hier.

Hiermee is het proces van het maken van een certificaat voltooid; u kunt het op de webserver installeren en gebruiken. Als u bij het aanmaken van een certificaat ook een taak in de planner aanmaakt, zal het certificaatvernieuwingsproces in de toekomst automatisch plaatsvinden.

Bron: www.habr.com

Voeg een reactie