GlobalSign Blog

Revocación de certificados: Entendiendo la comprobación de Revocación CRL, OCSP, y OCSP-Stapled

Revocación de certificados: Entendiendo la comprobación de Revocación CRL, OCSP, y OCSP-Stapled

Las comprobaciones de revocación se realizan para verificar la validez de los certificados digitales. Estas comprobaciones se realizan al conectarse a un sitio web seguro, validar una firma digital o iniciar un ejecutable firmado. Un certificado puede ser revocado si la clave privada del certificado ha sido comprometida. Situaciones como ésta pueden dar lugar a la suplantación de la identidad de una entidad o quizá a la distribución de código malicioso. 

Para entender mejor los certificados digitales y la comprobación de revocación, podemos compararlos con los certificados de seguridad e higiene en los restaurantes. Un restaurante con un certificado significa que el establecimiento ha sido revisado y que se encuentra en buen estado. Al igual que un certificado TLS, el certificado de salud y seguridad tiene un periodo de validez. Supongamos que el certificado de salud y seguridad tiene una validez de un año, ¿qué ocurre si se produce una infracción del código a los 6 meses del periodo de validez del certificado? Las fechas de inicio y fin seguirán implicando que el restaurante está en regla. Aquí es donde entran en juego los controles de revocación.

Cuando te conectas a un sitio web a través de tu navegador, el servidor web te devuelve su certificado TLS. Antes de que se complete la conexión, se realizan una serie de comprobaciones de validación, incluyendo comprobaciones de revocación. Existen varios métodos diferentes para realizar comprobaciones de revocación; el método utilizado puede depender de la configuración de tu navegador, sistema y/o servidor. Esta cohesión de controles y equilibrios existe para gestionar los riesgos para los usuarios y proteger las transacciones, comunicaciones y activos digitales.

Listas de revocación de certificados (CRL)

Las listas de revocación de certificados (CRL) son básicamente archivos de texto en los que se enumeran los números de serie de los certificados revocados. Si un cliente se conecta a www.ejemplo.com y el navegador está configurado para comprobar las CRL, obtendrá la URL de la lista de revocación de certificados del campo Punto de distribución de CRL del certificado TLS. Con esto, el navegador descarga toda la lista de revocación y buscará en ella el número de serie del certificado en cuestión. Si se encuentra en la lista, el certificado queda revocado. Este proceso se ejecuta cada vez que un nuevo visitante se conecta al sitio.

En el ejemplo del restaurante, sería como visitar un restaurante y mirar el certificado en la pared, tomando nota del número de serie del certificado y de la ubicación de la oficina que realizó la certificación. Para ver si el restaurante sigue en regla, se envía a alguien del grupo a la oficina de la Junta de Salud y Seguridad, que facilitará un inventario de los números de serie de los restaurantes con mala puntuación. Si está en el libro, no se debe comer allí. 
Sin embargo, este inventario no puede compartirse, y cada cliente debe repetir este proceso, recuperar su propia copia y realizar la búsqueda por sí mismo. Lo único que puede agilizar este proceso es que decidas comer allí al día siguiente y supongas que siguen en regla porque acabas de comprobarlo el día anterior.

En la práctica, el caché de revocación de certificados de tu sistema operativo y navegador dura, por término medio, unos 7 días. Cuando visitas un sitio que hace referencia a la misma CRL, puedes comprobarla localmente en lugar de volver a descargar toda la lista. Cuando se accede a un sitio que utiliza una CRL diferente o cuando caduca tu copia local, se descarga una copia nueva.

 Este sistema no es escalable y las CRL muy grandes pueden afectar al rendimiento.

Protocolo de estado de certificados en línea (OCSP)

El Protocolo de Estado de Certificados en Línea (OCSP) se desarrolló como sustituto de las Listas de Revocación de Certificados, aunque ambos siguen utilizándose en la actualidad. Al igual que ocurre con las CRL, existe una dirección para el respondedor OCSP incrustada en tu certificado, esta vez en el campo Acceso a Información de Autoridad (AIA). Los navegadores web y los sistemas operativos pueden utilizar esta dirección para consultar al respondedor OCSP y averiguar el estado de un certificado. 

Esto resuelve el problema de escalabilidad de las CRL, ya que no es necesario descargar toda la lista. En su lugar, se puede consultar un servidor como si fuera una base de datos para obtener una respuesta rápida. 

Volviendo al ejemplo del restaurante, sería como visitar un restaurante y anotar el número de serie del certificado en la pared, así como el número de teléfono de la oficina de certificación. Se llama a la oficina de certificación y se lee el número de serie del certificado. La oficina de certificación te dirá si el certificado en cuestión está en la lista o no. 
De nuevo, si visitas este restaurante con frecuencia, puede que no lo compruebes cada vez. Las respuestas OCSP, al igual que las CRL, también son almacenadas en caché por navegadores y sistemas operativos para su rápida recuperación posterior. Las copias locales también tienen una validez de unos 7 días. 

OCSP Stapling

El OCSP Stapling se basa en OCSP para aumentar aún más el rendimiento. Si tienes configurado el OCSP Stapling, tu servidor contactará periódicamente con el respondedor OCSP para recuperar una respuesta firmada y con marca de tiempo que tú mismo puedes alojar. Esta respuesta se «grapa» y se envía a los clientes conectados. Este método elimina la necesidad de que los clientes envíen una solicitud independiente a un servidor de terceros.
En el ejemplo del restaurante, sería como si el establecimiento llamara a la oficina de certificación cada pocos días para solicitar un sello oficial que demuestre que sigue en regla. El sello oficial estaría fechado y sólo sería válido durante un día más o menos.  Al entrar en el restaurante, los visitantes verían el certificado en la pared y un sello auténtico con una fecha reciente que demuestra que sigue siendo válido.

Controles y equilibrios

En última instancia, estos procesos existen para garantizar una comunidad digital de confianza y proporcionar fiabilidad a los certificados, sus clientes y sus CA emisoras. Sin este paso crucial en la creación de un espacio digital seguro, las jerarquías de confianza que se establecen como parte de la Ubicuidad Raíz en el espacio digital carecerían de sentido. Este sistema existe para crear controles y equilibrios dentro de las comunicaciones digitales y proporcionar una base de confianza entre las CA, los navegadores y las organizaciones.

Habla con nuestros expertos y crea una mayor confianza dentro de tu organización

Share this Post

Últimos blogs