Hacer de la renovación una tarea de continuidad del servicio
Renovar el certificado HTTPS para un MTA-STS El host de políticas está completo solo cuando el certificado correcto se entrega realmente en el punto final requerido y un cliente de validación puede recuperar la política. Una notificación de emisión exitosa no establece la implementación, la integridad de la cadena de confianza o la disponibilidad. Organice el trabajo en torno al servicio en ejecución en lugar del orden de los certificados.
Esta guía propone un control de renovación y una revisión de fallos ficticios. No emite certificados, inspecciona claves privadas, modifica el alojamiento ni se conecta al dominio de un cliente. Aún se requieren el certificado original y las observaciones HTTP. Los propietarios deben acordar el procedimiento aprobado de implementación y reversión antes de que un operador toque el servicio.
Inventario de las dos superficies del certificado.
El certificado de host de políticas autentica un nombre como mta-sts.example.com durante la recuperación HTTPS. Los servidores SMTP receptores presentan certificados separados para sus nombres de host MX . Esos servicios pueden tener diferentes propietarios, sistemas de renovación y fechas de vencimiento. Renovar uno no soluciona el otro, incluso cuando ambos están administrados por el mismo proveedor de hosting. RFC 8461 secciones 3.3 y 4.2
Registre el nombre del host de la política, el equipo responsable, la plataforma de implementación, la huella digital del certificado público actual, el intervalo de validez y el mecanismo de renovación previsto. Incluya todas las direcciones o niveles de servicio que puedan responder por el punto final. NotBefore y notAfter de un certificado delimitan su período de validez, mientras que la validación de la ruta también depende de otras restricciones y confianza del certificado. Una fecha de vencimiento aparentemente futura por sí sola no es un resultado de validación exitoso. RFC 5280 secciones 4.1.2.5 y 6
Verificar la identidad y la cadena antes de la implementación
El host de la política debe presentar un certificado vigente válido para su identidad DNS requerida y encadenado a una raíz en la que confíe el remitente. MTA. Delegar hosting a través de un CNAME no hace que sea suficiente un certificado para el nombre de host del proveedor. Conserve el nombre de host de la política original en las pruebas de validación y documente qué cadena pública se espera que envíe el servidor. RFC 8461 secciones 3.3 y 8.2
Utilice los nombres alternativos del sujeto del certificado al evaluar la identidad del servicio previsto. RFC 9525 es la especificación general actual de identidad de servicio y deja obsoleta RFC 6125 , que cita RFC 8461 . Mantenga explícitas las reglas DNS-ID específicas de la aplicación de MTA-STS en lugar de sustituir silenciosamente el comportamiento de la aplicación no relacionada. Un nombre común legible por humanos no es motivo para renunciar a una discrepancia en el nombre de host. RFC 9525 secciones 2 y 6
Planifique suficiente tiempo para recuperarse de forma segura
Elija una fecha límite de renovación interna que deje tiempo para la emisión fallida, errores de implementación y verificación. El margen apropiado depende de la vida útil del certificado y de la propiedad operativa; Aquí no se establece ningún número universal de días. Asigne una persona responsable y un contacto de respaldo. Un trabajo programado sin un destino de alerta o un propietario es una dependencia no verificada, no un proceso de renovación completo.
Mantenga el manejo de certificados dentro del sistema de gestión de secretos aprobado. El paquete de evidencia debe contener detalles del certificado público y resultados de validación, no claves privadas ni credenciales de cuenta. Defina qué puede revertir el operador, cómo se verificará la validez actual y qué fallas requieren escalada. Restaurar un certificado caducado porque era la configuración conocida de ayer no es un plan de recuperación útil.
Pruebe el punto final implementado en lugar del archivo de certificado
Después de una implementación autorizada, la verificación propuesta debe identificar el nombre de host exacto, la dirección, la hora UTC, la cadena observada, el resultado de la validación del nombre y el resultado de la confianza. Cuando existan varios nodos de servicio, conserve el alcance realmente marcado. La prueba local exitosa de un operador no puede demostrar que todos los remitentes externos confíen en la misma raíz o lleguen al mismo nodo. Registre esos límites en lugar de convertir una observación en preparación universal.
Luego verifique que la URL original conocida produzca un HTTP 200 directo con la política prevista. El trabajo certificado puede alterar accidentalmente la selección del host virtual, el enrutamiento o los controles de acceso a las aplicaciones. MTA-STS prohíbe seguir redirecciones HTTP durante la recuperación, por lo que el éxito del navegador después de la redirección es inadecuado. La conexión TLS válida y la respuesta HTTP utilizable son condiciones de aceptación distintas. RFC 8461 secciones 3.2–3.3
Examinar un despliegue parcial ficticio
Considere example.com ficticio.com, cuyo nombre de host de política es servido por dos nodos perimetrales. Un sistema de renovación obtiene un nuevo certificado, pero sólo un nodo lo recarga. El otro continúa cumpliendo con un certificado vencido. Pasa una prueba que llega al nodo actualizado; un remitente que llega al segundo nodo no puede autenticar la política. Estas observaciones son inventadas y no establecen ningún comportamiento real del proveedor.
La investigación propuesta compara las huellas digitales públicas y los intervalos de validez en los nodos de servicio, seguidos de la recuperación autenticada en el nombre de host sin cambios. No comienza relajando las verificaciones de certificados o eliminando el registro de descubrimiento. El propietario de la reparación completaría la implementación aprobada y verificaría ambos nodos. Los certificados SMTP MX aún necesitan su propia validación porque la reparación del host de políticas no dice nada sobre su estado.
Comprender el límite de la caché durante una interrupción
Un remitente de soporte con una política almacenada en caché válida y vigente debe continuar usándola si no se puede recuperar la política activa. Un remitente sin dicha política continúa como si MTA-STS estuviera ausente después de un error en la recuperación. Por lo tanto, la vida útil de la caché proporciona un beneficio de continuidad limitado para algunos remitentes, no permite que el certificado HTTPS caduque. Diferentes remitentes pueden ocupar legítimamente diferentes estados durante la misma interrupción. RFC 8461 sección 3.3
El ID de descubrimiento identifica la instancia de la política, no el número de serie del certificado. Si solo cambia el certificado y el cuerpo de la póliza sigue siendo idéntico, no asuma que se requiere una nueva identificación para que la renovación sea efectiva. Si la política también cambia, siga el orden de actualización del cuerpo antes del ID y tenga en cuenta las políticas almacenadas en caché. Mantenga la implementación de certificados y la revisión de políticas como cambios revisables por separado. RFC 8461 secciones 3.1 y 8.1
Conservar evidencia para la próxima renovación
Guarde el registro de implementación aprobado, los detalles públicos del certificado antes y después, los resultados de recuperación autenticados y cualquier información relevante. TLS-RPT observaciones. Una falla de la política Web PKI pertenece a la investigación del punto final de la política; una caducidad de certificado SMTP informada se refiere a la conexión de recepción. Compruebe qué categoría se informó realmente. RFC 8460 sección 4.3
El registro de erratas RFC 8461 actual incluye una corrección de capitalización informada sobre los certificados MTA de recepción vencidos; no permite certificados caducados. Aquí no se proporciona ninguna prueba original de renovación o alojamiento. La puerta operativa final sigue siendo una demostración con fecha y hora del servicio implementado, revisada por su propietario. Erratas RFC 8461