🥇Sulla strada per l'automazione del rilascio SSL

Spesso ci troviamo a lavorare con certificati SSL. Ricapitoliamo il processo di creazione e installazione di un certificato (in linea generale per la maggior parte dei casi).

Trovare un fornitore (sito dove possiamo acquistare un SSL).
Generare un CSR.
Invialo al fornitore.
Confermare la proprietà del dominio.
Ricevere il certificato.
Convertire il certificato nel formato desiderato (opzionale). Ad esempio, da pem a PKCS #12.
Installare il certificato sul server web.

Relativamente veloce, non difficile e comprensibile. Questa opzione è abbastanza valida se abbiamo al massimo una decina di progetti. E se sono di più, e ognuno ha almeno tre ambienti? Classico dev — staging — production. In questo caso, vale la pena considerare l'automazione di questo processo. Propongo di approfondire il problema e trovare una soluzione che in futuro minimizzi il tempo impiegato per creare e gestire i certificati. L'articolo conterrà un'analisi del problema e una piccola guida per la ripetizione.

Preciso in anticipo: la specializzazione principale della nostra azienda è .net, e quindi IIS e altre derivazioni per Windows. Pertanto, il client ACME e tutte le azioni per esso saranno anche descritte dal punto di vista dell'uso di Windows.

A chi è pertinente e alcuni dati di base

L'azienda K rappresentata dall'autore. URL (per esempio): company.tld

Il progetto X è uno dei nostri progetti, e occupandomene sono giunto alla conclusione che è necessario puntare alla massima economia di tempo nel lavoro con i certificati. Questo progetto ha quattro ambienti: dev, test, staging e production. Dev e test sono dalla nostra parte, staging e production sono dal lato del cliente.

La caratteristica del progetto è che ha un gran numero di moduli disponibili come sottodomini.

Quindi, abbiamo la seguente situazione:

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

Per production si utilizza un certificato wildcard acquistato, qui non ci sono dubbi. Ma copre solo il primo livello del sottodominio. Di conseguenza, se c'è un certificato per *.projectX.tld — allora funzionerà per staging.projectX.tld, mentre per module1.staging.projectX.tld no. E non mi va di acquistarne uno separato.

E questo è solo un esempio di un progetto di una singola azienda. E naturalmente, il progetto non è uno solo.

Le ragioni comuni per affrontare questa questione appaiono più o meno così:

Relativamente di recente Google ha proposto di ridurre la durata massima dei certificati SSL. Con tutte le conseguenze del caso.
Semplificare il processo di emissione e gestione SSL per le esigenze interne dei progetti e dell'azienda in generale.
Archiviazione centralizzata delle registrazioni sui certificati, che risolve parzialmente il problema della verifica del dominio tramite DNS e il successivo aggiornamento automatico, oltre a sollevare questioni di fiducia per il cliente. Tuttavia, più fiducia suscita un CNAME su server aziendale del partner/esecutore, piuttosto che su una risorsa esterna.
E infine, in questo caso la frase "meglio averlo che non averlo" è perfettamente adatta.

Scelta del fornitore SSL e passaggi preparatori

Tra le opzioni disponibili per i certificati SSL gratuiti, sono stati presi in considerazione cloudflare e letsencrypt. Il DNS per questo (e per alcuni altri progetti) è ospitato su cloudflare, ma non sono favorevole all'uso dei loro certificati. Pertanto, è stato deciso di utilizzare letsencrypt.
Per creare certificato SSL wildcard è necessario confermare il possesso del dominio. Questa procedura prevede la creazione di un record DNS (TXT o CNAME), seguito dalla sua verifica al momento dell'emissione del certificato. In Linux esiste un'utilità — certbot, che consente di automatizzare parzialmente (o completamente per alcuni fornitori DNS) questo processo. Per Windows, invece, tra le opzioni trovate e verificate di client ACME mi sono fermato a WinACME.

E il record per il dominio è stato creato, passiamo alla creazione del certificato:

Verso l'automazione dell'emissione di SSL

Ci interessa l'ultima uscita, vale a dire — le opzioni disponibili per confermare il possesso del dominio per l'emissione del certificato wildcard:

Creazione manuale dei record DNS (l'aggiornamento automatico non è supportato)
Creazione dei record DNS utilizzando il server acme-dns (puoi leggere di più qui.
Creazione dei record DNS utilizzando un proprio script (analogo al plugin cloudflare per certbot).

A prima vista, il terzo punto sembra adatto, ma se il fornitore DNS non supporta questa funzionalità? E noi abbiamo bisogno di un caso generale. E il caso generale sono i record CNAME, tutti li supportano. Pertanto, ci fermiamo al punto 2 e andiamo a configurare il nostro server ACME-DNS.

Configurazione del server ACME-DNS e il processo di emissione del certificato

Per esempio, ho creato il dominio 2nd.pp.ua e lo utilizzerò in seguito.

Un requisito obbligatorio per il corretto funzionamento del server è la creazione di record NS e A per il suo dominio. E il primo inconveniente che ho riscontrato è che cloudflare (almeno nella modalità gratuita) non consente di creare simultaneamente un record NS e un record A per lo stesso host. Non che questo fosse un problema, ma in bind è possibile. Il supporto ha risposto che il loro pannello non lo consente. Non è un problema, creiamo due record:

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

A questo punto il nostro host deve risolvere acmens.2nd.pp.ua.

$ ping acmens.2nd.pp.ua
PING acmens.2nd.pp.ua (35.237.128.147) 56(84) byte di dati

Ecco acme.2nd.pp.ua non sarà risolto, poiché il server DNS che lo gestisce non è ancora avviato.

I record sono stati creati, passiamo alla configurazione e all'avvio del server ACME-DNS. Vivrà su un server Ubuntu in docker un container, ma può essere avviato ovunque ci sia golang. Anche Windows va bene, ma preferisco comunque un server Linux.

Creiamo le directory e i file necessari:

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

Utilizziamo vim, il vostro editor di testo preferito, e inseriamo in config.cfg un esempio configurazione.

Per un funzionamento riuscito è sufficiente modificare le sezioni general e 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"
…

Inoltre, se desiderato, creiamo un file docker-compose nella directory principale del servizio:

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

Fatto. Possiamo avviare.

$ docker-compose up -d

A questo punto dovrebbe iniziare a risolvere l'host acme.2nd.pp.ua, e apparire il 404 su https://acme.2nd.pp.ua

$ ping acme.2nd.pp.ua
PING acme.2nd.pp.ua (35.237.128.147) 56(84) byte di dati.

$ curl https://acme.2nd.pp.ua
404 pagina non trovata

Se non appare questo — docker logs -f è d'aiuto, per fortuna i log sono abbastanza leggibili.

Possiamo iniziare a creare il certificato. Apriamo PowerShell come amministratore e avviamo winacme. Ci interessano le scelte:

M: Crea nuovo certificato (opzioni complete)
2: Inserimento manuale
2: [dns-01] Crea record di verifica con acme-dns (https://github.com/joohoi/acme-dns)
Alla domanda sul link al server ACME-DNS, rispondiamo con l'URL del server creato (https). URL del server acme-dns: https://acme.2nd.pp.ua

Nel client di output viene fornita una registrazione che deve essere aggiunta a un server DNS esistente (procedura da eseguire una sola volta):

[INFO] Creazione di una nuova registrazione acme-dns per il dominio 1nd.pp.ua

Dominio:              1nd.pp.ua
Record:               _acme-challenge.1nd.pp.ua
Tipo:                   CNAME
Contenuto:            c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Nota:                   Alcuni pannelli di controllo DNS aggiungono automaticamente il punto finale.
                           È necessaria solo una volta.

Verso l'automazione dell'emissione di SSL

Creiamo la registrazione necessaria e ci assicuriamo che sia stata creata correttamente:

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

Confermiamo di aver creato la registrazione necessaria in winacme e continuiamo il processo di creazione del certificato:

Verso l'automazione dell'emissione di SSL

Come utilizzare certbot come client è descritto qui.

A questo punto, il processo di creazione del certificato è completato; è possibile installarlo sul server web e utilizzarlo. Se durante la creazione del certificato viene anche creato un compito nel pianificatore, in futuro il processo di aggiornamento del certificato avverrà automaticamente.

Fonte: habr.com