Vaak werken we met SSL-certificaten. Laten we het proces van het maken en installeren van een certificaat in herinnering brengen (in het algemeen voor de meeste gevallen).
- Een provider vinden (een website waar we SSL kunnen kopen).
- Een CSR genereren.
- Dit naar de provider sturen.
- Bezit van het domein bevestigen.
- Het certificaat ontvangen.
- Het certificaat in de gewenste vorm omzetten (optioneel). Bijvoorbeeld van pem naar PKCS #12.
- Het certificaat op de webserver installeren.
Relatief snel, niet moeilijk en begrijpelijk. Deze optie is prima als we maximaal een paar projecten hebben. Maar wat als er meer zijn, en elk heeft minimaal drie omgevingen? Klassiek dev — staging — production. In dat geval is het tijd om na te denken over het automatiseren van dit proces. Laten we dieper ingaan op het probleem en een oplossing vinden die in de toekomst de tijd die nodig is voor het maken en onderhouden van certificaten minimaliseert. Het artikel zal een analyse van het probleem bevatten en een korte handleiding voor herhaling.
Ik wil vooraf opmerken: de belangrijkste specialisatie van ons bedrijf is .net, en dus IIS en andere Windows-derivaten. Daarom worden de ACME-client en alle acties voor hem ook beschreven vanuit het perspectief van gebruik op Windows.
Voor wie is dit relevant en enkele basisgegevens
Bedrijf K in de persoon van de auteur. URL (bijvoorbeeld): company.tld
Project X — een van onze projecten, waarbij ik tot de conclusie kwam dat we toch de richting van maximale tijdsbesparing bij het werken met certificaten moeten inslaan. Dit project heeft vier omgevingen: dev, test, staging en production. Dev en test zijn aan onze kant, staging en production aan de kant van de klant.
Een kenmerk van het project is dat het een groot aantal modules heeft die als subdomeinen beschikbaar zijn.
Dus, we hebben het volgende beeld:
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
Voor productie wordt een aangekocht wildcardcertificaat gebruikt, daarover zijn geen vragen. Maar dit dekt alleen het eerste niveau van de subdomeinen. Dus, als er een certificaat is voor *.projectX.tld — dan werkt het voor staging.projectX.tld, maar voor module1.staging.projectX.tld weer niet. En apart eentje kopen is ook niet echt aantrekkelijk.
En dit is slechts een voorbeeld van één project van één bedrijf. Een project is natuurlijk niet het enige.
De algemene redenen om deze kwestie aan te pakken zien er ongeveer als volgt uit:
- Relatief recent heeft Google voorgesteld de maximale geldigheidsduur van SSL-certificaten te verkorten. Met alle gevolgen van dien.
- Het proces van uitgifte en onderhoud vergemakkelijken SSL voor interne behoeften van projecten en het bedrijf als geheel.
- Gecentraliseerde opslag van certificaatgegevens, die gedeeltelijk het probleem van domeinverificatie via DNS oplost en vervolgens automatische vernieuwing mogelijk maakt, evenals het vertrouwen van de klant vergroot. Toch wekt een CNAME op de server van het bedrijf partner/opdrachtnemer, meer vertrouwen dan op een externe resource.
- En tenslotte past in dit geval de uitdrukking 'beter iets hebben dan niets hebben' perfect.
De keuze van de SSL-provider en voorbereidende stappen
Van de beschikbare opties voor gratis SSL-certificaten zijn cloudflare en letsencrypt overwogen. De DNS voor dit (en enkele andere projecten) bevindt zich op cloudflare, maar ik ben geen voorstander van het gebruik van hun certificaten. Daarom is besloten letsencrypt te gebruiken.
Voor het creëren van wildcard SSL certificaat moet het eigendom van het domein worden bevestigd. Deze procedure houdt in dat er een bepaalde DNS-record (TXT of CNAME) moet worden aangemaakt, dat vervolgens wordt gecontroleerd bij het uitgeven van het certificaat. In Linux is er een tool — certbot, die dit proces gedeeltelijk (of volledig voor sommige DNS-aanbieders) kan automatiseren. Voor Windows ben ik uitgekomen op de gevonden en gecontroleerde opties van ACME-clients, en heb ik gekozen voor WinACME.
De record voor het domein is aangemaakt, laten we beginnen met het maken van het certificaat:
We zijn geïnteresseerd in de laatste uitvoer, namelijk — de beschikbare opties voor domeineigendom verificatie voor het uitgeven van een wildcardcertificaat:
- Handmatig DNS-records aanmaken (automatische vernieuwing wordt niet ondersteund)
- DNS-records aanmaken met behulp van een acme-dns-server (meer informatie kan worden gelezen here.
- DNS-records aanmaken met behulp van een eigen script (een soortgelijk plug-in van cloudflare voor certbot).
Op het eerste gezicht lijkt het derde punt prima, maar wat als de DNS-provider deze functionaliteit niet ondersteunt? We hebben echter een algemeen geval nodig. En het algemene geval zijn CNAME-records, dat ondersteunen ze allemaal. Dus blijven we bij punt 2 en gaan we onze ACME-DNS-server instellen.
Instellen van de ACME-DNS-server en het proces van certificaatuitgifte
Als voorbeeld heb ik het domein 2nd.pp.ua aangemaakt, en dat zal ik verder gebruiken.
Een verplichte vereiste voor het correcte functioneren van de server is het aanmaken van NS- en A-records voor zijn domein. En het eerste vervelende punt waar ik tegenaan liep, is dat cloudflare (tenzij in de gratis modus) niet toestaat om tegelijkertijd een NS- en A-record voor dezelfde host aan te maken. Het was niet dat dit een probleem was, maar het kan in bind. De supportafdeling antwoordde dat hun paneel dat niet toestaat. Geen probleem, we maken twee records aan:
acmens.2nd.pp.ua. IN A 35.237.128.147
acme.2nd.pp.ua. IN NS acmens.2nd.pp.ua.
Op dit moment zou de host moeten resolven acmens.2nd.pp.ua.
$ ping acmens.2nd.pp.ua
PING acmens.2nd.pp.ua (35.237.128.147) 56(84) bytes aan gegevens
Hier acme.2nd.pp.ua zal niet resolven, aangezien de DNS-server die het beheert nog niet is gestart.
Records zijn aangemaakt, laten we doorgaan met het instellen en starten van de ACME-DNS-server. Deze zal draaien op mijn ubuntu server in docker een container, maar je kunt hem overal waar golang is starten. Windows is ook prima, maar ik geef toch de voorkeur aan een Linux-server.
Laten we de nodige mappen en bestanden aanmaken:
$ mkdir config
$ mkdir data
$ touch config/config.cfg
We maken gebruik van vim, je favoriete teksteditor, en plakken in config.cfg een voorbeeld configuratie.
Voor een succesvolle werking is het genoeg om de secties general en api aan te passen:
[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"
…
Ook, als je wilt, laten we een docker-compose bestand aanmaken in de hoofdmap van de 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
Klaar. We kunnen starten.
$ docker-compose up -d
Op dit moment zou de host moeten beginnen met resolven acme.2nd.pp.ua, en er zou een 404 moeten verschijnen op https://acme.2nd.pp.ua
$ ping acme.2nd.pp.ua
PING acme.2nd.pp.ua (35.237.128.147) 56(84) bytes aan gegevens.
$ curl https://acme.2nd.pp.ua
404 pagina niet gevonden
Als dit niet is verschenen — docker logs -f kan helpen, gelukkig zijn de logs behoorlijk leesbaar.
We can start creating the certificate. Open PowerShell as an administrator and run winacme. We are interested in the options:
- M: Create new certificate (full options)
- 2: Manual input
- 2: [dns-01] Create verification records with acme-dns (https://github.com/joohoi/acme-dns)
- In response to the question about the link to the ACME-DNS server, enter the URL of the created server (https). URL of the acme-dns server: https://acme.2nd.pp.ua
The client output provides a record that needs to be added to the existing DNS server (this procedure is one-time):
[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.
Create the necessary record, and make sure it was created correctly:
$ dig CNAME _acme-challenge.1nd.pp.ua +short
c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Confirm that we have created the required record in winacme, and continue the process of creating the certificate:
How to use certbot as a client is described here.
This completes the certificate creation process, you can install it on the web server and use it. If you also create a task in the scheduler when creating the certificate, the certificate renewal process will occur automatically in the future.
Bron: habr.com
