Verso l'automazione del rilascio SSL

Spesso ci troviamo a lavorare con certificati SSL. Rivediamo il processo di creazione e installazione del certificato (in generale per la maggior parte).

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

Relativamente veloce, non complicato e chiaro. Questa opzione è adeguata se abbiamo al massimo una decina di progetti. E se sono di più e ciascuno ha almeno tre ambienti? Classico dev — staging — production. In questo caso, è opportuno considerare l'automazione di questo processo. Proponiamo di approfondire un po' il problema e trovare una soluzione che, in seguito, minimizzi il tempo necessario per la creazione e la manutenzione dei certificati. L'articolo conterrà un'analisi del problema e una breve guida per la ripetizione.

Preciso in anticipo: la principale specializzazione della nostra azienda è .net, pertanto IIS e altre tecnologie Windows. Di conseguenza, il client ACME e tutte le azioni relative saranno descritte anche con una prospettiva di utilizzo di Windows.

A chi è rilevante e alcuni dati iniziali

L'azienda K tramite l'autore. URL (per esempio): company.tld

Il progetto X è uno dei nostri progetti, e lavorando a questo ho concluso che fosse necessario lavorare per massimizzare il risparmio di tempo nel trattamento dei certificati. Questo progetto ha quattro ambienti: dev, test, staging e production. Dev e test sono dalla nostra parte, staging e production sono del cliente.

La particolarità del progetto è che ha un gran numero di moduli accessibili come sottodomini.

Cioè, 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 la production viene utilizzato un certificato wildcard acquistato, quindi non ci sono dubbi. Tuttavia, copre solo il primo livello del sottodominio. Di conseguenza, se ho un certificato per *.projectX.tld, funzionerà per staging.projectX.tld, ma non per module1.staging.projectX.tld. Non si ha voglia di acquistare uno separato.

E questo è solo un esempio di un progetto di un'azienda. E il progetto, naturalmente, non è unico.

Le ragioni generali per affrontare questo problema si possono riassumere così:

• Recentemente Google ha proposto di ridurre il termine massimo di validità dei certificati SSL. Con tutte le conseguenze.
• Facilitare il processo di emissione e manutenzione SSL per le esigenze interne dei progetti e dell'azienda in generale.
• Conservazione centralizzata dei registri sui certificati, che risolve parzialmente il problema della verifica del dominio tramite DNS e dell'aggiornamento automatico successivo, oltre a garantire una maggiore fiducia da parte del cliente. Infatti, un CNAME sul server dell'azienda partner/esecutore, è generalmente considerato più affidabile rispetto a una risorsa esterna.
• Pertanto, in questo caso, la frase 'meglio avere che non avere' si adatta perfettamente.

Scelta del provider SSL e passaggi preparatori

Tra le opzioni disponibili per certificati SSL gratuiti, sono stati considerati cloudflare e letsencrypt. DNS per questo (e per alcuni altri progetti) è posizionato su cloudflare, ma non sono favorevole all'utilizzo dei loro certificati. Pertanto, si è deciso di usare letsencrypt.
Per creare Per il certificato wildcard SSL bisogna confermare la proprietà del dominio. Questa procedura prevede la creazione di un certo record DNS (TXT o CNAME), da verificare successivamente al momento dell'emissione del certificato. Su Linux c'è un'utilità — , che consente di automatizzare parzialmente (o completamente per alcuni fornitori DNS) questo processo. Per Windows, invece, tra le certbotopzioni trovate e testate, ho scelto WinACME. E ora che il record per il dominio è creato, passiamo alla creazione del certificato: Ci interessa l'ultima uscita, ovvero le opzioni disponibili per la verifica della proprietà di dominio per l'emissione del certificato wildcard:.

Creazione manuale dei record DNS (l'aggiornamento automatico non è supportato)

Creazione dei record DNS tramite server acme-dns (si possono leggere di più

1. Creazione dei record DNS tramite uno script personalizzato (analogo al plugin cloudflare per certbot).
2. A prima vista, il terzo punto sembra funzionare, ma se il fornitore DNS non supporta questa funzionalità? E noi abbiamo bisogno di un caso generale. Il caso generale è un record CNAME, tutti li supportano. Di conseguenza, ci fermiamo al punto 2 e procediamo a configurare il nostro server ACME-DNS. qui.
3. Configurazione del server ACME-DNS e processo di emissione del certificato.

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

Configurazione del server ACME-DNS e 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 creare i record NS e A per il suo dominio. E il primo inconveniente che ho riscontrato è che Cloudflare (almeno nella modalità gratuita) non permette di creare contemporaneamente i record NS e A per lo stesso host. Non è che sia un problema, ma in bind è possibile. Il supporto ha risposto che il loro pannello non lo consente. Non preoccupatevi, creeremo 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 risolversi acmens.2nd.pp.ua.

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

Ecco acme.2nd.pp.ua non si risolverà, poiché il server DNS che lo gestisce non è ancora attivo.

I record sono stati creati, passiamo alla configurazione e all'avvio del server ACME-DNS. Sarà in esecuzione su Ubuntu server in docker un contenitore, 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

Utilizzeremo Vim, il vostro editor di testo preferito, e incolleremo in config.cfg un esempio configurazione.

Per un funzionamento corretto basta 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 lo desiderate, possiamo creare 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. Ora possiamo avviare.

$ docker-compose up -d

A questo punto, l'host dovrebbe iniziare a risolversi acme.2nd.pp.ua, e dovrebbe apparire un 404 su 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

Se ciò non è apparso — docker logs -f è utile, per fortuna, i log sono abbastanza leggibili.

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

• M: Crea un nuovo certificato (tutte le opzioni)
• 2: Inserimento manuale
• 2: [dns-01] Crea record di verifica con acme-dns (https://github.com/joohoi/acme-dns)
• In risposta alla domanda sul link al server ACME-DNS, inseriamo l'URL del server creato (https). URL del server acme-dns: https://acme.2nd.pp.ua

Il client fornisce il record che deve essere aggiunto al server DNS esistente (procedura una tantum):

[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.
                           Ne è richiesto solo uno.

Creiamo il record necessario e ci assicuriamo che sia stato creato correttamente:

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

Confermiamo di aver creato il necessario record in winacme e continuiamo il processo di creazione del certificato:

Come utilizzare certbot come client è descritto qui.

A questo punto, il processo di creazione del certificato è completato e possiamo installarlo sul web server e utilizzarlo. Se nel processo di creazione del certificato viene creata anche un'attività nel pianificatore, il processo di aggiornamento del certificato avverrà automaticamente in futuro.

Fonte: habr.com