🥇 En el camino hacia la automatización de la emisión de SSL

A menudo tenemos que trabajar con certificados SSL. Recordemos el proceso de creación e instalación de un certificado (en general, para la mayoría).

Encontrar un proveedor (un sitio donde podamos comprar SSL).
Generar un CSR.
Enviárselo al proveedor.
Confirmar la propiedad del dominio.
Recibir el certificado.
Convertir el certificado a la forma requerida (opcional). Por ejemplo, de pem a PKCS #12.
Instalar el certificado en el servidor web.

Relativamente rápido, no complicado y claro. Esta opción es adecuada si tenemos un máximo de diez proyectos. ¿Pero qué pasa si hay más y cada uno tiene al menos tres entornos? Clásico dev - staging - production. En este caso, vale la pena considerar la automatización de este proceso. Propongo profundizar un poco en el problema y encontrar una solución que minimice en el futuro los costos de tiempo para crear y mantener certificados. El artículo incluirá un análisis del problema y una pequeña guía para la repetición.

Quiero aclarar de antemano: la especialización principal de nuestra empresa es .net, así que IIS y otros aspectos relacionados con Windows también se describirán desde la perspectiva del uso de Windows.

Para quién es relevante y algunos datos iniciales

La empresa K en la persona del autor. URL (como ejemplo): company.tld

El proyecto X — uno de nuestros proyectos, trabajando en el cual llegué a la conclusión de que es necesario avanzar hacia la maximización del ahorro de tiempo al trabajar con certificados. Este proyecto tiene cuatro entornos: dev, test, staging y production. Dev y test están de nuestro lado, staging y production en el lado del cliente.

Una característica del proyecto es que tiene un gran número de módulos, que están disponibles como subdominios.

Es decir, tenemos la siguiente imagen:

Dev
Prueba
Staging
Producción

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

Para producción se utiliza un certificado wildcard adquirido, por lo que no hay preguntas al respecto. Pero solo cubre el primer nivel de subdominio. Por lo tanto, si hay un certificado para *.projectX.tld, funcionará para staging.projectX.tld, pero no para module1.staging.projectX.tld. No quiero comprar uno por separado.

Y esto es solo un ejemplo de un proyecto de una empresa. Y, por supuesto, no es el único proyecto.

Las razones generales para abordar esta cuestión son más o menos las siguientes:

Relativamente recientemente Google propuso reducir el tiempo máximo de validez de los certificados SSL. Con todas las implicaciones que esto conlleva.
Facilitar el proceso de emisión y mantenimiento SSL para las necesidades internas de los proyectos y de la empresa en su conjunto.
Almacenamiento centralizado de registros de certificados, que resuelve parcialmente el problema de verificación de dominio mediante DNS y la posterior actualización automática, además de resolver la cuestión de la confianza del cliente. De todos modos, inspira más confianza un CNAME en el servidor de la empresa del socio/ejecutor, que en un recurso externo.
Y, por último, en este caso, la frase “mejor tener que no tener” encaja perfectamente.

Selección del proveedor de SSL y pasos preparatorios

De las opciones disponibles de certificados SSL gratuitos, se consideraron cloudflare y letsencrypt. El DNS para esto (y otros proyectos) se encuentra en cloudflare, pero no soy partidario de usar sus certificados. Por lo tanto, se decidió utilizar letsencrypt.
Para crear un certificado SSL wildcard es necesario comprobar la propiedad del dominio. Este procedimiento implica la creación de un registro DNS (TXT o CNAME) que se verificará posteriormente al emitir el certificado. En Linux hay una utilidad — certbot, que permite automatizar parcialmente (o completamente para algunos proveedores de DNS) este proceso. Para Windows, de las opciones encontradas y verificadas de clientes ACME, me decidí por WinACME.

Ya que se ha creado el registro para el dominio, pasamos a la creación del certificado:

En el camino hacia la automatización de la emisión de SSL

Nos interesa la última salida, es decir, las opciones disponibles para verificar la propiedad del dominio para emitir el certificado wildcard:

Creación de registros DNS manualmente (no se admite la actualización automática)
Creación de registros DNS utilizando un servidor acme-dns (se puede leer más al respecto aquí.
Creación de registros DNS utilizando un script propio (análogo al plugin de cloudflare para certbot).

A primera vista, el tercer punto parece adecuado, pero ¿qué pasa si el proveedor de DNS no admite esta funcionalidad? Necesitamos un caso general. Un caso general son los registros CNAME, que todos admiten. Por lo tanto, nos detenemos en el punto 2 y vamos a configurar nuestro servidor ACME-DNS.

Configuración del servidor ACME-DNS y proceso de emisión de certificados

Por ejemplo, he creado el dominio 2nd.pp.ua, y lo utilizaré más adelante.

Un requisito obligatorio para el correcto funcionamiento del servidor es la creación de registros NS y A para su dominio. Y el primer inconveniente con el que me encontré es que Cloudflare (al menos en la modalidad gratuita) no permite crear simultáneamente un registro NS y un registro A para el mismo host. No es que sea un problema, pero en BIND esto se puede hacer. El soporte respondió que su panel no lo permite. No hay problema, crearemos dos registros:

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

En esta etapa, el host acmens.2nd.pp.ua.

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

Y aquí está acme.2nd.pp.ua no se resolverá, ya que el servidor DNS que lo atiende aún no está en línea.

Los registros se han creado, pasamos a la configuración y inicio del servidor ACME-DNS. Vivirá en mi servidor Ubuntu en docker un contenedor, pero se puede iniciar en cualquier lugar donde haya Go. Windows también es adecuado, pero prefiero Linux para el servidor.

Creamos los directorios y archivos necesarios:

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

Usaremos vim, su editor de texto favorito, e insertaremos en config.cfg un ejemplo configuración.

Para un funcionamiento exitoso, basta con modificar las secciones general y 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"
…

Además, si lo desea, crearemos un archivo docker-compose en el directorio principal del servicio:

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. Ya se puede iniciar.

$ docker-compose up -d

En esta etapa, el host debe comenzar a resolverse acme.2nd.pp.ua, y aparecerá un 404 en https://acme.2nd.pp.ua

$ ping acme.2nd.pp.ua
PING acme.2nd.pp.ua (35.237.128.147) 56(84) bytes de data.

$ curl https://acme.2nd.pp.ua
404 página no encontrada

Si no aparece esto — docker logs -f es de ayuda, afortunadamente, los registros son bastante legibles.

Podemos comenzar a crear el certificado. Abrimos PowerShell como administrador y ejecutamos winacme. Nos interesan las opciones:

M: Crear nuevo certificado (todas las opciones)
2: Entrada manual
2: [dns-01] Crear registros de verificación con acme-dns (https://github.com/joohoi/acme-dns)
A la pregunta sobre el enlace al servidor ACME-DNS, introducimos la URL del servidor creado (https). URL del servidor acme-dns: https://acme.2nd.pp.ua

El cliente proporciona un registro que debe agregarse al servidor DNS existente (el procedimiento es único):

[INFO] Creando nueva inscripción acme-dns para el dominio 1nd.pp.ua

Dominio:              1nd.pp.ua
Registro:             _acme-challenge.1nd.pp.ua
Tipo:                 CNAME
Contenido:           c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Nota:                Algunos paneles de control de DNS añaden el punto final automáticamente.
                      Solo se requiere uno.

En el camino hacia la automatización de la emisión de SSL

Creamos el registro necesario y nos aseguramos de que se haya creado correctamente:

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

Confirmamos que hemos creado el registro necesario en winacme y continuamos con el proceso de creación del certificado:

En el camino hacia la automatización de la emisión de SSL

Cómo usar certbot como cliente se describe aquí.

Con esto se completa el proceso de creación del certificado; ahora se puede instalar en el servidor web y utilizar. Si al crear el certificado también se crea una tarea en el programador, el proceso de actualización del certificado se llevará a cabo automáticamente en el futuro.

Fuente: habr.com