Cara a automatizar a emisión de SSL

Moitas veces temos que traballar con certificados SSL. Lembremos o proceso de creación e instalación dun certificado (no caso xeral para a maioría).

• Atopar un provedor (un sitio onde podemos mercar SSL).
• Xerar RSE.
• Envíao ao provedor.
• Verifica a propiedade do dominio.
• Obter un certificado.
• Converte o certificado ao formulario desexado (opcional). Por exemplo, de pem a PKCS #12.
• Instale o certificado no servidor web.

Relativamente rápido, fácil e comprensible. Esta opción é bastante axeitada se temos un máximo dunha ducia de proxectos. E se hai máis deles e teñen polo menos tres ambientes? Desenvolvemento clásico - posta en escena - produción. Neste caso, paga a pena pensar en automatizar este proceso. Propoño afondar un pouco máis no problema e atopar unha solución que minimice aínda máis o tempo dedicado á creación e mantemento dos certificados. O artigo conterá unha análise do problema e unha pequena guía para a repetición.

Farei unha reserva con antelación: a principal especialización da nosa empresa é .net e, en consecuencia, IIS e outras relacionadas co parafuso. Polo tanto, o cliente ACME e todas as accións para el tamén se describirán en termos de uso de Windows.

Para quen é relevante e algúns datos de antecedentes

Empresa K representada polo autor. URL (por exemplo): empresa.tld

O proxecto X é un dos nosos proxectos, no que cheguei á conclusión de que aínda hai que avanzar cara ao máximo aforro de tempo cando se traballa con certificados. Este proxecto ten catro ambientes: dev, test, stage e production. O desenvolvemento e a proba están do noso lado, a posta en escena e a produción están do lado do cliente.

A peculiaridade do proxecto é que conta cunha gran cantidade de módulos que están dispoñibles como subdominios.

É dicir, temos a seguinte imaxe:

dev
Proba
Posición en escena
produción

proxectoX.dev.company.tld
proxectoX.proba.empresa.tld
posta en escena.proxectoX.tld
proxectoX.tld

módulo1.proxectoX.dev.empresa.tld
módulo1.proxectoX.proba.empresa.tld
module1.staging.projectX.tld
módulo1.proxectoX.tld

módulo2.proxectoX.dev.empresa.tld
módulo2.proxectoX.proba.empresa.tld
module2.staging.projectX.tld
módulo2.proxectoX.tld

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

moduleN.projectX.dev.company.tld
móduloN.proxectoX.proba.empresa.tld
moduleN.staging.projectX.tld
móduloN.proxectoX.tld

Para a produción, utilízase un certificado comodín adquirido, aquí non hai preguntas. Pero só cobre o primeiro nivel do subdominio. En consecuencia, se hai un certificado para *.projectX.tld, funcionará para staging.projectX.tld, pero non para module1.staging.projectX.tld. Non quero mercar un por separado.

E isto é só no exemplo dun proxecto dunha empresa. E o proxecto, por suposto, non está só.

As razóns xerais para abordar este problema son algo así:

• Recentemente Google propuxo reducir o período máximo de validez dos certificados SSL. Con todas as consecuencias.
• Facilitar o proceso de emisión e mantemento de SSL para as necesidades internas dos proxectos e da empresa no seu conxunto.
• Almacenamento centralizado de rexistros de certificados, que soluciona parcialmente o problema da validación do dominio mediante DNS e a posterior renovación automática, e tamén soluciona o problema da confianza do cliente. Non obstante, CNAME é máis fiable no servidor da empresa asociada/executor que nun recurso de terceiros.
• Pois, finalmente, neste caso, a frase “mellor ter que non ter” encaixa perfectamente.

Selección dun provedor SSL e pasos preparatorios

Entre as opcións dispoñibles para certificados SSL gratuítos, consideráronse cloudflare e letsencrypt. O DNS para este (e algúns outros proxectos) está aloxado por cloudflare, pero non son un fan de usar os seus certificados. Polo tanto, decidiuse usar letsencrypt.
Para crear un certificado SSL comodín, cómpre verificar a propiedade do dominio. Este procedemento implica a creación dalgún rexistro DNS (TXT ou CNAME), coa súa posterior verificación ao emitir un certificado. Linux ten unha utilidade − certbot, que lle permite automatizar parcialmente (ou completamente para algúns provedores de DNS) este proceso. Para Windows o mesmo de atopado e probado opcións para os clientes de ACME coas que me fixen WinACME.

E o rexistro para o dominio foi creado, imos pasar á creación dun certificado:

Interésanos a última conclusión, a saber, as opcións dispoñibles para verificar a propiedade do dominio para emitir un certificado comodín:

1. Crear rexistros DNS manualmente (non se admite a actualización automática)
2. Creación de rexistros DNS usando o servidor acme-dns (para máis detalles, consulte aquí.
3. Creando rexistros DNS usando o seu propio script (semellante ao complemento cloudflare para certbot).

A primeira vista, o terceiro punto é bastante axeitado, pero se o provedor de DNS non admite esta funcionalidade? E necesitamos un caso xeral. E o caso xeral son os rexistros CNAME, todos os admiten. Polo tanto, detémonos no punto 2, e imos configurar o noso servidor ACME-DNS.

Configuración do servidor ACME-DNS e proceso de emisión de certificados

Por exemplo, creei o dominio 2nd.pp.ua e usarei no futuro.

Requisito obrigatorio para o correcto funcionamento do servidor é a creación de rexistros NS e A para o seu dominio. E o primeiro momento desagradable que atopei é que cloudflare (polo menos no modo libre) non che permite crear simultaneamente un rexistro NS e A para o mesmo host. Non é que isto sexa un problema, pero si é posible. O soporte respondeu que o seu panel non permite facelo. Non importa, imos crear dúas entradas:

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

Nesta fase, debemos resolver o host acmens.2nd.pp.ua.

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

Pero acme.2nd.pp.ua non se resolverá, xa que o servidor DNS que o atende aínda non está en execución.

Creáronse os rexistros, pasemos a configurar e iniciar o servidor ACME-DNS. Vivireino no servidor ubuntu docker contenedor, pero pode executalo en calquera lugar onde haxa golang. Windows tamén está ben, pero aínda prefiro un servidor Linux.

Crea os directorios e ficheiros necesarios:

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

Usemos vim co teu editor de texto favorito e peguemos a mostra en config.cfg configuración.

Para un traballo exitoso, abonda con corrixir as seccións xerais 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"
…

Tamén, opcionalmente, cree un ficheiro docker-compose no directorio principal do servizo:

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

Listo. Podes correr.

$ docker-compose up -d

Nesta fase, o anfitrión debería comezar a resolver acme.2nd.pp.ua, e aparece 404 en 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 isto non aparece - docker logs -f <container_name> para axudar, ben, os rexistros son bastante lexibles.

Podemos comezar a crear un certificado. Abre powershell como administrador e executa winacme. Interésanos as eleccións:

• M: Crear un novo certificado (opcións completas)
• 2: Entrada manual
• 2: [dns-01] Crea rexistros de verificación con acme-dns (https://github.com/joohoi/acme-dns)
• Cando se lle pregunte sobre unha ligazón ao servidor ACME-DNS, insira o URL do servidor creado (https) como resposta. URL do servidor acme-dns: https://acme.2nd.pp.ua

Como resposta, o cliente emite un rexistro que debe engadirse ao servidor DNS existente (procedemento único):

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

Creamos a entrada necesaria e asegurámonos de que foi creada correctamente:

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

Confirmamos que creamos a entrada requirida en winacme e continuamos co proceso de creación dun certificado:

Descríbese como usar certbot como cliente aquí.

Isto completa o proceso de creación dun certificado, podes instalalo nun servidor web e usalo. Se, ao crear un certificado, tamén crea unha tarefa no planificador, no futuro o proceso de actualización do certificado producirase automaticamente.

Fonte: www.habr.com