Casos de uso de los certificados

Transport Layer Security (TLS)

¿Qué dos preguntas debe hacerse un cliente al recibir un certificado de un servidor?

1. ¿El certificado es válido y de confianza? El cliente tiene que verificar que el certificado lo ha emitido una autoridad de certificación (CA) de confianza y que no ha caducado ni ha sido revocado. Para ello comprueba el periodo de validez del certificado y se asegura de que está firmado por una CA en la que confía.
2. ¿El certificado se corresponde con la identidad del servidor? El cliente debe asegurarse de que los datos del certificado, como el Common Name (CN) o el Subject Alternative Name (SAN), coinciden con el nombre de dominio del servidor. Así se confirma que el certificado está realmente destinado al servidor al que el cliente intenta conectarse.

¿Cómo valida el cliente que un certificado es de confianza?

1. Comprobar la cadena de confianza del certificado: el cliente verifica la cadena de certificados, que incluye el certificado del servidor, los certificados intermedios y el certificado raíz. Cada certificado de la cadena debe estar firmado por la autoridad inmediatamente superior, hasta llegar a un certificado raíz de confianza.
2. Verificar el periodo de validez del certificado: el cliente comprueba el periodo de validez del certificado para asegurarse de que no ha caducado ni empieza a ser válido más adelante. Para ello revisa las fechas “Not Before” y “Not After” del certificado.
3. Comparar el certificado con la identidad del servidor: el cliente se asegura de que el Common Name (CN) o el Subject Alternative Name (SAN) del certificado coincide con el nombre de dominio del servidor. Eso confirma que el certificado está destinado al servidor al que se está conectando.
4. Comprobar la revocación: el cliente comprueba si el certificado ha sido revocado consultando la lista de revocación de certificados (CRL) o usando el Online Certificate Status Protocol (OCSP). Un certificado revocado deja de ser de confianza.
5. Verificar la firma digital: el cliente verifica la firma digital del certificado para asegurarse de que no se ha manipulado. Para ello comprueba la firma criptográfica con la clave pública de la CA emisora.

¿Cómo valida el cliente que el servidor es el verdadero propietario de un certificado?

1. Verificación de la cadena de certificados: el cliente verifica la cadena de certificados y comprueba que cada certificado de la cadena está firmado por una autoridad de certificación (CA) de confianza. Esa cadena empieza en el certificado del servidor y termina en un certificado raíz de confianza.
2. Coincidencia del nombre de dominio: el cliente comprueba que el Common Name (CN) o el Subject Alternative Name (SAN) del certificado coincide con el nombre de dominio del servidor. Así se garantiza que el certificado está destinado al servidor al que se está conectando.
3. Verificación de la firma digital: el cliente verifica la firma digital del certificado con la clave pública de la CA emisora. Esto garantiza que el certificado no se ha manipulado y que lo ha emitido realmente una CA de confianza.
4. Periodo de validez del certificado: el cliente comprueba el periodo de validez del certificado para asegurarse de que es válido en ese momento y de que no ha caducado.
5. Comprobación del estado de revocación: el cliente comprueba si el certificado ha sido revocado consultando la lista de revocación de certificados (CRL) o usando el Online Certificate Status Protocol (OCSP). Un certificado revocado deja de ser de confianza.

¿Por qué importa la propiedad si ya se ha comprobado que el certificado es de confianza?

Validez y confianza del certificado: este paso garantiza que el certificado lo ha emitido una autoridad de certificación (CA) de confianza, que está dentro de su periodo de validez y que no ha sido revocado. Confirma que el certificado es legítimo y que no se ha manipulado.

Verificación de la identidad del servidor: aunque un certificado sea válido y de confianza, también hay que confirmar que pertenece al servidor al que uno se conecta. Para ello se comprueba que el Common Name (CN) o el Subject Alternative Name (SAN) del certificado coincide con el nombre de dominio del servidor. Este paso garantiza que el certificado está destinado a ese servidor concreto y evita los ataques de intermediario, en los que un atacante podría presentar un certificado válido de otro dominio.

¿Cuáles son los dos métodos con los que el cliente responde a esta pregunta? ¿Qué dos resultados se producen con cada uno?

1. Verificación mediante el sistema de nombres de dominio (DNS): el cliente comprueba que el Common Name (CN) o el Subject Alternative Name (SAN) del certificado coincide con el nombre de dominio del servidor.
   Resultado:
   • Coincidencia: si los nombres coinciden, el cliente puede continuar con la conexión, con la seguridad de que el certificado está destinado a ese servidor.
   • Discrepancia: si los nombres no coinciden, lo más probable es que el cliente interrumpa la conexión o muestre una advertencia que señale un posible riesgo de seguridad.
2. Verificación mediante la infraestructura de clave pública (PKI): el cliente verifica la firma digital del certificado con la clave pública de la autoridad de certificación (CA) emisora.
   Resultado:
   • Firma válida: si la firma es válida, queda confirmado que el certificado no se ha manipulado y que lo ha emitido una CA de confianza.
   • Firma no válida: si la firma no es válida, el cliente interrumpirá la conexión o mostrará una advertencia para indicar que el certificado puede estar comprometido o ser fraudulento.

¿Qué determina qué método se utiliza?

Verificación mediante el sistema de nombres de dominio (DNS):

• Uso: este método se aplica siempre como parte del handshake TLS. El cliente compara el Common Name (CN) o el Subject Alternative Name (SAN) del certificado con el nombre de dominio del servidor para comprobar que coinciden.
• Factores determinantes: forma parte del protocolo TLS estándar y el cliente lo ejecuta de forma automática al establecer una conexión segura.

Verificación mediante la infraestructura de clave pública (PKI):

• Uso: este método también se aplica siempre durante el handshake TLS. El cliente verifica la firma digital del certificado con la clave pública de la autoridad de certificación (CA) emisora.
• Factores determinantes: es otra parte estándar del protocolo TLS. El cliente realiza esta comprobación automáticamente para asegurarse de que el certificado es válido y de que no se ha manipulado.

¿Qué certificados debe enviar el servidor al cliente?

Durante el handshake TLS, el servidor debe enviar al cliente los siguientes certificados:

• Certificado de entidad final: es el certificado propio del servidor, con el que demuestra su identidad ante el cliente.
• Certificados intermedios: estos certificados enlazan el certificado de entidad final con el certificado raíz de confianza. Ayudan a establecer una cadena de confianza que va desde el certificado del servidor hasta un certificado raíz de confianza.

¿Qué son los certificados de validación de dominio y de validación extendida?

Los certificados de validación de dominio (DV) son un tipo de certificado TLS en el que la autoridad de certificación (CA) verifica que el solicitante controla el dominio. Normalmente se hace de estas formas:

• Respondiendo a un correo enviado al contacto administrativo del dominio.
• Añadiendo un registro TXT en el DNS.
• Subiendo un archivo al servidor web.

Características principales:

• Emisión rápida: se pueden emitir con rapidez, a menudo en cuestión de minutos, porque requieren una validación mínima.
• Seguridad básica: proporcionan cifrado y una garantía básica de que el dominio está bajo el control de quien solicita el certificado.
• Buena relación coste-beneficio: suelen ser más baratos o incluso gratuitos, lo que los hace accesibles para sitios web pequeños y proyectos personales.

Los certificados de validación extendida (EV) son un certificado TLS de nivel superior que exige un proceso de validación más riguroso. La CA verifica la existencia legal, física y operativa de la entidad que solicita el certificado. Esto incluye:

• Confirmar la identidad y la situación legal de la entidad.
• Verificar su presencia física y operativa.
• Asegurar que la entidad tiene derechos exclusivos de uso del dominio.

Características principales:

• Alto nivel de garantía: ofrece a los usuarios el máximo nivel de confianza y garantía, porque implica una comprobación exhaustiva.
• Indicadores visibles: en algunos navegadores, los certificados EV mostraban el nombre de la organización en la barra de direcciones, aunque hoy es menos habitual.
• Mayor confianza: idóneos para sitios web que manejan información sensible, como los de entidades financieras y de comercio electrónico.

¿Cuáles son más seguros?

Por lo general, los certificados de validación extendida (EV) se consideran más seguros que los de validación de dominio (DV), debido al riguroso proceso de validación al que se someten. Esta es la comparación:

Certificados de validación de dominio (DV)

• Nivel de validación: solo verifica el control sobre el dominio.
• Seguridad: proporciona cifrado y garantías básicas.
• Caso de uso: adecuados para sitios web personales, blogs y pequeñas empresas.

Certificados de validación extendida (EV)

• Nivel de validación: verifica la existencia legal, física y operativa de la entidad.
• Seguridad: ofrece un mayor nivel de confianza y garantía gracias a la comprobación exhaustiva.
• Caso de uso: idóneos para entidades financieras, sitios de comercio electrónico y cualquier web que maneje información sensible.

Por qué los certificados EV son más seguros:

• Comprobación exhaustiva: los certificados EV exigen una validación extensa, lo que dificulta que entidades maliciosas los obtengan.
• Indicadores de confianza: aunque hoy es menos habitual, los certificados EV mostraban el nombre de la organización en la barra de direcciones del navegador y ofrecían así una garantía visible a los usuarios.
• Mayor garantía: el proceso de verificación detallado confirma que la entidad que hay detrás del certificado es legítima, lo que reduce el riesgo de phishing y de otros ataques.

Cuál es el proceso de revocación con OCSP stapling

El OCSP stapling mejora el proceso OCSP estándar porque reduce la latencia y protege mejor la privacidad. Así es como funciona:

1. El servidor solicita una respuesta OCSP: el servidor web consulta periódicamente el estado de revocación de su certificado al respondedor OCSP (un servidor que mantiene la autoridad de certificación, o CA). Esa consulta se hace en segundo plano y no en cada conexión de un cliente.
2. El respondedor OCSP devuelve una respuesta: el respondedor OCSP envía una respuesta OCSP firmada y con marca de tiempo que indica el estado del certificado (por ejemplo, “good”, “revoked” o “unknown”). El servidor guarda esa respuesta en caché.
3. Handshake TLS con la respuesta adjunta: cuando un cliente (por ejemplo, un navegador web) inicia una conexión con el servidor, el servidor incluye la respuesta OCSP en caché dentro del handshake TLS. Esto es lo que se conoce como “stapling” de la respuesta en el handshake.
4. El cliente verifica la respuesta OCSP: el cliente verifica la respuesta OCSP adjunta. Como la respuesta está firmada por la CA, el cliente puede fiarse de su validez. Si la respuesta indica que el certificado está revocado, el cliente no establecerá una conexión segura.
5. Actualizaciones periódicas: el servidor sigue actualizando periódicamente la respuesta OCSP en caché para disponer siempre de un estado actual que ofrecer durante el handshake TLS.

Este proceso reduce la necesidad de que los clientes hagan consultas OCSP por separado, lo que mejora el rendimiento y la privacidad.