Cómo afecta la RGPD a los certificados SSL

Durante estos días de tormenta de la RGPD (GDPR por sus siglas en inglés) habrás recibido decenas de correos pidiéndote una aceptación expresa para poder seguir enviándote newsletter o para comunicarte los cambios y adaptaciones de sus políticas de privacidad y protección de datos. Puede, tal vez, que hayas recibido alguna comunicación relacionada con tus certificados de seguridad.

Qué tiene que ver la RGPD con los certificados

Para obtener un certificados de tipo DV, Domain validation, (ver los distintos tipos de certificados) las entidades certificadoras pueden realizar la validación del dominio de 3 formas diferentes:

  • Validación por _email
  • Validación por DNS
  • Validación por archivo

Para la validación por DNS y por archivo, solo hay que tener acceso a la gestión DNS de tus dominios o a su sistema de archivo. Se generará una «clave» única que debe indicarse o en una entrada DNS o en un archivo localizado en una ruta concreta (<DOCUMENT_ROOT>/.well-known/pki-validation/).

Para la validación por email, la entidad certificadora (Comodo, Digicert…) enviará un correo a la dirección del titular del dominio o a una dirección de email preestablecida (admin@<DOMINIO>). Y aquí es donde la matan. Hasta ahora, hasta el 25 de mayo de 2018, Digicert podía obtener esta dirección del titular utilizando el WHOIS público, donde se mostraba información técnica del dominio así como los datos del titular del mismo. Como estos datos son considerados, con razón, datos personales, ya no se muestran de forma pública y ya no son accesibles por terceros.

Email vs DNS vs Fichero

Aunque la validación por email no es la validación más extendida para estos certificados y, desde luego, no es la más cómoda ni inmediata, es de las primeras que se implantó y puede que tu proveedor la utilice. En este caso, procura tener siempre activo (como buzón, como redirección…) una cuenta de correo admin@<DOMINIO> … y suerte.

Tipos de certificados de seguridad SSL

Si alguna vez te has enfrentado a la necesidad de contratar un SSL, supongo que te habrá sorprendido la disparidad de precios y te te habrás preguntado el por qué.

Lo primero a considerar es qué es lo que valida cada tipo de certificado. Un notario solo da fe de lo que está escrito, no de que lo que esté escrito sea verdad, con los certificados pasa algo similar. La entidad certificadora (CA), comprobará la validez de la información para crear el certificado según lo que se le pida.

Podemos distinguir los siguientes tipos de certificados en base a lo que validan, a lo que han comprobado que es cierto:

  1. Domain Validated (DV). El dominio pertenece al titular.
  2. Organization Validated (OV). La organización indicada posee el dominio.
  3. Extended Validated (EV). Comprobaciones adicionales y exhaustivas sobre la organización que solicita el certificado para el dominio.

Domain Validated (DV)

Comprueba que el dominio es un dominio válido y el propietario puede confirmar que, efectivamente es el propietario del dominio.

Esta validación la realiza el CA intercambiando mails con el titular del dominio, por ejemplo o, tal y como hará Let’s Encript, mediante comprobaciones de un agente en el servidor web para asegurarse que tiene acceso al dominio para el que se solicita el SSL.

Los certificados DV verifican el consentimiento del dueño de un dominio pero no verifican quién es el dueño del dominio en realidad.

Organization Validated (OV)

En este caso se valida el dominio y la organización que lo solicita y para ello hacen falta comprobaciones adicionales por parte del CA.

En estos casos se incluye en el certificado generado información sobre el sitio web y sobre la propia organización.

Extended Validated (EV)

Proporcionan el máximo nivel de confianza.

En este caso, el CA debe asegurarse para conceder el certificado de que diversos datos del dominio y de la organización. El CA se pondrá en contacto con la organización, normalmente por vía telefónica y le solicitará la documentación necesaria para conceder el certificado según la guía para certificados EV de CA/Browser Forum.

Certificado EV
Certificado EV en Mozilla Firefox

Referencias

SSL para dummies: gestión de certificados y PKI

A mediados de 2014 Google indicó que iba a considerar los certificados SSL (Secure Sockets Layer) como un elemento relevante en su algoritmo de posicionamiento (artículo en Google Webmasters Central (EN)).

A mediados de 2015, la fundación Mozilla junto con otros partners (EFF, Akamai, Cisco…) tiene previsto ofrecer certificados SSL “autoinstalables” de forma gratuita a través de su entidad de certificación (CA), Let’s Encrypt.

Y es que la cantidad de sitios web con certificados SSL no ha hecho más que crecer.

Imagen encuesta SSL Netcraft
Imagen encuesta SSL Netcraft

Aun así, el mercado de los SSL está en mano de unos pocos proveedores: Symantec, GoDaddy y Comodo tienen el 75% del mercado de SSL.

De forma resumida, un certificado SSL nos permite establecer una comunicación segura entre nuestro navegador y la página web de destino, gracias a que hay un tercero, la autoridad de certificación (CA) que es la que asegura que el destino al que navegamos es quien dice ser.

Para entender bien como funciona, no es necesario, pero sí interesante, conocer términos como cifrado asimétrico, PKI (Public Key Infraestructure) o la ya mencionada CA (Certificate Authority).

Como funciona la infraestructura de clave pública (PKI)

El cifrado asimétrico se basa en el intercambio de claves públicas para cifrar el contenido que solo el poseedor de la clave privada puede descifrar o para ser capaces de identificar al emisor.

El emisor cifra la información usando su clave privada y envía la clave pública al receptor. Con la clave pública, el receptor cifra el mensaje que solo la clave privada puede descifrar con lo que la comunicación del mensaje es segura.

Esquema de cifrado asimétrico
Cifrado asimétrico (por RealTimeLogic)

Este sistema también se utiliza para la firma de mensajes.

Igual que antes, solo el emisor posee la clave privada con la que se cifra el mensaje. El emisor proporciona al receptor la clave pública y con ella puede descifrar el mensaje. Como solo el emisor puede cifrar los mensajes de esa clave pública, nos sirve para identificar al emisor, pero no para mantener seguro el mensaje ya que se puede descifrar usando la clave pública.

Firma asimétrica
Firma asimétrica

Firma digital de mensajesEl problema de estas comunicaciones es que aunque identifiquemos al emisor, ¿cómo podemos confiar en él?

TLS/SSL resuelven este problema utilizando un tercero de confianza. El protocolo TLS/SSL utiliza una clave simétrica, y se utiliza el cifrado asimétrico para enviar una firma cifrada con la clave privada del emisor junto con la clave pública necesaria.

Los certificados y la PKI

Componentes de un certificadoDe cara a establecer una relación de confianza, hay unas autoridades de certificación (CA) que son las que nos aseguran que el receptor es quien dice ser. Para que el emisor confíe en el receptor, este debe tener firmado su certificado público por una CA de confianza.

Los certificados de los CA, con sus claves públicas, están almacenadas por defecto en los navegadores.

Durante la comunicación navegador-servidor, lo que se produce es:

  1. El navegador solicita identificar al servidor
  2. El servidor, envía su certificado público
  3. El navegador comprueba la validez del certificado
  4. El navegador comprueba ahora la validez del CA, del tercero de confianza, en su lista de CA
  5. Si el certificado público es correcto, y el CA que lo ha firmado es de confianza, el navegador debe comprobar que el nombre del servidor (el dominio) del certificado es es el mismo con el que se está comunicando
  6. Si es así, el navegador puede confiar en que se está comunicando con un servidor concreto de forma segura
Esquema de validación de certificados
Esquema de validación de certificados

Referencias