¿Qué es un certificado « SSL »?

Cada vez que introduces una contraseña, envías un formulario o realizas un pago con tarjeta de crédito, confías en que la conexión entre tu navegador y el sitio web es privada. Un certificado SSL es lo que hace posible esa confianza. Se trata de una de las tecnologías de seguridad más extendidas en Internet, pero a menudo se malinterpreta, en parte porque el sector sigue denominándola «SSL», a pesar de que el protocolo subyacente cambió hace años.

¿Qué es un certificado « SSL »?

Un certificado « SSL » es una credencial digital que vincula la identidad de un sitio web a una clave pública. El cifrado en sí lo lleva a cabo el protocolo TLS , que utiliza esa clave pública durante el proceso de establecimiento de la conexión para autenticar el servidor y establecer las claves de sesión. La función del certificado es más limitada, pero igual de importante: proporciona al cliente una razón para creer que la clave pertenece al sitio que cree estar visitando, y no a un atacante que se interpone en la conexión. Fomenta la confianza.

El término «SSL» es, en cierto modo, un vestigio histórico. Como se ha mencionado anteriormente, el protocolo asociado es TLS. « SSL » son las siglas de Secure Sockets Layer, el protocolo criptográfico original para autenticar y cifrar las comunicaciones a través de una red. Ese protocolo fue sustituido hace algún tiempo por su sucesor, más avanzado y seguro: TLS (Transport Layer Security). Aun así, «certificadoSSL » sigue siendo la expresión habitual en el sector, y la mayoría de la gente sigue diciendo « SSL » cuando, técnicamente, se refiere a « TLS ». A lo largo de esta guía, «certificadoSSL » o «SSL/TLS» se refiere a los certificados que protegen las conexiones actuales de TLS .

Para las organizaciones, un certificado SSL/TLS es mucho más que una herramienta de cifrado. Garantiza la integridad de los datos, permite la autenticación y protege las transacciones web, lo que lo convierte en una base fundamental de la confianza digital. Es lo que permite a los usuarios, socios y sistemas interactuar de forma segura a través de Internet.

También conviene aclarar un punto que suele generar confusión: todos los certificados de SSL/TLS siguen elestándar de certificados X.509, el formato que define cómo se estructuran los campos y la información de identidad del certificado. X.509 es la especificación más amplia, y SSL/TLS es solo uno de los muchos lugares en los que aparece. En otras palabras, todos los certificados SSL son certificados X.509, pero los certificados X.509 también se utilizan en la firma de correos electrónicos, la firma de código, las VPN, la identidad de dispositivos, etc.

Una breve historia de SSL y TLS

SSL Fue desarrollado por Netscape en la década de los 90 para cifrar y proteger las comunicaciones a través de Internet. La versión 1.0 de SSL nunca llegó a lanzarse debido a fallos de seguridad; la versión 2.0 de SSL le siguió en 1995 con importantes deficiencias, y la versión 3.0 de SSL , lanzada en 1996, aportó las mejoras fundamentales que marcaron el rumbo de las comunicaciones seguras en la web. En 2015, SSL v3.0 y las versiones anteriores habían quedado obsoletas, y en 2020 SSL se retiró por completo.

Mientras Netscape perfeccionaba el protocolo « SSL », el Grupo de Trabajo de Ingeniería de Internet (IETF) desarrolló el protocolo « TLS » como su sucesor. El protocolo « TLS » es, en esencia, una versión más reciente y segura del « SSL »: la versión 1.0 del « TLS » se lanzó en 1999 (basada en la versión 3.0 del « SSL »), seguida de la versión 1.1 del « TLS » en 2006 y de la versión 1.2 del « TLS », que ha estado en uso durante mucho tiempo, en 2008. El nombre «SSL» simplemente se quedó en el uso cotidiano, por lo que la gente sigue diciendo «certificadoSSL » cuando, en realidad, la conexión se realiza a través de TLS.

El estándar actual es el « TLS » 1.3, finalizado en 2018 y que actualmente protege la mayoría de las conexiones modernas. Ahora es más rápido y seguro que nunca. Para una comparación más detallada de ambos protocolos, consulta nuestros artículos complementarios en SSL y TLS.

Cómo funcionan los certificados « SSL » / «TLS »

Un certificado SSL/TLS protege la comunicación combinando dos tipos de criptografía y dos protocolos distintos. Comprender ambos es la clave para entender por qué esta tecnología es tan eficaz.

En términos generales, el protocolo de seguridad de la capa de transporte ( TLS ) establece una conexión segura en la capa de transporte entre dos puntos finales: un servidor y un cliente. Esa conexión suele establecerse entre el servidor de un sitio web y un navegador, o entre un servidor de correo y una aplicación de correo electrónico como Outlook. Para que funcione, el protocolo de seguridad de la capa de transporte ( TLS ) se basa en dos protocolos independientes:

• El protocolo de establecimiento de conexiónautentica al servidor (y, opcionalmente, al cliente), negocia qué métodos criptográficos se van a utilizar y genera una clave compartida.
• El protocolo de registroaísla cada conexión y utiliza esa clave compartida para proteger la comunicación durante el resto de la sesión.

El apretón de manos: donde se establece la confianza

El protocolo de enlace de seguridad ( TLS ) es un proceso criptográfico asimétrico que establece un canal seguro entre el servidor y el cliente. Todas las conexiones HTTPS comienzan con este protocolo. Durante el protocolo de enlace, el servidor posee una clave privada, mientras que el cliente recibe la clave pública correspondiente incluida en el certificado SSL/TLS , que luego utiliza para autenticar al servidor y confirmar su identidad. Además de que el cliente pueda autenticar al servidor, durante el protocolo de enlace también se establecen claves de sesión, que se utilizan para cifrar la comunicación a partir de ese momento.

Un establecimiento de conexión correcto se produce de forma instantánea y automática en segundo plano, sin alterar la experiencia del usuario. Por el contrario, un establecimiento de conexión fallido interrumpe la conexión y suele mostrar un mensaje de advertencia en el navegador.

Cuando el protocolo de establecimiento de conexión se realiza con éxito, ofrece tres ventajas en materia de seguridad:

• Autenticación:la identidad del servidor se verifica mientras la conexión sea válida.
• Confidencialidad:los datos están cifrados y solo son visibles para el servidor y el cliente.
• Integridad:las firmas digitales confirman que los datos no han sido alterados durante la transmisión.

Una vez que el protocolo de establecimiento de conexión establece una clave de sesión compartida, la criptografía asimétrica ha cumplido su función. Es entonces cuando el protocolo de transmisión toma el relevo, utilizando un cifrado simétrico más rápido para proteger el flujo de datos durante el resto de la sesión.

El certificado en sí contiene los datos de identificación que necesita un navegador para confirmar tu identidad, junto con la clave pública, la fecha de caducidad y otra información importante. Si quieres examinar estos componentes en la práctica, nuestra guía sobrecómo comprobar un certificado SSL te explica qué significa cada parte y cómo visualizarlas en tu navegador.

Infraestructura de clave pública y SSL

SSL/ Los certificadosTLS no funcionan de forma aislada. Forman parte de un marco más amplio denominado «infraestructura de clave pública» (PKI), que gestiona la seguridad mediante el cifrado y regula los certificados digitales a lo largo de todo su ciclo de vida. Cuando recibes un certificado SSL/TLS de una autoridad de certificación (CA), lo instalas en tu servidor, normalmente junto con un certificado intermedio que vincula tu certificado a la raíz de confianza de la autoridad. Todos estos son elementos y procedimientos de la PKI.

La forma más clara de imaginar la PKI es como una especie de Departamento de Tráfico digital. El Departamento de Tráfico verifica tu identidad antes de expedir un permiso de conducir, y el permiso que te entrega es algo más que un simple documento con tu nombre. Incluye tu fotografía, que es lo que lo hace útil: cualquiera puede comprobar que la persona que presenta el permiso es la misma a la que se le expidió.

Un certificado « SSL » / «TLS » funciona de manera similar. Una autoridad de certificación verifica la identidad de un sitio web y emite un certificado que contiene la clave pública del sitio, el equivalente a la foto en el certificado. Cualquiera puede comprobar que el servidor que presenta el certificado posee realmente la clave privada correspondiente. Y, al igual que un carné de conducir, un certificado indica el nombre de su titular, incluye una fecha de caducidad y puede revocarse antes de esa fecha si surge algún problema.

La cadena de confianza

Para que un certificado de SSL/TLS sea considerado fiable, debe remontarse a una CA raíz de confianza. Este vínculo se denomina «cadena de confianza». En el núcleo de toda PKI se encuentra la CA raíz, la fuente de confianza que garantiza la integridad de todo el sistema. Cuando una CA raíz firma un certificado, da inicio a la cadena. Si esa CA raíz goza de confianza pública, cualquier certificado válido vinculado a ella será considerado automáticamente fiable por los principales navegadores y sistemas operativos.

Los navegadores verifican esta cadena automáticamente. Tu navegador ya conoce las claves públicas de varias CA de confianza. Cuando recibe el certificado de un sitio web, utiliza esas claves para comprobar la firma del certificado y, a continuación, repite el proceso con cada certificado de la cadena hasta llegar a una CA raíz que reconozca. Esto es exactamente lo que ocurre detrás del icono del candado de la barra de direcciones: una verificación rápida y recursiva de que el certificado en el que confías procede de una fuente fiable. Para conocer con más detallecómo funcionan las cadenas de confianza y las autoridades de certificacióna nivel de especificación, consulta nuestra guía sobre X.509.

Tipos de certificados de « SSL »

Uno de los aspectos más malinterpretados de los certificados SSL/TLS es que existen diferentes tipos. Conviene dejar claro en qué se diferencian. El tipo de certificado es una distinción de carácter procedimental, no criptográfico. Todos los certificados SSL/TLS , sea cual sea su tipo, utilizan el mismo cifrado, la misma cadena de confianza y el mismo protocolo de establecimiento de conexión. Lo que varía de un tipo a otro es la información que la autoridad de certificación ha recopilado antes de la firma.

Hay tres tipos, cada uno de ellos definido por una afirmación y una comprobación distintas:

• Validación de dominio (DV):la autoridad de certificación (CA) confirma que el solicitante controla el dominio, a menudo mediante una simple comprobación del registro « DNS ». Este es el tipo más rápido y básico, que suele emitirse en cuestión de minutos y no incluye datos de la organización. Los certificados DV son más adecuados para sitios web personales o internos que para sitios web empresariales dirigidos al público. Obtén más información sobre la validación de dominio en nuestrapágina dedicada a este tema.
• Validación de organización (OV):la autoridad de certificación (CA) confirma el control del dominio y la existencia legal de la organización, comprobando su identidad con los registros oficiales y exigiendo documentación adicional. Los datos de la organización aparecen en el certificado, lo que ofrece mayor garantía a los visitantes. La validación OV es una buena opción para sitios web comerciales que recopilan datos de los usuarios. Consulta nuestra página sobrela validación de organizaciónsi te interesa saber más al respecto.
• Validación ampliada (EV):el tipo más riguroso. La autoridad de certificación (CA) lleva a cabo una revisión exhaustiva de la existencia jurídica, física y operativa de la organización, confirma la autorización del solicitante y aplica controles de emisión por dos personas. La solicitud debe ser iniciada por la propia organización. Los certificados EV se rigen por las Directrices EV del CA/Browser Forum, y los navegadores pueden mostrar indicadores mejorados que señalan el elevado nivel de confianza. Para obtener más información, consulta nuestro análisis en profundidad sobrela validación extendida.

El tipo de certificado también se puede consultar en el propio certificado. Los datos de los certificados OV y EV aparecen en los campos del sujeto; el certificado EV añade atributos como la categoría empresarial de la organización, la jurisdicción de constitución y el número de registro, y un identificador de política indica de qué tipo es el certificado. Las partes que confían en el certificado reconocen el certificado EV al relacionar ese identificador con una raíz de confianza.

La elección del tipo adecuado depende de la finalidad de tu sitio web, del perfil de riesgo y del nivel de garantía de identidad que necesiten tus usuarios. Próximamente publicaremos un artículo detallado sobre cómo elegir y validar certificados; para la mayoría de las organizaciones, la regla práctica es que un tipo más riguroso denota mayor credibilidad, lo cual es fundamental a la hora de gestionar datos confidenciales o transacciones financieras. Obtén más información sobre la validación de certificados en nuestroblog dedicado a este tema.

Ventajas de los certificados « SSL » / «TLS »

La implementación de un certificado SSL/TLS ofrece ventajas que van mucho más allá del icono del candado. Las cuatro más importantes son la protección de datos, la verificación de la identidad, la mejora de la visibilidad en los motores de búsqueda y el cumplimiento normativo.

Cifrado de datos sensibles

La principal ventaja de un certificado SSL/TLS es que cifra los datos confidenciales durante su transmisión, lo que impide los ataques de «hombre en el medio» (MitM). En un ataque MitM, un atacante intercepta la información destinada a un destinatario legítimo, a veces creando un sitio web falso que engaña a los visitantes para que faciliten sus credenciales o datos de pago. Pensemos, por ejemplo, en el inicio de sesión en la banca online: si alguien intercepta ese tráfico sin cifrar, tus credenciales podrían quedar expuestas, lo que abriría la puerta al robo de identidad o a pérdidas económicas. El protocolo TLS evita esto cifrando los datos, de modo que el tráfico interceptado se vea como un galimatías ininteligible, y verificando la identidad del propietario del dominio para que los visitantes accedan al sitio web auténtico.

Verificación de la propiedad del sitio web

Un certificado « SSL » / «TLS » certifica que un sitio web pertenece a quien dice ser. Dado que una autoridad de certificación solo emite el certificado tras verificar la identidad del solicitante y la titularidad del dominio, un certificado firmado avala de forma efectiva a la organización. Como los navegadores confían en la autoridad de certificación, extienden esa confianza a la organización verificada, lo que da a los visitantes la seguridad de que están tratando con una empresa legítima.

Apoyo al cumplimiento normativo

La mayoría de las normativas que regulan los datos sensibles no mencionan el protocolo « TLS » (TCP/IP) por su nombre. Exigen que los datos en tránsito estén protegidos con criptografía sólida, y el protocolo « TLS » (SSL) es el mecanismo por el que se ha decantado el sector para cumplir ese requisito. La norma PCI DSS es la más explícita, ya que exige el uso de criptografía sólida durante la transmisión a través de redes públicas abiertas y descarta por completo las primeras versiones del protocolo « TLS » (SSL). La HIPAA trata la seguridad de la transmisión como una especificación flexible, lo que permite alternativas en principio, pero te obliga a documentar por qué el cifrado no era adecuado. El RGPD menciona el cifrado como un ejemplo de medida técnica adecuada en lugar de exigirlo, aunque sus normas de notificación de violaciones le dan un peso real: los datos que resultan ininteligibles para una parte no autorizada modifican lo que estás obligado a revelar. Estos son solo algunos ejemplos de una lista muy amplia de leyes y marcos de seguridad.

El coste de no tener uno

El protocolo HTTPS dejó de ser un factor diferenciador hace ya algunos años y se ha convertido en el estándar básico. Google incorporó el HTTPS como un factor de posicionamiento de peso relativo en 2014, pero, dada su adopción casi universal en la actualidad, ya no supone prácticamente ninguna ventaja. La consecuencia ahora es justo la contraria: los navegadores etiquetan los sitios que utilizan el protocolo HTTP sin cifrar como «No seguro», y cada vez son más las funciones de las plataformas web que se restringen a orígenes seguros. Un certificado ya no te aporta ninguna ventaja; su ausencia te supone un inconveniente.

Casos de uso habituales de los certificados « SSL » y «TLS »

Aunque los certificados de SSL/TLS son los más visibles en los sitios web, sus aplicaciones abarcan tanto los entornos empresariales internos como los conectados a Internet. El mismo protocolo subyacente protege una variedad sorprendentemente amplia de conexiones.

Protección de sitios web y aplicaciones web

Este es el caso de uso que la mayoría de la gente tiene en mente. Cuando un certificado firmado de SSL/TLS protege un sitio web, demuestra que la organización ha autenticado su identidad ante un tercero de confianza, y el navegador otorga su confianza a dicha organización. Técnicamente, el tráfico web no seguro se transmite a través de HTTP en el puerto 80, un protocolo de texto sin cifrar que resulta relativamente fácil de interceptar y leer para un atacante. El protocolo TLS utiliza, en cambio, el puerto 443, lo que cifra el intercambio entre el navegador y el servidor y autentifica la conexión. Cuando se requiere seguridad, el navegador cambia automáticamente a la conexión segura, siempre que el servidor tenga instalado un certificado válido. Debido a la proliferación del phishing, navegadores como Chrome ahora redirigen a HTTPS de forma predeterminada.

Aplicaciones empresariales y de intranet

Las empresas utilizan los certificados SSL/TLS mucho más allá de sus sitios web públicos. Entre los casos de uso internos más habituales se incluyen los controles de acceso a la red, la autenticación en redes privadas virtuales (VPN) y las implementaciones de inicio de sesión único (SSO). En cada caso, una identidad digital sustituye a la incomodidad que suponen las contraseñas largas y que deben cambiarse con frecuencia. La incorporación de una identidad digital en un ordenador de sobremesa, un servidor o un punto de acceso inalámbrico garantiza que solo los dispositivos autorizados puedan conectarse a los recursos corporativos, y los productos de SSO se basan en el mismo modelo de confianza para conceder acceso a través de un portal o de servicios en la nube.

Seguridad de los dispositivos del Internet de las cosas (IoT)

SSL/ Los certificados «TLS » también autentican los dispositivos. Una identidad digital instalada en un dispositivo IoT garantiza que solo los dispositivos de confianza puedan conectarse a una red y autentica los datos que dichos dispositivos intercambian con aplicaciones autorizadas. A medida que crece el número de dispositivos conectados, esta identidad basada en certificados se vuelve esencial para impedir el acceso de hardware no fiables.

Seguridad del correo electrónico y de las comunicaciones

La misma infraestructura PKI que sustenta TLS también sirve de base para el correo electrónico y las comunicaciones seguras. Cabe señalar que los certificados de firma de correo electrónico son distintos de los certificados de SSL/TLS , ya que utilizan funciones de uso de claves diferentes, aunque se basan en la misma infraestructura. Esto nos recuerda una vez más quelos certificados X.509 y sus casos de uso habitualesvan mucho más allá del navegador web.

Gestión a gran escala de certificados de SSL/TLS

Las definiciones básicas de los certificados de « SSL » / «TLS » rara vez mencionan la parte más complicada: su gestión. La mayoría de las organizaciones dependen de docenas o incluso cientos de certificados repartidos por distintos entornos, y mantenerlos todos válidos supone un auténtico reto operativo. Hay tres problemas que se repiten una y otra vez, y el seguimiento manual mediante hojas de cálculo y recordatorios de calendario tiende a fallar a medida que aumenta el volumen.

El problema de la caducidad del certificado

SSL/TLS Los certificados no duran para siempre y caducan más rápido que nunca. Si se descuida una sola renovación, las consecuencias son inmediatas: los sitios web y las aplicaciones pueden dejar de funcionar, los usuarios pierden la confianza y tu nivel de seguridad se ve afectado. Una solución de gestión de certificados realiza un seguimiento de las fechas de caducidad de todos y cada uno de los certificados, de modo que los equipos dispongan de un amplio margen de tiempo para actuar, en lugar de tener que apresurarse en el último momento. A medida que se acorta su vida útil, esta capacidad de alerta temprana pasa de ser una comodidad a convertirse en una necesidad.

Visibilidad y expansión en distintos entornos

A medida que crecen los inventarios de certificados, la visibilidad se ve mermada. A menudo, los equipos no pueden precisar cuántos certificados gestionan, cuáles están a punto de caducar o dónde está implementado cada uno. La proliferación agrava el problema: en ocasiones, las organizaciones acumulan varios certificados en un mismo dominio simplemente para evitar dejarlo desprotegido durante el ajetreo de la renovación, lo que añade otro elemento más que mantener. Sin un inventario claro, un solo certificado que se pase por alto puede provocar una interrupción del servicio.

Por qué la automatización es ahora imprescindible

Las soluciones de gestión de certificados resuelven estos problemas automatizando la detección, el seguimiento de los vencimientos y simplificando el mantenimiento. La detección automatizada crea un registro preciso y continuamente actualizado de todos los certificados de la empresa, de modo que estos se emiten y renuevan en el momento adecuado sin necesidad de intervención manual. El resultado es una reducción de los errores manuales, una menor carga de trabajo y una probabilidad mucho menor de que se produzca una interrupción del servicio costosa y evitable. Esta es la faceta práctica y cotidiana de la gestión del ciclo de vida de los certificados, y es donde la mayoría de las organizaciones sienten la presión en primer lugar.

El cambio a períodos de validez más cortos para los certificados SSL/TLS

El cambio más importante que se avecina para los certificados SSL es una reducción drástica de su periodo de validez. En abril de 2025, el CA/Browser Forum, el organismo que establece las normas mundiales para los certificados digitales, aprobó la propuesta SC-081v3, que acorta la vigencia máxima de los certificados SSL/TLS de confianza pública según un calendario fijo.

Según ese calendario, el plazo máximo de validez se reducirá progresivamente desde el nivel actual hasta alcanzar una fracción de su duración anterior:

• Máximo de 200 díasantes del 15 de marzo de 2026
• Un máximo de 100 díasantes del 15 de marzo de 2027
• 47 días como máximoantes del 15 de marzo de 2029

Las implicaciones operativas son considerables. Con un plazo máximo de 47 días, las organizaciones tendrán que renovar cada certificado aproximadamente ocho veces más a menudo que con el plazo máximo anterior de 398 días. Esto supone, en la práctica, el fin de la gestión de certificados del tipo «configúralo y olvídate». Una tarea que antes era una labor anual se convierte en un proceso operativo casi continuo.

Para los equipos de TI y seguridad, la respuesta práctica es prepararse ahora en lugar de reaccionar más adelante. Esto implica elaborar un inventario completo de los certificados existentes, identificar en qué casos aún se realizan renovaciones manuales y adoptar la automatización antes de que lleguen los plazos más cortos. Protocolos como ACME (Automated Certificate Management Environment) pueden gestionar la emisión, la renovación y la revocación de forma automática, y actualmente cuentan con una amplia compatibilidad entre las autoridades de certificación. Los equipos que,en la práctica, tratenla gestión del ciclo de vida de los certificadoscomo una disciplina fundamental y continua, en lugar de como un evento que se produce una vez al año, asumirán el cambio con mucha más facilidad que aquellos que dependen del seguimiento manual.

Cómo Keyfactor ayudarte Keyfactor

Los retos que se abordan a lo largo de esta guía, desde la caducidad y la proliferación hasta el ritmo cada vez más acelerado de las renovaciones, apuntan todos a la misma conclusión: los certificados deben gestionarse teniendo en cuenta la rapidez, la flexibilidad y la agilidad criptográfica. « Keyfactor » ayuda a las organizaciones a hacer precisamente eso en tres áreas complementarias.

• Infraestructura PKI moderna.
  Para las organizaciones que desean emitir certificados a escala empresarial, Keyfactorofrece EJBCAopen-source es una plataforma PKI de nivel empresarial que genera confianza y emite identidades en entornos grandes y complejos.
• Automatización del ciclo de vida de los certificados. 
  Keyfactor Command Ofrece visibilidad de principio a fin, detección automática y renovación automática, de modo que los equipos siempre saben cuántos certificados tienen, dónde están implementados y cuándo caducan. Esto resuelve directamente los problemas de caducidad, proliferación y visibilidad que convierten la gestión manual en un lastre.
• PKI como servicio.
  Para los equipos que necesitan una infraestructura de certificados sólida sin la carga operativa que supone gestionarla por sí mismos,PKI como servicioofrece una PKI gestionada y la automatización de certificados en un solo paquete.

En conjunto, estas capacidades reflejanel enfoque deKeyfactorpara gestionar la confianza digital a gran escala: ayudar a las organizaciones a adelantarse al cambio en el periodo de validez de 47 días, evitar interrupciones del servicio y garantizar que todos los certificados estén controlados a medida que crecen sus entornos.