Muy a menudo tenemos que trabajar con certificados SSL. Recordemos el proceso de creación e instalación de un certificado (en el caso general para la mayoría).
- Encuentre un proveedor (un sitio en el que podamos comprar SSL).
- Generar CSR.
- Envíelo a su proveedor.
- Verificar la propiedad del dominio.
- Obtenga un certificado
- Convierta el certificado a la forma deseada (opcional). Por ejemplo, de pem a PKCS # 12.
- Instale el certificado en el servidor web.
Relativamente rápido, no complicado y comprensible. Esta opción es bastante adecuada si tenemos un máximo de una docena de proyectos. ¿Y si hay más y tienen al menos tres entornos? Desarrollo clásico - puesta en escena - producción. En este caso, debe pensar en automatizar este proceso. Le sugiero que profundice en el problema y encuentre una solución que minimice el tiempo requerido para crear y mantener certificados en el futuro. El artículo presentará un análisis del problema y una pequeña guía para la repetición.
Haré una reserva por adelantado: la especialización principal de nuestra empresa es .net y, en consecuencia, IIS y otros Windows derivados. Por lo tanto, el cliente ACME y todas sus acciones también se describirán en términos de uso de Windows.
Para quién es esto relevante y algunos datos fuente
Empresa K representada por el autor. URL (por ejemplo): company.tld
El Proyecto X es uno de nuestros proyectos, con el cual llegué a la conclusión de que, de todos modos, debemos avanzar hacia el máximo ahorro de tiempo cuando trabajamos con certificados. Este proyecto tiene cuatro entornos: desarrollo, prueba, puesta en escena y producción. Dev y test están de nuestro lado, la puesta en escena y la producción están del lado del cliente.
Una característica del proyecto es que tiene una gran cantidad de módulos que están disponibles como subdominios.
Es decir, tenemos la siguiente imagen:
Para la producción, se utiliza el certificado comodín comprado, no hay preguntas. Pero cubre solo el primer nivel del subdominio. En consecuencia, si hay un certificado para * .projectX.tld, entonces funcionará para staging.projectX.tld, pero para module1.staging.projectX.tld ya no funciona. Pero no tengo ganas de comprar uno por separado.
Y este es solo un ejemplo de un proyecto de una compañía. Y el proyecto, por supuesto, no es uno.
Las razones comunes para que todos aborden este problema se parecen a esto:
- Más recientemente, Google ha propuesto reducir el período de validez máximo de los certificados SSL . Con todas las consecuencias.
- Facilitar el proceso de emisión y mantenimiento de SSL para las necesidades internas de los proyectos y la empresa en su conjunto.
- Almacenamiento centralizado de entradas de certificados, que resuelve parcialmente el problema de la verificación del dominio utilizando DNS y las actualizaciones automáticas posteriores, y también resuelve el problema de la confianza del cliente. Sin embargo, CNAME genera más confianza en el servidor de la empresa asociada / contratista que en un recurso de terceros.
- Bueno, finalmente, en este caso, la frase "mejor tener que no" encaja perfectamente.
Elección de un proveedor de SSL y pasos preparatorios
De las opciones disponibles para certificados SSL gratuitos, se consideraron cloudflare y letsencrypt. El DNS para este (y algunos otros proyectos) está alojado en cloudflare, pero no soy fanático de usar sus certificados. Por lo tanto, se decidió usar letsencrypt.
Para crear un certificado SSL comodín, debe confirmar la propiedad del dominio. Este procedimiento implica la creación de algún registro DNS (TXT o CNAME), con su posterior verificación al emitir un certificado. Linux tiene una utilidad llamada certbot , que le permite automatizar parcialmente (o completamente para algunos proveedores de DNS) este proceso. Para Windows, de las opciones de cliente ACME encontradas y probadas , me decidí por WinACME .
Y se crea el registro para el dominio, procedemos a la creación del certificado:
Estamos interesados en la última conclusión, a saber, las opciones disponibles para verificar la propiedad del dominio para emitir un certificado comodín:
- Crear registros DNS manualmente (no se admite la actualización automática)
- Creación de registros DNS usando el servidor acme-dns (puede encontrar más detalles aquí .
- Crear registros DNS utilizando su propio script (análogo del complemento cloudflare para certbot).
A primera vista, el tercer punto es bastante adecuado, pero si el proveedor de DNS no es compatible con esta funcionalidad? Y necesitamos un caso general. Y el caso general son los registros CNAME, todos ellos los 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 el proceso de emisión de certificados
Por ejemplo, creé el dominio 2nd.pp.ua, y en el futuro lo usaré.
Un requisito previo para el correcto funcionamiento del servidor es la creación de registros NS y A para su dominio. Y el primer momento desagradable que encontré: cloudflare (al menos en modo de uso libre) no le permite crear simultáneamente un registro NS y A para el mismo host. No es que fuera un problema, pero en enlace es posible. El soporte respondió que su panel no lo permite. No importa, crea dos entradas:
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 debería resolverse.
$ ping acmens.2nd.pp.ua PING acmens.2nd.pp.ua (35.237.128.147) 56(84) bytes of data
Pero acme.2nd.pp.ua no se resolverá, ya que el servidor DNS que lo atiende aún no se está ejecutando.
Se crean registros, vaya a configurar y ejecutar el servidor ACME-DNS. Lo tendré en vivo en el servidor ubuntu en el contenedor docker , pero puedes ejecutarlo donde sea que haya golang. Windows también está bien, pero todavía prefiero un servidor Linux.
Cree los directorios y archivos necesarios:
$ mkdir config $ mkdir data $ touch config/config.cfg
Aprovecha vim su editor de texto favorito e inserte una configuración de muestra en config.cfg.
Para tener éxito, solo modifique 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, cree 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 Puedes correr
$ docker-compose up -d
En esta etapa, el host acme.2nd.pp.ua debería comenzar a acme.2nd.pp.ua , y 404 debería aparecer 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
Si esto no apareciera - docker logs -f <container_name> para ayudar, afortunadamente, los registros son bastante legibles.
Podemos comenzar a crear un certificado. Abra powershell como administrador y ejecute winacme. Estamos interesados en la elección:
- M: Crear nuevo certificado (opciones completas)
- 2: entrada manual
- 2: [dns-01] Cree registros de verificación con acme-dns ( https://github.com/joohoi/acme-dns )
- Cuando se nos preguntó sobre el enlace al servidor ACME-DNS, ingresamos la URL del servidor creado (https) en respuesta. URL del servidor acme-dns: https://acme.2nd.pp.ua
En el servidor, el cliente emite una entrada que debe agregarse al servidor DNS existente (procedimiento ú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 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 creamos la entrada necesaria en winacme y continuamos el proceso de creación del certificado:
Aquí se describe cómo usar certbot como cliente.
Esto completa el proceso de creación de un certificado, puede instalarlo en un servidor web y usarlo. Si, al crear un certificado, también se crea una tarea en el planificador, en el futuro el proceso de renovación del certificado se realizará automáticamente.