Para los servidores web expuestos públicamente es necesario disponer de un certificado digital emitido por una CA pública de confianza y ampliamente reconocida, no siendo válido hacer uso de certificados digitales autofirmados, ni de CAs privadas.
Evaluar y seleccionar el tipo adecuado de certificado digital (DV, OV o EV) que se desea obtener para cada servidor o aplicación web.
Evaluar y seleccionar la CA que emitirá el certificado empleando múltiples criterios objetivos, como su reputación, la funcionalidad que ofrece, su adopción de nuevos estándares, los mecanismos de revocación de certificados que implementa, etc.
Seleccionar el periodo de renovación del certificado digital y renovar los certificados periódicamente y siempre antes de su vencimiento.
Hacer uso de certificados digitales firmados mediante SHA-256 (o superior). En ningún caso hacer uso de firmas basadas en SHA-1 o MD5.
Identificar y configurar adecuadamente (en el orden correcto) la cadena completa de certificación (o de certificados) asociada al certificado digital, desde la CA raíz, pasando por todas las CAs intermedias, hasta el certificado final.
Seleccionar el tipo adecuado de certificado digital respecto al nombre de la entidad representada por éste, es decir, referencia directa o única, lista de nombres, certificado comodín, o multi-dominio.
El certificado digital debería incluir tanto el nombre del servidor web representado (“www”, o la lista de servidores web, o el comodín) como de su dominio.
El nombre de la entidad debe estar reflejado en el certificado digital a través del campo “SAN” (Subject Alternative Name, extensión “subjectAltName”) en lugar de mediante el “CN” (Common Name).
Asegurar la validez del certificado digital en todo momento, incluyendo el nombre de la entidad, periodo de validez, CA emisora del certificado, revocación del certificado y propósito.
Asociar el certificado digital a una CA que haga uso de Certificate Transparency (CT) y confirmar que el certificado ha sido registrado en los logs públicos de CT.
Monitorizar los logs o registros de CT para identificar la emisión de certificados digitales de dominios propios de manera ilegítima por parte de otras CAs, sin la autorización del propietario del dominio. Complementariamente, hacer uso de servicios de monitorización de CT para ser informado de cambios en los certificados digitales asociados a un dominio.
Proporcionar información de registro en CT (mediante SCT) en las respuestas HTTPS del servidor web hacia los clientes web mediante una extensión del certificado digital X.509v3, (o preferiblemente) mediante una extensión específica de TLS o empleando OCSP Stapling.
Se recomienda valorar la utilización de la cabecera HTTP “Expect-CT” para declarar la necesidad de usar certificados digitales reconocidos en CT. En su defecto, hacer uso de las capacidades de notificación de “Expect-CT” para identificar el uso de certificados digitales no válidos desde el punto de vista de CT.
Configurar en el servicio de resolución de nombres
DNS los registros CAA correspondientes a la lista de CAs asociadas a los certificados digitales del dominio.
Asociar el certificado digital a una CA que haga uso de CAA (Certification Authority Authorization).
Hacer uso de las capacidades de notificación de CAA para identificar errores o peticiones de certificados no válidas.
Hacer uso de HPKP (HTTP Public Key Pinning) para establecer los certificados digitales reconocidos asociados al entorno, servidor o aplicación web. En su defecto, hacer uso de las capacidades de notificación de HPKP para identificar el uso de certificados digitales válidos, pero no legítimos o autorizados, contra el entorno web.
En el caso de hacer uso de HPKP, se recomienda emplear un valor de “max-age” de 5184000 (60 días o 2 meses), empezar haciendo un uso limitado de la cabecera HPKP en un recurso concreto, e ir incrementando progresivamente el valor de “max-age”.
Si se está haciendo uso de la directiva “report-uri” de HPKP, se debe emplear una referencia web HTTPS asociada a un servidor web distinto al que ha enviado la cabecera HPKP.
HPKP debería de ser implementado para la totalidad del dominio mediante la directiva “includeSubDomains”.
HPKP debe de incluir, como mínimo, dos pines: uno principal, asociado a uno de los certificados digitales de la cadena de certificación actual, y uno de backup, que no debe de estar en la cadena de certificación actual.
Evaluar y seleccionar el certificado digital de la cadena de certificación actual que será utilizado para la generación de los pines de HPKP, pudiendo elegir un escenario más restrictivo (servidor web final), intermedio (CAs intermedias) o más permisivo (CA raíz).
Seleccionar la CA vinculada a los pines de backup de HPKP y proteger convenientemente la clave privada asociada a estos pines.