Verso l'automazione dell'emissione SSL

Molto spesso dobbiamo lavorare con i certificati SSL. Ricordiamo il processo di creazione e installazione di un certificato (nel caso generale per la maggior parte).

• Trova un provider (un sito dove possiamo acquistare SSL).
• Genera CSR.
• Invialo al tuo provider.
• Verifica la proprietà del dominio.
• Ottieni un certificato.
• Convertire il certificato nel modulo richiesto (facoltativo). Ad esempio, da pem a PKCS #12.
• Installa il certificato sul server web.

Relativamente veloce, non complicato e comprensibile. Questa opzione è abbastanza adatta se abbiamo un massimo di dieci progetti. E se ce ne fossero di più e avessero almeno tre ambienti? Sviluppo classico - messa in scena - produzione. In questo caso, vale la pena pensare ad automatizzare questo processo. Propongo di approfondire un po' il problema e trovare una soluzione che riduca ulteriormente al minimo il tempo impiegato per la creazione e il mantenimento dei certificati. L'articolo conterrà un'analisi del problema e una piccola guida alla ripetizione.

Vorrei effettuare una prenotazione in anticipo: la specializzazione principale della nostra azienda è .net e, di conseguenza, IIS e altri prodotti correlati a Windows. Pertanto, il client ACME e tutte le relative azioni verranno descritte anche dal punto di vista dell'utilizzo di Windows.

Per chi è rilevante e alcuni dati iniziali

Azienda K rappresentata dall'autore. URL (ad esempio): azienda.tld

Il Progetto X è uno dei nostri progetti, mentre lavoravo al quale sono giunto alla conclusione che dobbiamo ancora muoverci verso il massimo risparmio di tempo quando lavoriamo con i certificati. Questo progetto ha quattro ambienti: sviluppo, test, staging e produzione. Sviluppo e test sono dalla nostra parte, staging e produzione sono dalla parte del cliente.

Una particolarità del progetto è che dispone di un gran numero di moduli disponibili come sottodomini.

Cioè, abbiamo la seguente immagine:

Dev
Test
Staging
Produzione

projectX.dev.company.tld
progettoX.test.company.tld
staging.projectX.tld
progettoX.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 produzione viene utilizzato un certificato jolly acquistato, qui non sorgono domande. Ma copre solo il primo livello del sottodominio. Di conseguenza, se esiste un certificato per *.projectX.tld, funzionerà per staging.projectX.tld, ma non per module1.staging.projectX.tld. Ma in qualche modo non voglio comprarne uno separato.

E questo si basa solo sull'esempio di un progetto di un'azienda. E, naturalmente, c'è più di un progetto.

I motivi comuni per cui tutti dovrebbero affrontare questo problema sono simili a questi:

• тносительно недавно Google ha proposto di ridurre il periodo massimo di validità dei certificati SSL. Con tutte le conseguenze.
• Facilitare il processo di emissione e mantenimento di SSL per le esigenze interne dei progetti e dell'azienda nel suo insieme.
• Archiviazione centralizzata dei record dei certificati, che risolve parzialmente il problema della verifica del dominio tramite DNS e il successivo rinnovo automatico, risolvendo anche il problema della fiducia del cliente. Tuttavia, un CNAME sul server di un'azienda partner/esecutore è più affidabile che su una risorsa di terze parti.
• Ebbene, finalmente, in questo caso la frase “è meglio avere che non avere” calza a pennello.

Selezione di un provider 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 alcuni altri progetti) è ospitato da cloudflare, ma non sono un fan dell'utilizzo dei loro certificati. Pertanto si è deciso di utilizzare letsencrypt.
Per creare un certificato SSL con caratteri jolly, è necessario confermare la proprietà del dominio. Questa procedura prevede la creazione di alcuni record DNS (TXT o CNAME) e la successiva verifica al momento dell'emissione di un certificato. Linux ha un'utilità: certbot, che consente di automatizzare parzialmente (o completamente per alcuni provider DNS) questo processo. Per Windows da trovato e verificato Opzioni client ACME che ho scelto WinACME.

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

A noi interessa l'ultima conclusione, ovvero le opzioni disponibili per confermare la proprietà del dominio per l'emissione di un certificato con caratteri jolly:

1. Crea manualmente i record DNS (l'aggiornamento automatico non è supportato)
2. Creazione di record DNS utilizzando il server acme-dns (puoi leggere ulteriori informazioni su qui.
3. Creazione di record DNS utilizzando il tuo script (simile al plug-in cloudflare per certbot).

A prima vista, il terzo punto è abbastanza adatto, ma cosa succede se il provider DNS non supporta questa funzionalità? Ma abbiamo bisogno di un caso generale. E il caso generale sono i record CNAME, poiché tutti li supportano. Ci fermiamo quindi al punto 2 e andiamo a configurare il nostro server ACME-DNS.

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

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

Requisito obbligatorio Affinché il server funzioni correttamente è necessario creare i record NS e A per il suo dominio. E il primo momento spiacevole che ho riscontrato è che cloudflare (almeno in modalità di utilizzo gratuito) non consente di creare contemporaneamente record NS e A per lo stesso host. Non che questo sia un problema, ma in caso di vincolo è possibile. Il supporto ha risposto che il loro pannello non consente di farlo. Nessun 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 dovrebbe risolversi acmens.2nd.pp.ua.

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

Ma acme.2nd.pp.ua non si risolverà, poiché il server DNS che lo serve non è ancora in esecuzione.

Creati i record, si procede alla configurazione e al lancio del server ACME-DNS. Vivrà sul mio server Ubuntu in scaricatore di porto container, ma puoi eseguirlo ovunque sia disponibile golang. Anche Windows è abbastanza adatto, ma preferisco comunque un server Linux.

Creare le directory e i file necessari:

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

Usiamo vim con il tuo editor di testo preferito e incolliamo l'esempio in config.cfg configurazione.

Per un funzionamento corretto, è sufficiente correggere le sezioni generale 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 si desidera, creeremo 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

Pronto. Puoi eseguirlo.

$ docker-compose up -d

A questo punto l'host dovrebbe iniziare a risolvere acme.2nd.pp.uae appare un 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

Se questo non appare - docker logs -f <container_name> per aiutare, fortunatamente, i log sono abbastanza leggibili.

Possiamo iniziare a creare il certificato. Apri PowerShell come amministratore ed esegui winacme. A noi interessano le elezioni:

• 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 su un collegamento al server ACME-DNS, inserire nella risposta l'URL del server creato (https). URL del server acme-dns: https://acme.2nd.pp.ua

All'apertura, il client emette un record che deve essere aggiunto al server DNS esistente (procedura una tantum):

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

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 la voce richiesta in winacme e continuiamo il processo di creazione di un certificato:

Viene descritto come utilizzare certbot come client qui.

Questo completa il processo di creazione di un certificato; puoi installarlo sul server web e utilizzarlo. Se, durante la creazione di un certificato, crei anche un'attività nello scheduler, in futuro il processo di rinnovo del certificato avverrà automaticamente.

Fonte: habr.com