Una autoridad de certificación (CA), también llamada autoridad de certificados, es una entidad de confianza que valida las identidades de los activos en línea que son propiedad de las organizaciones, como sitios web o direcciones de correo electrónico, al emitir documentos electrónicos denominados certificados digitales. Las CA validan la titularidad del dominio y, en algunos casos, la legitimidad de la titularidad del sitio web y emiten certificados digitales en los que confían los navegadores web como Chrome, Safari y Firefox. Desempeñan un rol fundamental a la hora de mantener la seguridad en Internet al cifrar las comunicaciones en línea y reforzar la confianza.
Antes de profundizar en el tema de las CA, es importante comprender el funcionamiento básico de un certificado SSL/TLS y su rol a la hora de proteger las comunicaciones en línea.
Un certificado SSL/TLS es un archivo criptográfico instalado en su servidor web que ayuda a establecer una comunicación en línea segura y cifrada. Los certificados SSL/TLS sirven para dos propósitos principales:
Cuando se conecta a un sitio web a través de HTTPS, el intercambio de información se cifra y resulta indescifrable para los ciberdelincuentes que intentan interceptarla.
Los certificados SSL/TLS funcionan basándose en un marco de relaciones de confianza (normalmente denominado "cadena de confianza"), donde son firmados y emitidos por CA de confianza. Como se ha indicado anteriormente, la CA es responsable de validar la identidad del dominio y de emitir, conservar y revocar los certificados para el dominio en cuestión, con el fin de garantizar una plataforma segura para que los usuarios se conecten y compartan su información.
Puede ver los detalles del certificado SSL/TLS de cualquier sitio web que funcione con HTTPS y encontrará la siguiente información:
Clave pública: Detalles sobre la clave pública y el respectivo algoritmo criptográfico que se usaron para firmar el certificado.
Sujeto: Información sobre el dominio para el que se emitió el certificado o, para ciertos tipos de certificados, la legitimidad de la organización que opera el sitio web.
CA emisora: La firma de la autoridad emisora de confianza que reafirma la seguridad de cualquier información compartida con el sitio web.
Toda esta información se puede obtener haciendo clic en el candado de la barra de direcciones del sitio web que desee conocer.
Cuando un usuario se conecta a un sitio web a través de HTTPS, ambas partes que se comunican —el equipo cliente y el servidor— validan su identidad y se autentican mutuamente antes de establecer la conexión. Este proceso se denomina negociación TLS. Durante este proceso, se genera una clave de sesión, que proporciona un cifrado simétrico de la sesión concreta después de que ambas partes se hayan autenticado correctamente.
Esta es la secuencia de pasos que se producen en segundo plano cuando un usuario se conecta a un sitio web a través de HTTPS:
El navegador del equipo del usuario intenta establecer una conexión con el equipo servidor del sitio web protegido con TLS y le solicita que demuestre su identidad.
El servidor web recibe la solicitud y devuelve una copia de su certificado TLS junto con su clave pública.
El navegador recibe el certificado y comprueba su legitimidad comparándolo con una lista predefinida de CA de confianza. Si el navegador confía en el certificado, crea una clave simétrica denominada clave de sesión, cifra la clave utilizando la clave pública del servidor y la envía de vuelta al servidor.
El servidor web descifra el mensaje con su clave privada y envía una aceptación —que está cifrada con la clave de sesión— al navegador para iniciar la sesión.
El proceso de negociación TLS ha finalizado. Luego, el navegador y el servidor inician la sesión, en la que toda la información intercambiada se cifra utilizando la clave de sesión. Esto evita que cualquier intento de ataque man-in-the-middle porque la clave para descifrar la transferencia de datos reside únicamente en las partes implicadas.
La cadena de confianza del certificado es un concepto importante en la infraestructura de clave pública (PKI) que ayuda a trazar un certificado SSL/TLS hasta su certificado raíz, es decir, la CA emisora con la que se firmó. Entre un certificado instalado en un servidor web y su raíz, suele haber uno o varios certificados intermedios vinculados entre sí. Los navegadores necesitan información completa sobre la cadena de confianza para determinar si se puede confiar o no en el certificado de un sitio web, por lo que es importante que las organizaciones se aseguren de que la cadena de confianza está intacta en los certificados instalados en sus sitios web para cumplir los requisitos de los navegadores e infundir confianza entre los visitantes del sitio.
Hay tres componentes significativos en la cadena de confianza del certificado. Estos son:
El certificado raíz se encuentra en la posición más alta de la jerarquía de la cadena de confianza. Es un certificado autofirmado por una autoridad emisora y se adhiere al estándar de un certificado X.509. Un certificado raíz firmado por una CA pública es de confianza de forma predeterminada en los almacenes de confianza del navegador del cliente. Si la clave privada del certificado raíz se ve comprometida, todos los certificados firmados utilizando la raíz se verán afectados y deberán ser sustituidos. Por lo tanto, una autoridad de certificación raíz debe vigilar de cerca su clave privada y abstenerse de firmar directamente los certificados de entidad final.
Un certificado intermedio funciona como intermediario entre el certificado raíz y los certificados de servidor. Normalmente, hay al menos un certificado intermedio presente en la cadena de confianza. El objetivo principal de un certificado intermedio es mantener la clave privada raíz segura y desconectada, y evitar que firme directamente los certificados de servidor de las entidades finales expuestas a posibles riesgos cibernéticos. Mientras que los navegadores de los clientes confían de forma predeterminada en los certificados raíz, los certificados intermedios no siempre se envían junto con los sistemas operativos de los clientes, los almacenes de confianza de los navegadores u otras aplicaciones compatibles con los certificados.
Los certificados de servidor, o certificados de entidad final, se instalan en los servidores web y autentifican la identidad de sus hosts locales. Cuando se instalan en un sitio web, el protocolo de transferencia de hipertexto pasa de HTTP a HTTPS (donde S significa SSL), lo que indica que es un enlace de conexión cifrado entre el servidor y el navegador del cliente. Los certificados de servidor implementados en sitios web orientados al público suelen estar firmados y emitidos por CA de confianza. Si el certificado de servidor de un sitio web concreto no está emitido por una CA de confianza, los navegadores de los clientes no confían en el sitio web, lo que genera advertencias de seguridad que acaban afectando la credibilidad de la marca entre los posibles clientes.
Existen cinco grandes categorías de modelos de confianza dentro del ámbito de PKI. Estos son:
En este modelo, todos los certificados de usuario son emitidos directamente por la CA presente en la cadena. La cadena de confianza comienza con la CA y termina con el certificado de servidor sin que intervenga ningún certificado intermedio. Esta configuración es sencilla de implementar, pero si cambia la clave privada de la CA, deberá reconfigurar toda la arquitectura. Por esta razón, este modelo no es adecuado para grandes comunidades de usuarios.
El modelo jerárquico, también conocido como modelo de árbol, es el método frecuentemente adoptado para implementar la PKI. En esta configuración, la CA raíz, o el ancla de confianza, ocupa la posición más alta de la cadena de confianza y las relaciones de confianza son unidireccionales (de arriba a abajo). Este modelo admite una o varias CA intermedias y es escalable, y cada certificado de entidad final llega hasta una única CA, es decir, la CA raíz. Uno de los inconvenientes de este modelo es que, al tratarse de un único punto de confianza, si la clave privada de la CA raíz se ve comprometida, esto implica una reestructuración completa de la arquitectura de la PKI. Además, pasar de un modelo PKI existente con múltiples CA al modelo jerárquico es logísticamente difícil porque todas las entidades finales tienen que realinear sus puntos de confianza.
El modelo de confianza en malla también se denomina arquitectura de certificación cruzada, en la que el ancla de confianza de un servidor final es su CA local. Todas las CA funcionan de forma independiente y la relación de confianza es mutua, a diferencia del modelo jerárquico que funciona con un único punto de confianza. En este modelo, cada CA es autónoma, realiza una verificación cruzada de igual a igual con otras CA y la naturaleza de la confianza es bidireccional. La principal ventaja del modelo de malla es que es más fácil incorporar una nueva comunidad de usuarios porque no hay un único punto de confianza y, por tanto, no es necesario cambiar los puntos de confianza existentes para los nuevos usuarios. Sin embargo, este modelo incurre en elevados costos de mantenimiento y plantea problemas de escalabilidad.
Este modelo es similar al modelo de malla con relaciones de confianza bidireccionales, pero con una CA puente que actúa como punto central para todas las CA autónomas implicadas en la arquitectura. En este modelo, la cadena de confianza es menos compleja que en la arquitectura de malla, ya que se puede rastrear hasta una única CA puente. Un inconveniente de este modelo es que los certificados de usuario son complejos, ya que la CA puente se basa en la información de los certificados para establecer relaciones de confianza entre los distintos módulos de la PKI. Esto, a su vez, plantea retos técnicos relacionados con la distribución de certificados e información de estado de forma que resulten beneficiosos para los usuarios y las aplicaciones.
La naturaleza altamente dinámica de las redes de TI exige que las organizaciones adopten modelos de confianza que sean ágiles y escalables. Como su nombre indica, el modelo de confianza híbrido es una combinación de dos o más de las arquitecturas anteriores en función de los requisitos de las comunidades de usuarios implicadas. El siguiente diagrama muestra un modelo híbrido en el que la arquitectura jerárquica y de CA única se combinan para producir un nuevo marco de confianza.
Los certificados digitales no tienen por qué obtenerse necesariamente de CA públicas. Los usuarios pueden generar certificados autofirmados en sus propios host locales con sus propias claves privadas en lugar de solicitarlos a una CA pública o privada. Las organizaciones tienden a utilizar certificados autofirmados para aplicaciones, herramientas y procesos internos por comodidad. Sin embargo, utilizar certificados autofirmados —incluso para fines internos— supone enormes riesgos de seguridad. Estos son algunos de ellos:
Usar certificados autofirmados en sitios orientados al público también puede causar estragos en la credibilidad de la marca de las organizaciones debido a que aparecen advertencias de seguridad en los navegadores de los clientes. Las empresas rara vez utilizan certificados autofirmados en servidores públicos. Usar certificados autofirmados en sitios orientados al público también puede causar estragos en la credibilidad de la marca de las organizaciones debido a que aparecen advertencias de seguridad en los navegadores de los clientes. Las empresas rara vez utilizan certificados autofirmados en servidores públicos.
Una forma de deshacerse de los certificados autofirmados internos es establecer una CA interna (como la CA de Microsoft) y configurarla para que cree e implemente certificados para las entidades corporativas. Los procedimientos de validación, la longitud de las claves, los algoritmos de firma y los procesos de revocación se pueden personalizar en función de la política de seguridad de la organización.
Establecer algún tipo de confianza a nivel de CA resulta mucho más seguro que utilizar certificados autofirmados.
Los certificados firmados por CA, o certificados públicos, son certificados digitales firmados y emitidos por CA de confianza. Es muy recomendable que las empresas utilicen certificados firmados por CA para los sitios orientados al público, ya que serán verificados automáticamente y gozarán de la confianza de los sistemas operativos de los clientes. Esto proporciona una experiencia de navegación fluida a los clientes y mantiene alejadas las advertencias de seguridad del navegador que pueden afectar a la credibilidad de la marca. Para adquirir certificados firmados por una CA, las organizaciones deben elegir primero una CA de confianza y el tipo de certificado necesario, crear y enviar una solicitud de firma de certificado (CSR) a la CA y, a continuación, implementar el certificado adquirido en los servidores finales de destino dentro de la red.
A continuación se muestra una secuencia elaborada de los pasos que siguen los administradores de PKI para adquirir y distribuir certificados de una CA pública:
Seleccionar el tipo adecuado de socio de CA que cumpla las políticas de seguridad de la empresa es el primer paso para adquirir y gestionar certificados de CA públicas. Los puntos a tener en cuenta al evaluar las CA incluye:
Aunque todas las empresas de CA pasan por rigurosas auditorías para obtener la acreditación, no todas las CA son igual de seguras. Incluso las empresas de CA más reputadas han sido víctimas de brechas de seguridad en el pasado, por lo que las organizaciones deben estar al tanto de las noticias relacionadas con SSL/TLS cuando elijan suscribirse a un socio de CA.
Algunas empresas de CA cobran mucho (el precio puede llegar a $1.500 por certificado), mientras que otras ofrecen el mismo cifrado por una cantidad mucho menor. También existen CA de código abierto como Let's Encrypt y CAcert que ofrecen certificados X.509 gratis. Los administradores de PKI suelen buscar socios CA con los precios de certificados más bajos que cumplan los requisitos corporativos en términos de reputación de marca y facilidad de uso.
El servicio de atención al cliente es un factor importante a tener en cuenta a la hora de elegir una CA. La mayoría de las organizaciones no cuentan con un equipo interno dedicado a la PKI, por lo que tienen problemas frecuentes durante la implementación y las renovaciones. Elegir una CA que ofrezca asistencia para la implementación y una interfaz de gestión sencilla puede suponer un gran ahorro de tiempo para los equipos de TI.
El mundo de la seguridad en Internet cambia constantemente. Dado que se descubren nuevas vulnerabilidades cada día, es esencial que las organizaciones elijan un proveedor de certificados que priorice la adaptación a las últimas tendencias de seguridad SSL/TLS, como la transparencia de los certificados y la fijación de certificados, así como los algoritmos de firma más recientes, como SHA-2 y ECDSA.
El foro de navegadores/autoridades de certificación, también conocido como foro CA/B, es un consorcio voluntario de CA, proveedores de navegadores, sistemas operativos y otras aplicaciones habilitadas para PKI que promulga directrices industriales que controlan la emisión y gestión de certificados X.509 encadenados a un ancla de confianza. Cualquier decisión importante relativa a las normas y requisitos aceptados para los certificados se realiza mediante la aprobación de mociones en el foro CA/B, seguidas de un periodo de votación de una semana tras la aprobación unánime de todos los miembros del foro.
Tras elegir la CA, el siguiente paso es evaluar y encontrar qué tipo de certificado SSL/TLS se ajusta a sus necesidades. Los certificados de CA pública pueden clasificarse a grandes rasgos en tres categorías principales. Aunque el nivel de seguridad del cifrado sigue siendo el mismo para cada tipo de certificado, la diferencia radica en el proceso de validación e investigación previo a la concesión del certificado. Los tres tipos principales de certificados CA son:
La validación de dominio es la menos estricta. La CA simplemente valida la propiedad legal del dominio por parte de la entidad solicitante antes de emitir el certificado. No se comprueban los antecedentes de la organización. Este tipo de certificado es el más adecuado para las pequeñas empresas que necesitan un cifrado SSL de bajo costo sin tener que presentar documentos de la empresa.
Para este tipo de certificado, la CA verifica la propiedad legal del dominio por parte de la entidad solicitante y también examina la información organizacional hasta cierto punto, lo que proporciona una mayor visibilidad sobre la parte que procesa su información. Los navegadores web tienen una forma de diferenciar entre certificados SSL, DV y OV mostrando el nombre de la organización junto con la información del certificado, lo que aumenta la confianza asociada. Este tipo de certificado es adecuado para las organizaciones que recopilan información de identificación personal de sus clientes.
En este tipo de validación, la CA no sólo verifica la propiedad legal del dominio concreto, sino que lleva a cabo una rigurosa investigación de la organización. La validación extendida es la más larga y costosa, y la emisión de certificados se realiza siguiendo el estricto protocolo de las directrices para certificados EV SSL ratificadas formalmente por el foro CA/B. La CA que distribuye un certificado EV SSL también debe someterse a estrictas auditorías para adquirir los derechos de emisión. Este tipo de certificado es el más adecuado para grandes empresas, instituciones financieras y organismos de comercio electrónico que recopilan y procesan grandes volúmenes de información sensible.
Tras elegir su CA preferida y el tipo de certificado, el siguiente paso es generar una CSR y enviarla a la CA. La CSR es un archivo codificado que contiene la clave pública y algunos detalles sobre el certificado y la organización, y es el proceso estándar establecido para solicitar un certificado a una CA pública. En resumen, la CA utilizará los datos de la CSR para generar un certificado. La CSR se puede visualizar con un simple editor de texto y suele llevar la extensión de archivo PEM o CSR. Aquí hay un ejemplo de cómo es una CSR.
Una vez que la CA recibe una CSR, utiliza la clave pública adjunta para descifrar la firma y reunir la información especificada. A continuación, la CA verifica su identidad, el derecho al dominio especificado, y realiza una comprobación de los antecedentes de su organización (en función del tipo de certificado solicitado). A continuación, la CA genera el certificado X.509 a partir de su CSR, aplica un hash y lo cifra, y luego lo firma utilizando la clave privada correspondiente. Después, el certificado CA firmado se envía de vuelta a la organización. Lleva la firma de la CA y su clave pública, y suele tener la extensión de archivo CER. A continuación, el certificado obtenido se instala en los equipos de destino dentro de la red.
Una vez implementados los certificados en los servidores necesarios de la red, se debe monitorear constantemente su uso. Todos los tipos de certificados X.509 tienen un periodo de validez determinado, por lo que se deben renovar antes de la fecha de caducidad. Las renovaciones oportunas son importantes porque ayudan a mantenerse al día de las últimas normas de cifrado y mantienen la credibilidad de la marca.
Los certificados emitidos por CA se pueden clasificar en tres tipos dependiendo del grado de validación antes de concederlos. Son certificados validados por dominio, validados por organización y validados extendidos.
Un certificado digital contiene información relacionada con la organización para la que se ha emitido el certificado. Incluye detalles como el nombre de la organización, la fecha de emisión del certificado, el nombre del dominio, el número de contacto y la fecha de caducidad junto con la firma digital de la autoridad emisora.