Porque es un paso previo para crear certificados digitales con Let’s Enscrypt que incluyan comodines como en *.empresa.net. <\/p>\n\n\n\n\n\n\n\n
gandi.net<\/a> ofrece un API<\/a> para poder gestionar los productos que tengo contratados con ellos. No estoy seguro de si son todos o no porque siguen a\u00fan en transici\u00f3n hacia su versi\u00f3n 5 y parece que no est\u00e1 del todo claro si est\u00e1 completa o no.<\/p>\n\n\n\n En cualquier caso si se accede al panel de control empleando la versi\u00f3n 4, en la direcci\u00f3n https:\/\/v4.gandi.net<\/a> se puede obtener una clave para acceder al API v\u00eda XML. Primero una para efectuar pruebas y luego otra para acceder a los productos reales. La documentaci\u00f3n es bastante completa y los ejemplos aparecen descritos en varios lenguajes. He elegido Perl porque es lo que m\u00e1s seguridad me da y porque prefiero integrarlo en una peque\u00f1a aplicaci\u00f3n antes de hacerlo funcionar junto a certbot. <\/p>\n\n\n\n Casi al mismo tiempo que escribo estas l\u00edneas me encuentro una entrada del blog<\/a> de Norbert Preining en el planet<\/em> de Debian que va mucho m\u00e1s al grano que yo y lo resuelve de otra manera. Pero en mis condiciones prefiero seguir mi camino aunque me lleve m\u00e1s tiempo porque necesito entender el procedimiento. <\/p>\n\n\n\n Norbert, por ejemplo, s\u00f3lo pasa por encima de la distribuci\u00f3n de certificados y yo, que veo grandes posibilidades en que estos certificados lleven comodines y se adapten a un n\u00famero ilimitado de subdominios, tengo m\u00e1s problemas para ver una soluci\u00f3n clara. No s\u00e9 si emplear un modelo push<\/em> que copie los certificados a los servidores cliente y reinicie los servicios o un modelo pull<\/em> en el que sean \u00e9stos los que consulten cambios regularmente y hagan toda la tarea ellos mismos. <\/p>\n\n\n\n Cualquiera de los dos m\u00e9todos tienen validez inicialmente y como no me decido por uno o por otro voy a enumerarlas aqu\u00ed:<\/p>\n\n\n\n