Certificado de servidor

27 abril 2015
Usuarios
Josep Ma Solanes 0
|

¡Que cruz esto de los certificados! Pero no he podido evitar intentar explicar de manera sencilla porque necesitamos los certificados.

Esta entrada hace referencia al uso de certificados en la parte servidor, es decir, para proteger un servicio que queremos ofrecer. Decidle Web, correo electrónico, VPN, conexión Wi-Fi, etc…

El certificado al lado servidora sirve para proteger la COMUNICACIÓN, el transporte de los datos, no la AUTENTICACIÓN del equipo o usuario que se hace de otra manera.

¿Para que me sirve poner un certificado?

El certificado sirve para proteger la comunicación entre un cliente y el servidor, estableciendo un canal de comunicación seguro. Al estilo de las películas de espías, como si fuera el teléfono rojo. De esta manera se intenta evitar que alguien pueda estar mirando que se está enviando o hablando entre ellos. El uso de certificados en los servidores tiene que ser el habitual y exigible en todos los servicios seguros que hay en Internet o dentro de la empresa y, de los que como usuario, debéis asegurar que así sea cuando se introducen datos sensibles: cuentas de usuario y contraseñas, acceso al banco, tarjetas de crédito, contratos, correo electrónico, etc… En este aspecto, tenemos que estar atentos que no se intente sustituir el certificado del servidor por otro. Siguiendo el símil de los espías, equivaldría al agente secreto que secuestra al espía y se hace pasar por él para obtener la información deseada. El error que siempre he encontrado en estos casos, es que el comprador no tenga por lo menos una foto del espía para poder verificar su identidad a simple vista. Las películas son películas. En el entorno de certificados, el servidor (sería como el comprador o vendedor de la peli), casi nunca conoce al cliente (el espía o comprador del material). Por lo tanto, se debe idear una manera en que el cliente, automáticamente y de manera transparente, pueda pasar información secreta al servidor sin que nadie más se pueda poner de por medio. Esta manera es con la utilización de los certificados en los servidores.

¿Qué elementos intervienen?

Entidad Certificadora

En toda infraestructura de certificados, lo primero que necesito es alguien que genere y valide que los certificados que se utilizan son los correctos, que los ha generado quien dice que es y no cualquier otro. Esto se consigue con la ENTIDAD CERTIFICADORA. Esta puede ser comercial («pública») o propia. Pongo pública entre comillas porque la confianza con la entidad certificadora es siempre eso, una relación de confianza. Depende de cada uno que confíe en una entidad certificadora. Si no hay manera de que el cliente y el servidor hablen previamente para ponerse de acuerdo en la entidad certificadora a utilizar, lo suyo será que ambos confíen en un tercero que proporcione esta seguridad, equivaldría a un mediador que conoce todas las partes.

No existe una entidad certificadora «buena», todas son buenas y malas a la vez, es una cuestión de confianza.

En el caso de España, hay ciertas entidades certificadoras validadas por el estado (Fábrica de Moneda y Timbre, ID Cat, Camerfirma, etc…) para tramitaciones legales dentro del territorio (declaración de la renta, firma de documentos, facturación electrónica, etc…), pero que sean «legales» en España no quiere decir que lo sean en Francia. Cada uno barre para su casa y de momento no hay una entidad de administración pública que las pueda agrupar a todas. Si utilizáis los certificados de ID Cat o Camerfirma lo más normal es que aparezca el mensaje de no confianza en la entidad certificadora. Esto es así porque estos organismos no han añadido el certificado de su entidad a los navegadores por defecto. Por lo que se tiene que hacer manualmente como en cualquier otra entidad. Es una operación habitual.

Claus públiques de IDCat

Por lo tanto, lo primero que se debe hacer como cliente es confiar en la entidad certificadora que ha emitido los certificados que utilizan los servidores. Hay que añadir el certificado de la entidad emisora a la aplicación que se tenga que utilizar (ya sea el navegador, el lector PDF, el correo electrónico, etc…); como Entidad de certificación raíz de confianza. De esta manera, cuando un servicio presente un certificado emitido por la entidad certificadora correspondiente, la aplicación podrá comprobar que el certificado ha sido generado por esta entidad y no por otra. En caso que no confiemos en la entidad certificadora que genera los certificados, no se podrá hacer esta comprobación y en el navegador aparecerá el molesto mensaje, que la mayoría acepta sin leer, informando que no se puede comprobar la identidad del sitio. En otro tipo de aplicaciones (VPNs, Wi-Fi, etc…) lo más normal es que, al no poder comprobar la identidad del certificado, no se genere la comunicación.

Error de confiança en el certificat del servidor

Certificado de servidor

El otro elemento necesario es el certificado que se asigna al servicio del servidor. El que se instala en el servidor Web, VPN, Wi-Fi, etc… Este certificado contiene una clave pública (contraseña pública) y una clave privada (contraseña privada) y NO se debe distribuir NUNCA a los clientes, sólo debe instalarse en los servidores que proporcionen el servicio. Lo remarco porque es el error más común con el que me encuentro, que se instale o distribuya este certificado a los clientes. Una vez instalado el certificado en el servicio que se quiere proteger, a grandes rasgos, este es el funcionamiento que sigue:

  • El ususario accede al servicio mediante la aplicación correspondiente, por ejemplo, con un navegador en una web segura.
  • El servidor detecta la conexión a la web y presenta el certificado asociado, proporcionando la clave pública del certificado del servidor al cliente.
  • El navegador del cliente comprueba que el certificado que ha presentado el servidor es de confianza (pertenece a una entidad certificadora dada de alta en el navegador).
  • En caso afirmativo, cierra la conexión con el candado. En caso contrario, el navegador emite el mensaje de advertencia de que el sitio no es seguro.
  • El cliente se guarda la clave pública que utiliza para cifrar (proteger) todas las comunicaciones con el servidor.
  • A la vez, el servidor recibe las comunicaciones cifradas del cliente que descifra con su clave privada. Al no tener nadie más esta clave privada se asegura la confidencialidad.

Se acaba de establecer un canal de comunicación seguro con dos partes (emisor y receptor) cuando estas no se conocen. Pero en este punto no se comprueba la identificación de la persona que quiere acceder, el paso que corresponde a introducir el usuario, contraseña, token, tarjeta de crédito, etc… la responsabilidad del cual recae en el propio servicio. Lo único que se ha hecho ha sido proteger la comunicación porque cuando se introduzcan estos o otros datos queden al margen de miradas o oídos externos.

Conclusión

Para proteger una comunicación entre un servicio y múltiples clientes que no conozco, la manera que tengo para hacerlo es utilizar un certificado que controlo en la parte servidora. Que a la vez, los clientes que accedan al servicio tienen que confiar en la entidad certificadora que ha emitido este certificado. El certificado de la parte servidor NO lo distribuiré nunca a los clientes. En cambio, el certificado público de la entidad emisora me interesa que se distribuya como a más máquinas y aplicaciones mejor para que puedan utilizar mis servicios protegidos.

¿Te ha gustado el artículo? Lo puedes compartir en las redes sociales. También puedes dejar tu opinión, comentario o sugerencia. ¡Gracias!

Similar Posts by The Author: