Resumen

  • El anuncio de Let’s Encrypt del 15 de octubre prevé pasar de cuatro a seis perspectivas remotas y realizar siete solicitudes de validación en total, incluida la principal. El 27 de octubre confirmó que las seis funcionan en pruebas.
  • La tabla de quórum del CA/Browser Forum admite una falta de corroboración con dos a cinco perspectivas remotas y dos con seis o más. Las perspectivas que sí corroboran deben situarse en dos regiones RIR. El despliegue en producción está previsto para el 10 de noviembre, condicionado a las pruebas.

Un certificado empieza con una ruta

El dueño de un sitio coloca una respuesta al desafío de control del dominio. Su servidor la muestra y el administrador da por cerrado el trámite. Una autoridad de certificación tiene otra obligación: asegurarse de que la respuesta no existe únicamente en la ruta de red desde la que la observó. Un desvío BGP puede llevar a un validador hacia un destino distinto. Si una sola perspectiva bastara, un atacante que controlara ese trayecto podría obtener un certificado que después aceptarían los navegadores.

La corroboración desde varias redes convierte esa observación solitaria en una decisión contrastada. La perspectiva principal determina el resultado del control del dominio o de la consulta CAA; las remotas comprueban si ven lo mismo. Según el aviso original de Let’s Encrypt, publicado el 15 de octubre, la organización añadirá dos perspectivas a las cuatro que tenía. En el mismo hilo informó el 27 de octubre de que el entorno de pruebas ya usa seis. Su objetivo para producción es el 10 de noviembre, si las pruebas salen bien. Ese hilo todavía no contiene el anuncio de la puesta en producción.

La norma industrial dibuja el terreno. Los requisitos vigentes del CA/Browser Forum exigen al menos cuatro perspectivas remotas desde el 15 de junio de 2026 y al menos cinco desde el 15 de diciembre. Las perspectivas remotas que corroboren a la principal deben abarcar dos regiones de servicio RIR. No basta con instalar servidores en lugares pintorescos: las respuestas que dan el sí tienen que cruzar esa frontera de diversidad.

La sexta perspectiva compra un margen preciso

La tabla del Foro permite una no corroboración si se usan entre dos y cinco perspectivas distantes; con seis o más permite dos. Por tanto, cuatro respuestas concordantes de seis pueden superar el quórum aunque otras dos discrepen, siempre que se cumplan las demás condiciones. Con cinco también hacen falta cuatro respuestas concordantes, pero solo queda espacio para una discrepancia. El sexto observador compra tolerancia a una segunda respuesta adversa o ausente mediante una observación más. No se ha rebajado el mínimo práctico de voces favorables en esa comparación.

El cálculo trae letra técnica con consecuencias reales. Dos perspectivas son distintas si las separan al menos 500 kilómetros en línea recta; las remotas también deben distinguirse de la principal y entre sí dentro del quórum. Si la autoridad emplea conjuntos distintos para validar el dominio y comprobar CAA, ambos tienen que cumplir su quórum. Compartir una caché DNS entre observadores destruiría la independencia de sus respuestas, por eso la norma lo prohíbe. Si se repite la prueba, los votos de la primera tentativa no se arrastran a la siguiente.

La autoridad puede volver a preguntar; no puede construir una mayoría reuniendo aciertos de distintas rondas.

El registro operativo de 2024 confirma que Let’s Encrypt llegó entonces a cuatro perspectivas remotas en producción. El hilo de octubre de 2026 aporta un hecho nuevo y más acotado: seis en pruebas. El operador explica la ampliación como una defensa frente a desvíos BGP. La defensa depende de que las rutas y los resolutores de los testigos sean verdaderamente independientes. Una perspectiva nueva que repitiese el mismo error de otra aumentaría el contador sin añadir mucha información.

La negativa también necesita un expediente

Cuando falla el quórum o la condición de dos regiones, la norma ordena a la autoridad no emitir el certificado. Para un sitio que renueva automáticamente, esa frase puede convertirse en una interrupción visible. El desafío podría funcionar desde la oficina del administrador y fallar desde una red remota. Quien recibe el error necesita saber si falló la respuesta esperada, el acceso desde una ruta, una prohibición CAA o la distribución regional de las respuestas favorables.

El Foro permite repetir la corroboración de inmediato e incluso cambiar de método, pero exige empezar con respuestas frescas. Esa regla coloca la responsabilidad del diagnóstico en la autoridad emisora. Una nueva tentativa puede resolver un problema pasajero; acumular las respuestas convenientes de varios intentos maquillaría el expediente de emisión.

El hilo consultado no publica tasas de error en pruebas, demoras, rechazos por región ni resultados del despliegue previsto. Un aviso fechado que confirme las seis perspectivas en producción y un balance agregado de rechazos serían la prueba siguiente. Hoy el hecho comprobado es la activación en pruebas y una fecha futura condicionada.

El CA/Browser Forum decide cuántos testigos son suficientes. Let’s Encrypt decide dónde situarlos y cómo operar el sistema. El solicitante soporta la negativa. El certificado es un producto; el reparto de esas decisiones es su gobierno.