Porque es un paso previo para crear certificados digitales con Let’s Enscrypt que incluyan comodines como en *.empresa.net.
gandi.net ofrece un API para poder gestionar los productos que tengo contratados con ellos. No estoy seguro de si son todos o no porque siguen aún en transición hacia su versión 5 y parece que no está del todo claro si está completa o no.
En cualquier caso si se accede al panel de control empleando la versión 4, en la dirección https://v4.gandi.net se puede obtener una clave para acceder al API vía XML. Primero una para efectuar pruebas y luego otra para acceder a los productos reales. La documentación es bastante completa y los ejemplos aparecen descritos en varios lenguajes. He elegido Perl porque es lo que más seguridad me da y porque prefiero integrarlo en una pequeña aplicación antes de hacerlo funcionar junto a certbot.
Casi al mismo tiempo que escribo estas líneas me encuentro una entrada del blog de Norbert Preining en el planet de Debian que va mucho más al grano que yo y lo resuelve de otra manera. Pero en mis condiciones prefiero seguir mi camino aunque me lleve más tiempo porque necesito entender el procedimiento.
Norbert, por ejemplo, sólo pasa por encima de la distribución de certificados y yo, que veo grandes posibilidades en que estos certificados lleven comodines y se adapten a un número ilimitado de subdominios, tengo más problemas para ver una solución clara. No sé si emplear un modelo push que copie los certificados a los servidores cliente y reinicie los servicios o un modelo pull en el que sean éstos los que consulten cambios regularmente y hagan toda la tarea ellos mismos.
Cualquiera de los dos métodos tienen validez inicialmente y como no me decido por uno o por otro voy a enumerarlas aquí:
| Método | Ventajas | Desventajas |
| push | – Los certificados se distribuyen inmediatamente. – Sólo se precisa instalar un paquete en el servidor que gestiona los certificados. | – Se necesita automatizar accesos de root a root. – Además de copiar archivos es necesario ejecutar programas para reiniciar servicios. – Si lo anterior falla es más difícil de percibir y, por tanto, de notificar. |
| pull | – La importación de certificados y su instalación en la máquina es más sencilla. – La renovación de servicios es más flexible. – Si algo falla es más sencillo avisar sobre ello e incluso reintentarlo. | – Se precisan dos paquetes: uno en el servidor y otro en cada cliente. – O se crea un mecanismo específico o pueden existir grandes diferencias de tiempo entre generación y uso. |
Así que la elección no es fácil para mí. Por una parte estaría instalar y mantener un paquete en un único servidor (que encima no tendría que estar expuesto al exterior) y añadir conexiones delicadas hacia las otras máquinas que usarán los certificados. Además de transferir es necesario reiniciar servicios, y esa es otra.
Puede darse la situación de que no todas las máquinas lo reciban, por un fallo concreto que corte el proceso de transmisión, y entonces existan servicios con certificados caducos o incompletos.
El otro mecanismo aligera la carga de la máquina que renueva certificados dado que son los otros los que se conectan, comprueban y descargan los certificados y ya con ellos hacen lo que necesiten hacer, como reiniciar servicios o algo más exótico. Es mantener dos paquetes y también se precisa una conexión delicada hacia el servidor central. Esta rutina de chequeo independiente está muy bien siempre que los certificados se renueven en fechas y horas concretas. ¿ Qué ocurre si te piden, como me pasa ocasionalmente, que añada un nuevo servicio o cambie otro ? Que tendría que implementar un mecanismo de aviso a los clientes para que sincronizasen. No estoy seguro ahora mismo de si eso se daría con la suficiente asiduidad como para que mereciese la pena.
Y creo que debo parar aquí porque el razonamiento empieza a ser circular. Hagamos una pausa para dibujar algo que quede bonito y me ayude.