La infraestructura de clave pública (PKI) se utiliza para gestionar la identidad y la seguridad en las comunicaciones por Internet y en las redes informáticas. La tecnología fundamental en la que se basa la PKI es la criptografía de clave pública, un método de cifrado que se basa en el uso de dos claves relacionadas —una clave pública y una clave privada— para proteger los datos y verificar la identidad.

Este par de claves, pública y privada, funciona conjuntamente para cifrar y descifrar mensajes. La combinación de dos claves criptográficas de esta manera también se conoce como cifrado asimétrico, que se diferencia del cifrado simétrico, en el que se utiliza una única clave tanto para el cifrado como para el descifrado.

Entre las ventajas del cifrado asimétrico se incluyen:

• La clave pública puede compartirse de forma segura para el intercambio de claves y el cifrado de datos.
• La clave privada permanece protegida en el dispositivo del usuario para garantizar la seguridad de las operaciones con claves.
• Ofrece una protección más sólida contra los ataques que el cifrado simétrico.

Este sistema es compatible con certificados SSL, firmas digitales y otros protocolos de cifrado que mantienen a salvo los datos confidenciales. La separación entre claves públicas y privadas convierte al cifrado RSA en un pilar de la confianza en las comunicaciones seguras modernas.

Cómo se basa la criptografía de clave pública en el cifrado

La criptografía de clave pública se basa en algoritmos matemáticos para generar pares de claves. La clave pública consiste en una cadena de números aleatorios que se utiliza para cifrar datos, mientras que la clave privada se utiliza para descifrarlos. Solo el destinatario previsto, que posee la clave privada, puede leer los datos cifrados.

Las claves públicas se crean mediante un complejo algoritmo criptográfico que las vincula matemáticamente a sus claves privadas, lo que las hace muy resistentes a los ataques de fuerza bruta o a los intentos de adivinar la clave.

El tamaño de la clave o la longitud en bits de las claves públicas determina la solidez de la protección. Por ejemplo, las claves RSA de 2048 bits se emplean a menudo en certificados SSL, firmas digitales y otros certificados digitales. Esta longitud de clave ofrece suficiente seguridad criptográfica para impedir que los piratas informáticos descifren el algoritmo. Organismos de normalización como el CA/Browser Forum definen requisitos básicos para los tamaños de clave y algoritmos admitidos, con el fin de mantener la confianza y la interoperabilidad entre sistemas.

La PKI hace posible los certificados digitales con los que nos encontramos a diario, de forma discreta y omnipresente, al utilizar sitios web, aplicaciones móviles, documentos en línea y dispositivos conectados. Uno de los casos de uso más comunes de la PKI es el protocolo Transport Layer Security (TLS)/Secure Socket Layer (SSL) basado en X.509. Este constituye la base del protocolo HTTPS, que permite la navegación web segura. Sin embargo, los certificados digitales también se aplican a una amplia gama de casos de uso, entre los que se incluyen la firma de código de aplicaciones, las firmas digitales y otros aspectos de la identidad digital y la seguridad.

Algoritmos RSA, DSA y ECC

Existen tres algoritmos principales que se utilizan para la generación de claves PKI, cada uno de ellos basado en un problema matemático diferente que define su solidez y eficiencia:

• Rivest–Shamir–Adleman (RSA): Basado en la dificultad de factorizar números primos grandes, el cifrado RSA es el algoritmo más consolidado y ampliamente utilizado para certificados SSL y firmas digitales.
• Criptografía de curva elíptica (ECC): Utiliza la estructura algebraica de las curvas elípticas para proporcionar seguridad con longitudes de clave mucho más cortas, lo que mejora el rendimiento y reduce el uso de memoria y los requisitos de ancho de banda.

¿Qué es RSA?

El algoritmo RSA fue desarrollado en 1977 por Ron Rivest, Adi Shamir y Leonard Adleman. Se basa en el hecho de que la factorización de números primos grandes requiere una potencia de cálculo significativa. Fue el primer algoritmo en utilizar el modelo de clave pública/clave privada y sigue gozando de amplia confianza en la actualidad. Existen diferentes longitudes de clave asociadas a RSA, siendo las de 2048 bits el estándar para la mayoría de los sitios web hoy en día.

¿Qué es el ECC?

El cifrado ECC, o criptografía de curva elíptica, se basa en algoritmos matemáticos que rigen la estructura algebraica de las curvas elípticas sobre campos finitos. Proporciona niveles de seguridad criptográfica equivalentes a los de RSA y DSA, con longitudes de clave mucho más cortas, lo que reduce el uso de memoria y las exigencias de ancho de banda. Por ello, es habitual comparar el ECC con el RSA. El ECC ofrece un rendimiento más rápido, especialmente en dispositivos móviles y de IoT. El ECC se estandarizó tras la acreditación del Algoritmo de Firma Digital de Curva Elíptica (ECDSA) en 1999 y también cuenta con el respaldo de la NSA.

¿Qué es el DSA?

El cifrado DSA (Algoritmo de Firma Digital) utiliza un algoritmo diferente al de RSA para crear claves públicas y privadas, basado en la exponenciación modular y el problema matemático del logaritmo discreto. Ofrece los mismos niveles de seguridad que el RSA para claves de tamaño equivalente. La comparación entre DSA y RSA suele reducirse a la velocidad de firma y la eficiencia de la verificación. El DSA fue propuesto por el Instituto Nacional de Estándares y Tecnología (NIST) en 1991 y fue adoptado por la Norma Federal de Procesamiento de la Información (FIPS) en 1993.

Cabe señalar que es posible admitir varios algoritmos de cifrado al mismo tiempo. Por ejemplo, los servidores Apache pueden admitir claves generadas tanto por RSA como por DSA en un mismo servidor, lo que ofrece flexibilidad y una mayor seguridad empresarial.

¿En qué se diferencian RSA y DSA?

Aunque RSA y DSA utilizan tipos diferentes de algoritmos matemáticos para generar sus pares de claves, la diferencia clave entre las claves RSA y DSA radica en el rendimiento y la velocidad, no en la solidez criptográfica.

Rendimiento y velocidad

El cifrado RSA es más rápido que el DSA a la hora de cifrar y firmar, pero es más lento que el DSA para descifrar y verificar. Sin embargo, dado que la autenticación requiere ambas operaciones con claves, la diferencia de rendimiento en la práctica es mínima para la mayoría de las aplicaciones.

RSA también es más lento que DSA en lo que respecta a la generación de claves, pero, dado que las claves se generan una sola vez y se utilizan durante meses o años, esto no suele ser un factor importante a tener en cuenta.

Compatibilidad con el protocolo SSH

Otra diferencia radica en la compatibilidad con el protocolo Secure Shell (SSH). RSA es compatible tanto con el SSH original como con la segunda edición más reciente, SSH2, mientras que DSA solo es compatible con SSH2. Dado que SSH2 es más seguro, esta distinción puede influir en la elección entre DSA y RSA en determinados entornos.

Respaldo federal

Otra diferencia entre DSA y RSA es que DSA cuenta con el respaldo del Gobierno Federal de EE. UU. Para las empresas que prestan servicios a organismos federales, mantener la conformidad con las normas gubernamentales puede ser un motivo para elegir DSA.

En definitiva: para la mayoría de los casos de uso, sectores y entornos normativos, RSA y DSA son muy similares, ofrecen una solidez criptográfica equivalente y hay relativamente poca diferencia entre ambos. Los dos algoritmos son también igualmente compatibles con los principales protocolos de Internet, incluidos Nettle, OpenSSL, wolfCrypt, Crypto++ y cryptlib.

¿En qué se diferencia el ECC del RSA y el DSA?

La mayor diferencia entre el ECC y el RSA y el DSA es la mayor solidez criptográfica que ofrece el ECC para un tamaño de clave equivalente. Una clave ECC es más segura que una clave RSA o DSA del mismo tamaño, ya que ofrece una seguridad equivalente con una demanda computacional mucho menor.

Comparación del tamaño de las claves:

Tamaños de clave recomendados según el NIST

El ECC es más eficiente

Como muestra la figura, con el ECC se consigue una resistencia criptográfica equivalente a la de RSA o DSA con tamaños de clave significativamente menores —aproximadamente un orden de magnitud más pequeños—. Por ejemplo, para alcanzar la resistencia criptográfica equivalente al cifrado con una clave simétrica de 112 bits se necesitaría una clave RSA de 2048 bits, pero solo una clave ECC de 224 bits. El tamaño reducido se traduce en operaciones con claves más rápidas, un menor uso de memoria y un mejor rendimiento para los certificados SSL y los procesos de intercambio seguro de claves.

Las longitudes de clave más cortas implican que los dispositivos necesitan menos potencia de procesamiento para cifrar y descifrar datos, lo que hace que ECC sea una buena opción para dispositivos móviles, el Internet de las cosas y otros casos de uso con una potencia de cálculo más limitada.

Seguridad y velocidad

La ECC también presenta algunas ventajas frente a RSA o DSA en casos de uso más tradicionales, como los servidores web, ya que el menor tamaño de las claves permite una mayor seguridad con handshakes SSL más rápidos, lo que se traduce en tiempos de carga de las páginas web más rápidos. Las claves ECC más pequeñas permiten una mayor protección sin perder eficiencia, lo que supone una ventaja importante en implementaciones a gran escala.

Cabe destacar que ECDSA, la versión original de la ECC, es una variante de DSA. ECDSA ofrece niveles de solidez criptográfica equivalentes por número de bits que el ECC.

¿Por qué no se utiliza ampliamente la criptografía de curva elíptica?

Aunque RSA es el algoritmo más utilizado, el ECC ha ido ganando popularidad a lo largo de los años. Una de las razones más sencillas del predominio de RSA es que lleva más tiempo en el mercado. Dicho esto, el ECC presenta algunos inconvenientes que podrían explicar mejor por qué la gente lo evita:

• Complejidad: Aprender y adoptar la ECC lleva más tiempo y es un proceso más complejo que el de RSA. Esto puede aumentar el riesgo de errores, lo que tendrá un impacto negativo en la ciberseguridad.
• Vulnerabilidades: La ECC puede ser vulnerable a los ataques de canal lateral (SCA), que pueden dar lugar a ataques de fuerza bruta. También puede ser vulnerable a los ataques de seguridad por «twist», aunque existen contramedidas para ayudar a prevenir estos ataques.
• Compatibilidad: Las infraestructuras más antiguas y el software heredado se diseñaron principalmente en torno a RSA y DSA, lo que limita la compatibilidad con el ECC en algunos entornos. Sin embargo, a medida que los estándares evolucionan y las implementaciones del ECC maduran, cada vez más organizaciones están adoptando el ECC por su eficiencia y solidez a largo plazo.

La informática cuántica y el futuro de los algoritmos de cifrado

La computación cuántica supone una grave amenaza para los métodos de criptografía tradicionales como RSA, DSA y ECC. Estos algoritmos se basan en problemas matemáticos, como la factorización de números primos grandes y los logaritmos discretos, que podrían resolverse casi al instante con un ordenador cuántico. Si eso ocurriera, el cifrado utilizado en la mayoría de los certificados SSL, las firmas digitales y las comunicaciones seguras podría descifrarse en cuestión de segundos.

Repercusiones en el mundo real cuando lleguen los ordenadores cuánticos

Repercusiones en el mundo real cuando lleguen los ordenadores cuánticos

Si las organizaciones no adoptan una criptografía a prueba de cuántica antes de que los ordenadores cuánticos a gran escala estén disponibles, los siguientes escenarios serán altamente probables:

• Ataques del tipo «recoger ahora, descifrar más tarde»: Los adversarios recogen hoy en día comunicaciones cifradas que se basan en sistemas que utilizan claves RSA, ECC o DSA, las almacenan y luego las descifran una vez que los recursos cuánticos estén disponibles.
• Confidencialidad comprometida: Los sitios web, los sistemas de correo electrónico, las redes privadas virtuales y otros canales seguros protegidos con criptografía clásica de clave pública podrían verse vulnerados en cuestión de minutos, en lugar de años.
• Autenticación y firmas digitales socavadas: Los marcos de confianza que dependen de algoritmos de firma digital (por ejemplo, versiones de DSA y ECC) pueden ser falsificados o invalidados, lo que pone en riesgo la distribución de software, las transacciones financieras, la verificación de identidad y los documentos electrónicos.
• Riesgo para las infraestructuras críticas: Los sistemas de los sectores financiero, sanitario, energético, de transporte y gubernamental que dependen de la criptografía de clave pública podrían sufrir interrupciones operativas, exposición de datos o inyección de datos falsos si se descifra el cifrado.
• Exposición normativa y de cumplimiento: Las organizaciones podrían encontrarse en situación de incumplimiento de las nuevas obligaciones que exigen la migración a estándares criptográficos a prueba de la computación cuántica, lo que las expondría a sanciones legales, reputacionales o financieras.

¿Cuáles son los nuevos estándares de cifrado poscuántico del NIST?

Para prepararse para este cambio, el Instituto Nacional de Estándares y Tecnología (NIST) ha evaluado la actual criptografía poscuántica (PQC) y ha introducido nuevos estándares de cifrado poscuántico en el marco de las Normas Federales de Procesamiento de la Información (FIPS). Estos nuevos algoritmos están diseñados para resistir ataques tanto de ordenadores clásicos como cuánticos.

• FIPS 203 – ML-KEM (CRYSTALS-Kyber): El estándar principal para el cifrado, que utiliza matemáticas basadas en retículas para claves pequeñas y rápidas y un bajo consumo de memoria.
• FIPS 204 – ML-DSA (CRYSTALS-Dilithium): El estándar principal para las firmas digitales, que equilibra la alta velocidad con una sólida protección criptográfica.
• FIPS 205 – SLH-DSA (SPHINCS+): Una alternativa sin estado basada en hash para FIPS 204; es más lenta y ocupa más espacio, pero utiliza una estructura matemática diferente para ofrecer mayor resiliencia.
• FIPS 206 – FN-DSA (FALCON): Un nuevo estándar, aún sin finalizar, que se denominará FN-DSA, abreviatura de FFT (transformada rápida de Fourier) sobre el algoritmo de firma digital basado en retículas NTRU.

Próximos pasos: desarrollar una estrategia de seguridad resistente a la computación cuántica

La preparación para la era cuántica comienza con la concienciación y una planificación proactiva. Las organizaciones deben empezar por identificar dónde se utilizan actualmente los algoritmos RSA, DSA y ECC, incluyendo certificados SSL, VPN, sistemas de autenticación internos y la firma de código de aplicaciones. A partir de ahí, los equipos de seguridad pueden priorizar la migración a algoritmos seguros frente a la computación cuántica.

La estrategia Q.U.A.N.T. de Sectigo ofrece un marco claro para guiar este proceso, ayudando a las empresas a cuantificar su huella criptográfica, detectar riesgos y evaluar y diseñar estrategias para una transición segura. A través de este enfoque, los equipos pueden llevar a cabo la implementación con soluciones automatizadas y a prueba de cuántica, y realizar un seguimiento del progreso continuo para mantener la agilidad criptográfica a medida que evolucionan los estándares.

Las organizaciones pueden mantenerse a la vanguardia asociándose con una autoridad de certificación de confianza como Sectigo, líder en el desarrollo de la criptografía poscuántica.

Protege tu futuro con las soluciones de seguridad preparadas para la PQC de Sectigo

Ahora que comprendes en qué se diferencian los algoritmos de cifrado RSA, DSA y ECC, y cómo la computación cuántica pronto transformará los estándares de cifrado, es hora de preparar a tu organización para lo que está por venir. Sectigo ofrece certificados digitales de confianza y soluciones avanzadas de criptografía poscuántica diseñadas para ayudar a las empresas a realizar una transición fluida hacia el cifrado de próxima generación.

Contáctanos para aprender más sobre cómo nuestros productos pueden proteger tu sitio web de amenazas de seguridad. También recomendamos explorar las soluciones PQC de Sectigo.

Si bien los algoritmos resistentes a la computación cuántica resuelven el problema criptográfico, plantean uno práctico: claves y firmas mucho más grandes. Si se implementaran a través de la infraestructura de clave pública (PKI) actual, sobrecargarían todas las conexiones seguras, lo que aumentaría los costes de ancho de banda, procesamiento y almacenamiento en todo Internet. Los usuarios de dispositivos móviles y las redes de alta latencia serían los más afectados, pero algunos sistemas, como los servidores web heredados y los equilibradores de carga, podrían dejar de funcionar por completo.

Conscientes de estas limitaciones, criptógrafos de todo el sector, incluidos equipos de Google y Cloudflare, con la colaboración de Sectigo, han estado desarrollando un nuevo enfoque. Los certificados de árbol de Merkle (MTC) no imponen grandes firmas poscuánticas a una infraestructura que no fue diseñada para ellas, sino que replantean cómo se crean y se distribuyen los certificados para la era poscuántica.

¿Qué es un certificado de árbol de Merkle?

Un MTC es un nuevo enfoque de los certificados digitales que reduce drásticamente la cantidad de datos intercambiados durante una conexión segura. En lugar de firmar cada certificado individualmente y enviar una cadena completa con cada establecimiento de conexión, una autoridad de certificación agrupa los certificados que emite en una única estructura denominada «árbol de Merkle». La autoridad firma el árbol en lugar de cada certificado, y los navegadores reciben las puntas de confianza del árbol con antelación a través de una infraestructura de transparencia. Los elementos del árbol que se firman son resúmenes hash, que en sí mismos son resistentes a los ataques cuánticos.

Cuando un navegador se conecta a un sitio web, este presenta una prueba breve —solo un puñado de hash— que demuestra que su certificado pertenece a un árbol en el que el navegador ya confía. La pesada cadena de firmas nunca se transmite por la red. Esa diferencia es importante a escala poscuántica. Una sola firma ML-DSA ocupa aproximadamente 2,4 kilobytes, y una cadena convencional transportaría varias de ellas, además de los artefactos de transparencia. La prueba de Merkle que las sustituye suele ocupar menos de un kilobyte.

Es probable que los MTC coexistan con los certificados que utilizamos hoy en día. Hay que anticiparse a un futuro en el que los métodos resistentes a los ataques cuánticos sigan siendo eficientes, transparentes y compatibles con la web tal y como la conocemos actualmente.

¿Por qué son importantes los certificados de árbol de Merkle para Internet?

La PKI está presente en todas nuestras pilas tecnológicas. Las aplicaciones en la nube, las cargas de trabajo impulsadas por IA y miles de millones de dispositivos conectados dependen de handshakes TLS rápidos y constantes. Si la autenticación poscuántica ralentiza esos handshakes, todo el mundo lo notará. Los MTC son importantes porque eliminan esa desventaja de dos formas importantes.

1. Los certificados de árbol de Merkle ayudan a mantener la velocidad de Internet

Imponer las firmas poscuánticas tradicionales en los sitios web públicos aumentaría enormemente el tamaño de los handshakes y degradaría la experiencia del usuario, especialmente en dispositivos móviles y conexiones de alta latencia. Los MTC eluden el problema sustituyendo múltiples firmas de gran tamaño por una única prueba de inclusión compacta, lo que mantiene la sobrecarga cercana a la que experimentan los usuarios en la actualidad. Podemos seguir utilizando Internet exactamente como lo hacemos ahora, de forma rápida e ininterrumpida, con resistencia cuántica subyacente.

2. Los certificados de árbol de Merkle integran la transparencia en el diseño

En la PKI actual, el registro de la transparencia de certificados (CT) se añade como un paso independiente al proceso de emisión. Cuando falla el registro, un certificado puede permanecer en circulación sin que nadie se dé cuenta, creando un punto ciego de seguridad.

Los MTC invierten esa relación. El acto de crear un certificado es el acto de registrarlo. Si un certificado no está en el árbol, simplemente no existe. Esto es importante porque la autenticación en un mundo poscuántico no puede ser verdaderamente segura sin una visibilidad total, y los MTC hacen que ambos aspectos sean inseparables.

Nuestra visión: Sectigo y los certificados de árbol de Merkle

El impulso que hay detrás de este cambio es real y cuantificable. Los navegadores han señalado que los MTC son su vía preferida para llevar los certificados poscuánticos a la web pública, y ya se están llevando a cabo experimentos de viabilidad con tráfico real de Internet. Sectigo cree que los MTC representan la vía más prometedora hacia la autenticación poscuántica que preserva el rendimiento y la escalabilidad de los que dependen hoy en día las organizaciones.

Al mismo tiempo, seguimos de cerca el ecosistema poscuántico en su conjunto, desde los algoritmos estandarizados por el NIST, como el ML-DSA, hasta las especificaciones en evolución de la IETF, las decisiones sobre la hoja de ruta de los navegadores y los requisitos de adopción por parte de las empresas. El alcance total de lo que pueden hacer los MTC aún se está definiendo. Lo que ya está claro es que las organizaciones necesitan visibilidad, automatización y agilidad criptográfica para adaptarse a medida que maduran los estándares. Sectigo mantiene su compromiso de ayudar a los clientes a prepararse para ese futuro, sea cual sea la forma que adopte la arquitectura de certificados subyacente.

Estos certificados vinculan una clave pública a una identidad verificada, lo que permite a los sistemas confirmar la legitimidad de una entidad digital. Constituyen la base de la seguridad en línea, protegiendo las comunicaciones entre sitios web, aplicaciones, documentos y dispositivos.

Cada certificado X.509 incluye una clave pública, datos de identificación y una firma digital de una autoridad de certificación (CA) de confianza. La firma digital confirma la integridad y el origen del certificado, formando parte de una cadena de certificados que remite a una CA raíz de confianza. Esta estructura fomenta la confianza y ayuda a prevenir la suplantación de identidad.

Una de las principales ventajas de un certificado X.509 es que utiliza un par de claves compuesto por una clave pública y una clave privada relacionadas entre sí. En criptografía, el par de claves pública y privada se utiliza para establecer claves de sesión seguras, verificar identidades y permitir la comunicación cifrada.

La aplicación más habitual de la PKI basada en X.509 es el Protocolo de Capa de Sockets Seguros (SSL) / Seguridad de la Capa de Transporte (TLS), la base del protocolo HTTPS que permite la navegación web segura. Más allá de HTTPS, el estándar X.509 también se utiliza para la firma de código con fines de seguridad de las aplicaciones, las firmas digitales y otros protocolos críticos de Internet.

Historial de versiones de X.509

La primera versión del estándar X.509 se publicó en 1988. Para formalizar las normas de emisión de certificados, el Sector de Normalización de las Telecomunicaciones de la UIT (UIT-T) desarrolló un sistema jerárquico de nombres distinguidos que seguía las normas del servicio de directorio electrónico de X.500 y se inspiraba en los sistemas utilizados para asignar números de teléfono a nivel mundial, pero adaptado a los requisitos organizativos más flexibles de Internet.

La versión 3 introdujo una importante actualización con soporte para múltiples extensiones. Las revisiones posteriores han perfeccionado el estándar v3 para dar respuesta a los casos de uso modernos de Internet y a las necesidades de seguridad en constante evolución.

Además, el Grupo de Trabajo de Ingeniería de Internet (IETF), a través de su grupo de trabajo sobre infraestructura de clave pública conocido como PKIX, adaptó el estándar de certificados X.509 v3 para crear el certificado de infraestructura de clave pública X.509 de Internet y la lista de revocación de certificados (CRL), conocido como RFC 5280. Este perfil se utiliza ahora ampliamente para definir cómo se gestionan los certificados y las listas de revocación en los sistemas de Internet.

Las ventajas de los certificados X.509

Dado que los certificados X.509 facilitan la mensajería segura y la navegación web, su uso reporta importantes ventajas a las organizaciones. Se utilizan para autenticar sitios web, cifrar datos en tránsito y validar usuarios y dispositivos tanto en redes públicas como privadas. Su estructura, que incluye una firma digital de confianza de una autoridad de certificación (CA), los convierte en un elemento fundamental para el funcionamiento de protocolos de comunicación seguros como SSL/TLS y S/MIME.

Al vincular una identidad verificada a una clave pública, los certificados X.509 establecen una confianza digital que respalda la seguridad y la privacidad de los datos en cada interacción. Estas ventajas se extienden al tráfico web, los sistemas internos, las API, las comunicaciones por correo electrónico y mucho más.

Establecer confianza

Los certificados digitales, también conocidos como certificados de clave pública, permiten a personas, organizaciones e incluso dispositivos demostrar su identidad en un contexto digital. Como base de todas las identidades digitales, los certificados X.509 están presentes en todas partes y son esenciales para cualquier proceso conectado, desde sitios web hasta aplicaciones, pasando por dispositivos finales y documentos en línea. Por ejemplo, sin ellos, no podríamos confiar en que www.amazon.com sea realmente el sitio web de Amazon.

Este nivel de confianza se construye no solo a través de la arquitectura criptográfica, sino también mediante el proceso de emisión de certificados. El formato X.509 permite la validación de la identidad al confirmar que:

1. La clave pública pertenece al dominio, la organización o la persona física que figura en el certificado
2. El certificado ha sido firmado por una autoridad de certificación (CA) de confianza, como Sectigo, o es autofirmado
3. El certificado cumple con las políticas de certificados definidas y no ha sido revocado ni alterado

Cuando un certificado está firmado por una CA de confianza, el usuario del certificado puede estar seguro de que se ha validado al titular del certificado o al nombre de host/dominio, mientras que los certificados autofirmados son menos fiables, ya que el titular no se somete a ninguna validación adicional antes de la emisión.

Facilitar la escalabilidad

La arquitectura de infraestructura de clave pública (PKI) en la que se basan los certificados X.509 admite una escalabilidad masiva. Las organizaciones pueden proteger miles de millones de intercambios de datos diarios mediante certificados que no requieren intervención manual para su verificación o descifrado. Esto es posible porque las claves públicas pueden distribuirse abiertamente, sin revelar la clave privada necesaria para desbloquear los datos cifrados.

Esto hace que los certificados X.509 sean especialmente eficaces a la hora de ampliar la identidad segura y el cifrado en servicios en la nube, redes empresariales, dispositivos conectados y sistemas transfronterizos.

Ayuda a lograr la agilidad criptográfica

El estándar X.509 admite múltiples algoritmos criptográficos, incluidos RSA, ECC y DSA, y se está ampliando para admitir los algoritmos poscuánticos emergentes. Esta flexibilidad permite a las organizaciones adoptar una criptografía más sólida con el paso del tiempo sin tener que reconstruir toda su infraestructura PKI. A medida que los algoritmos evolucionan y las amenazas aumentan, esta agilidad criptográfica garantiza que los sistemas permanezcan protegidos con un cifrado actualizado y basado en estándares.

Fomentar la interoperabilidad

El estándar X.509 es compatible de forma universal con navegadores, sistemas operativos, plataformas móviles, dispositivos de red y proveedores de servicios en la nube. Esta amplia compatibilidad permite que los certificados funcionen de manera coherente en diferentes entornos y con distintos proveedores.

Facilitar la automatización y la gestión del ciclo de vida

Los ciclos de vida de los certificados digitales pueden gestionarse automáticamente mediante protocolos como ACME, EST y SCEP. Las organizaciones pueden emitir, renovar y revocar certificados X.509 a gran escala sin intervención manual. Esta automatización reduce el riesgo de certificados caducados, interrupciones del servicio o errores humanos, y ayuda a mantener la disponibilidad de los sistemas críticos.

¿Cómo funcionan los certificados X.509?

Los certificados X.509 funcionan vinculando una clave pública a una identidad verificada mediante una firma digital de una autoridad de certificación (CA) de confianza. El certificado sigue una estructura definida que permite el cifrado seguro de datos, la autenticación y la validación de la confianza entre sistemas.

El estándar X.509 se basa en un lenguaje de descripción de interfaces conocido como Notación de Sintaxis Abstracta Uno (ASN.1), que define estructuras de datos que pueden serializarse y deserializarse de forma multiplataforma. Mediante el par de claves asociado al certificado, los sistemas pueden establecer sesiones seguras, verificar firmas digitales y proteger las comunicaciones.

Los fundamentos de la infraestructura de clave pública

La clave pública consiste en una cadena de números aleatorios y puede utilizarse para cifrar un mensaje. Solo el destinatario previsto puede descifrar y leer este mensaje cifrado, y ello solo es posible utilizando la clave privada asociada, que también está formada por una larga cadena de números aleatorios. La clave privada permanece secreta y nunca se comparte.

Dado que la clave pública se publica para que todo el mundo pueda verla, las claves públicas se crean mediante un complejo algoritmo criptográfico que las empareja con una clave privada asociada, generando combinaciones numéricas aleatorias de longitudes variables para que no puedan ser vulneradas mediante un ataque de fuerza bruta.

Los algoritmos más comunes utilizados para generar claves públicas son:

• Rivest–Shamir–Adleman (RSA): un algoritmo muy utilizado que se basa en la dificultad de factorizar números primos grandes.
• Criptografía de curva elíptica (ECC): utiliza curvas elípticas sobre campos finitos para proporcionar una seguridad sólida con longitudes de clave más cortas.
• Algoritmo de firma digital (DSA): se basa en la exponenciación modular y en el problema del logaritmo discreto.

El tamaño de la clave o la longitud en bits de las claves públicas determina la solidez de la protección. Por ejemplo, las claves RSA de 2048 bits se utilizan ampliamente en certificados SSL, firmas digitales y otros certificados digitales. Esta longitud de clave ofrece suficiente seguridad criptográfica para impedir que los piratas informáticos descifren el algoritmo. Grupos de normalización como el CA/Browser Forum definen tamaños mínimos de clave y requisitos criptográficos para mantener la confianza y la compatibilidad entre navegadores y sistemas.

Figura: Los certificados X.509 utilizan un par de claves pública y privada relacionadas para la autenticación de la identidad y la seguridad de las comunicaciones por Internet y las redes informáticas

Los certificados X.509 utilizan un par de claves pública y privada relacionadas para la autenticación de la identidad y la seguridad de las comunicaciones por Internet y las redes informáticas.

Campos de emisión

Los campos de los certificados X.509 contienen información sobre la identidad a la que se expide el certificado, así como la identidad de la CA emisora. Los campos estándar incluyen:

• Versión: La versión X.509 utilizada, que determina la estructura y las extensiones disponibles.
• Número de serie: El identificador único de número de serie proporcionado por la CA que distingue el certificado de los demás.
• Algoritmo de firma: El método específico de hash y cifrado utilizado para generar la firma digital.
• Valor de la firma: La propia firma digital, creada por la clave privada de la CA para autenticar el contenido del certificado.
• Nombre distinguido del emisor: El nombre de la CA que emite el certificado
• Período de validez del certificado: La fecha y hora de inicio y fin en las que es válido y se puede considerar fiable
• Nombre distinguido del sujeto: El nombre de la identidad a la que se expide el certificado
• Información de la clave pública del sujeto: – la clave pública asociada a la identidad

Figura: Los certificados X.509 utilizan un par de claves pública y privada relacionadas para la autenticación de la identidad y la seguridad de las comunicaciones por Internet y las redes informáticas

Extensiones comunes de los certificados digitales

Además de sus campos de información estándar, la versión 3 de X.509 introdujo extensiones que amplían la funcionalidad de los certificados para el uso moderno de Internet.

Dos extensiones comunes de los certificados X.509 que se utilizan hoy en día son:

• Extensión de nombre alternativo del sujeto (SAN): Permite que un certificado vincule varias identidades a la misma clave pública. Esto puede incluir dominios adicionales, nombres DNS, direcciones IP o direcciones de correo electrónico. Gracias a esta extensión, un único certificado puede abarcar varios puntos finales, lo que reduce la complejidad y el coste. Los certificados con SAN suelen denominarse certificados multidominio.
• Uso de la clave (Key Usage): Define cómo se puede utilizar la clave pública, por ejemplo, para firmas digitales, cifrado de claves o firma de certificados. Por ejemplo, un certificado con el uso «solo para firma» no puede utilizarse para el cifrado. Esto evita el uso indebido y garantiza que los certificados se apliquen según lo previsto.

Otras extensiones de uso común son el uso extendido de la clave (Extended Key Usage), las restricciones básicas (Basic Constraints) y los puntos de distribución de listas de certificados revocados (CRL Distribution Points), dependiendo de la función y el entorno del certificado.

Los certificados digitales aplican cadenas de confianza jerárquicas

Para reforzar aún más la confianza en una identidad, a menudo se combinan varios certificados digitales para construir una cadena de confianza jerárquica que proporciona una serie de capas de verificación. Cada uno de ellos debe estar firmado por una CA emisora como parte del proceso de verificación X.509. La CA se identifica y se almacena en la raíz del certificado. Se pueden incluir certificados intermedios adicionales en la cadena de confianza, los cuales deben ser validados.

La cadena completa de certificados suele incluir:

• Certificado raíz
• Certificado intermedio
• Certificado final

Por ejemplo, cuando un cliente de navegador web lee el certificado, debe poder seguir la ruta jerárquica de certificación, incluidos los certificados intermedios necesarios para la validación que están vinculados de forma recursiva a la CA raíz que figura en el almacén de confianza del cliente, lo que da como resultado una cadena de confianza completa.

Figura: Los certificados SSL/TLS suelen combinar certificados de CA intermedios para crear una cadena de confianza jerárquica

Listas de revocación de certificados (CRL)

El estándar X.509 también define el uso de una lista de revocación de certificados, que identifica todos los certificados digitales que han sido revocados por la CA emisora antes de la fecha de caducidad prevista. La revocación suele producirse cuando se ve comprometida una clave privada, el certificado se ha emitido de forma incorrecta o cambia la situación del titular del certificado.

Estos certificados revocados ya no deben considerarse fiables.

Las CRL ofrecen una forma sencilla de distribuir información sobre estos certificados no válidos. Sin embargo, los navegadores web y las aplicaciones modernas están dejando de utilizar cada vez más las CRL en favor de métodos más eficientes, como el Protocolo de estado de certificados en línea (OCSP) y el «stapling» de OCSP, que ofrecen funciones de revocación completas.

Codificación de certificados PKI

Un elemento destacable que no se define en el estándar X.509 es cómo debe codificarse el contenido del certificado para su almacenamiento en archivos.

Existen dos esquemas de codificación que se utilizan habitualmente para almacenar certificados digitales en archivos:

• Reglas de codificación distinguidas (DER) es el más común, ya que este esquema abarca la mayoría de los objetos de datos. Los certificados codificados mediante DER son archivos binarios y no pueden leerse con editores de texto, pero pueden procesarse mediante navegadores web y numerosas aplicaciones cliente.
• Privacy Enhanced Mail (PEM) es un esquema de codificación de correo electrónico cifrado que puede utilizarse para convertir certificados codificados en DER en archivos de texto.

Aplicaciones habituales de la infraestructura de clave pública X.509

Muchos protocolos de Internet se basan en X.509, y existen numerosas aplicaciones de la tecnología PKI que se utilizan a diario, entre ellas la seguridad de los servidores web, las firmas digitales y la firma de documentos, así como las identidades digitales.

Seguridad de los servidores web con certificados SSL/TLS

La PKI es la base de los protocolos SSL/TLS que admiten conexiones HTTPS en los navegadores web modernos. Sin certificados SSL o TLS para establecer conexiones seguras, los ciberdelincuentes podrían aprovechar Internet u otras redes IP utilizando diversos vectores de ataque, como los ataques de «hombre en el medio», para interceptar mensajes y acceder a su contenido.

Firmas digitales y firma de documentos

Además de utilizarse para proteger mensajes, los certificados basados en PKI permiten realizar firmas digitales a prueba de manipulaciones y una firma de documentos verificada.

Las firmas digitales son un tipo específico de firma electrónica que aprovecha la PKI para autenticar la identidad del firmante y la integridad de la firma y del documento. Las firmas digitales no pueden alterarse ni duplicarse de ninguna manera, ya que la firma se crea generando un hash, que se cifra utilizando la clave privada del remitente. Esta verificación criptográfica vincula matemáticamente la firma al mensaje original para garantizar que el remitente está autenticado y que el mensaje en sí no ha sido alterado.

Firma de código

La firma de código permite a los desarrolladores añadir una capa de seguridad mediante la firma digital de aplicaciones, controladores y programas de software, de modo que los usuarios finales puedan verificar que un tercero no ha alterado ni comprometido el código que reciben. Para verificar que el código es seguro y fiable, estos certificados digitales incluyen la firma del desarrollador de software, el nombre de la empresa y una marca de tiempo.

Certificados de correo electrónico

Los certificados S/MIME se utilizan para validar a los remitentes de correo electrónico y cifrar el contenido de los mensajes y los archivos adjuntos. Esto impide que los atacantes suplanten identidades o lean los mensajes mientras están en tránsito.

S/MIME aprovecha los certificados X.509 para proteger las comunicaciones por correo electrónico tanto personales como corporativas, protegiendo contra el spear phishing, la pérdida de datos y los ataques sofisticados de ingeniería social.

Muchos sectores confían en S/MIME para cumplir con los requisitos normativos o de cumplimiento.

Identidades digitales

Los certificados X.509 también proporcionan una eficaz autenticación de identidad digital. A medida que los datos y las aplicaciones se expanden más allá de las redes tradicionales hacia dispositivos móviles, nubes públicas, nubes privadas y dispositivos del Internet de las cosas, proteger las identidades cobra más importancia que nunca. Y las identidades digitales no tienen por qué limitarse a los dispositivos; también pueden utilizarse para autenticar a personas, datos o aplicaciones. Los certificados de identidad digital basados en este estándar permiten a las organizaciones mejorar la seguridad al sustituir las contraseñas, que los atacantes son cada vez más hábiles a la hora de robar.

¿Cómo se obtiene un certificado X.509?

Un componente fundamental para la implementación de certificados X.509 es una autoridad de certificación (CA) o un agente de confianza que emita los certificados y publique las claves públicas asociadas a las claves privadas de los usuarios. Sin esta CA de confianza, sería imposible para los remitentes saber que, de hecho, están utilizando la clave pública correcta asociada a la clave privada del destinatario y no la clave asociada a un actor malintencionado que pretenda interceptar información confidencial y utilizarla con fines maliciosos.

Dispones de varias opciones para obtener certificados X.509:

• Utilizar una autoridad de certificación (CA) de terceros de confianza: Proveedores como Sectigo validan la identidad del solicitante y emiten certificados respaldados por una jerarquía de confianza pública.
• Gestionar tu propia CA interna: Muchas empresas y proveedores tecnológicos optan por gestionar su propia CA para emitir certificados para sistemas, dispositivos o usuarios internos.
• Utilizar certificados autofirmados: Estos los crea y firma la propia organización. Aunque son fáciles de generar, no gozan de confianza pública y requieren una configuración manual de la confianza.

Independientemente del método que elijas, la autoridad de certificación debe:

• Validar la identidad del solicitante antes de emitir el certificado.
• Confirmar que la clave pública publicada está correctamente asociada a la clave privada del solicitante.
• Mantener sólidas prácticas de seguridad interna para protegerse contra vulneraciones o abusos.

Gestionar certificados X.509 con Sectigo

Uno de los aspectos más críticos de los certificados X.509 es gestionarlos de forma eficaz a gran escala mediante la automatización. Sin contar con personal, procesos y tecnología de calidad, las empresas se exponen a brechas de ciberseguridad, interrupciones del servicio, daños a su marca y fallos en infraestructuras críticas.

Sectigo Certificate Manager (SCM) Pro ofrece un control centralizado sobre todo el ciclo de vida de los certificados públicos y privados. Desde la emisión hasta la renovación y la revocación, SCM Pro permite la automatización, la aplicación de políticas y una integración perfecta en su entorno tecnológico actual.

SCM Enterprise amplía esta capacidad a todas las identidades humanas y de máquinas de su organización, ofreciendo una gestión completa del ciclo de vida de los certificados desde una única plataforma.

Las firmas electrónicas, conocidas comúnmente como «firmas e», constituyen un amplio conjunto de soluciones que utilizan un proceso electrónico para validar un documento o una transacción mediante una firma. A medida que los documentos y las comunicaciones se vuelven cada vez más digitales, las empresas y los consumidores de todo el mundo han adoptado la rapidez y la comodidad que ofrecen este tipo de firmas. Sin embargo, existen muchos tipos diferentes de firmas electrónicas, cada uno de los cuales permite a los usuarios firmar documentos digitalmente y ofrece cierto grado de autenticación de identidad.

Las firmas digitales son un tipo específico de firma electrónica y constituyen el tipo más seguro que existe. Las firmas digitales se basan en certificados PKI emitidos por una autoridad de certificación (CA). Antes de emitir un certificado de firma de documentos, la CA verifica la identidad del firmante mediante un proceso de verificación. Este proceso puede implicar comprobaciones de documentación, verificación de la organización u otros procedimientos, dependiendo del tipo de certificado: validación de organización (OV) o validación extendida (EV). Otros tipos de firma electrónica menos seguros pueden utilizar métodos comunes de autenticación electrónica para verificar la identidad del firmante, como una dirección de correo electrónico, un nombre de usuario o una identificación corporativa, o un número de teléfono o un PIN.

Debido a los diferentes requisitos técnicos y de seguridad, las firmas electrónicas varían en cuanto a su aceptación en el sector, la zona geográfica y el ámbito jurídico. Las firmas digitales cumplen con los requisitos normativos más exigentes, incluida la Ley Federal ESIGN de Estados Unidos y otras leyes internacionales aplicables.

¿Cómo funcionan las firmas digitales?

Las firmas digitales utilizan la PKI, considerada el estándar de referencia para la autenticación de la identidad digital y el cifrado. La PKI se basa en el uso de dos claves relacionadas, una clave pública y una clave privada, para cifrar y descifrar un mensaje mediante potentes algoritmos de criptografía de clave pública. La firma se genera utilizando la clave privada del firmante, lo que vincula de forma segura su identidad al documento. También se puede aplicar una marca de tiempo para registrar cuándo se firmó el documento y ayudar a preservar su validez a lo largo del tiempo.

Así es como funciona el envío de una firma digital:

1. El remitente selecciona el archivo que desea firmar digitalmente en la plataforma de documentos o en la aplicación.
2. El ordenador del remitente calcula el valor hash único del contenido del archivo.
3. Este valor hash se cifra con la clave privada del remitente para crear la firma digital.
4. El archivo original, junto con su firma digital, se envía al destinatario.
5. El destinatario abre el archivo en una aplicación compatible, que reconoce que el archivo ha sido firmado digitalmente.
6. A continuación, el ordenador del destinatario descifra la firma digital utilizando la clave pública del remitente.
7. Después, el ordenador del destinatario calcula el hash del archivo original y compara el hash que ha calculado con el hash, ahora descifrado, del archivo del remitente para confirmar que el archivo no ha sido alterado.

¿Qué medidas de seguridad ofrecen?

Las firmas digitales ofrecen tres garantías de seguridad fundamentales:

• Autenticación de la identidad del firmante,
• Integridad de los datos para confirmar que el documento no ha sido alterado
• No repudio, lo que significa que el firmante no puede negar posteriormente haber aprobado el documento

En conjunto, estas protecciones ayudan a las organizaciones a reducir el fraude, cumplir los requisitos de cumplimiento normativo y realizar transacciones digitales seguras con confianza.

¿Cómo pueden las organizaciones obtener un certificado de firma digital?

El proceso para crear una firma digital es fácil y sencillo, tanto para profesionales independientes como para empresas. En primer lugar, necesitas un certificado de firma digital, que puedes adquirir a través de una autoridad de certificación de confianza, como Sectigo. Una vez completado el proceso de compra y emisión, puedes descargar e instalar el certificado. A continuación, solo tienes que utilizar la función de firma digital de la plataforma o aplicación de documentos correspondiente.

Por ejemplo, la mayoría de las aplicaciones de correo electrónico disponen de un botón «Firmar digitalmente», mientras que los documentos de Microsoft Word pueden mostrar un botón de firma una vez que se ha añadido una línea de firma.

¿Cómo verifican los destinatarios un documento firmado digitalmente?

Al enviar un documento firmado con una clave privada, el destinatario obtiene la clave pública del firmante para verificar la firma digital. Una vez descifrado el documento, el destinatario puede ver el documento sin alteraciones, tal y como lo concibió el usuario. Si el destinatario no puede verificar el documento utilizando la clave pública, ello significa que el documento ha sido alterado, o incluso que la firma no pertenece al firmante original.

¿Por qué es fundamental proteger la clave privada?

La tecnología de la firma digital requiere que todas las partes implicadas confíen en que la persona que crea la firma ha sido capaz de mantener en secreto su propia clave privada. Si otra persona tiene acceso a la clave privada del firmante, dicha persona podría crear firmas digitales fraudulentas en nombre del titular de la clave privada.

¿Qué ocurre si se modifica un documento firmado?

Si el remitente o el destinatario alteran el archivo después de que haya sido firmado digitalmente, el valor hash del documento cambia. Cuando el sistema del destinatario compara el hash recién actualizado con el hash original firmado, cualquier discrepancia revela que el documento ha sido modificado. En este caso, la firma digital se marca como no válida, lo que alerta a los usuarios de una posible manipulación.

¿Qué aspecto tiene una firma digital?

Dado que el núcleo de una firma digital es el certificado PKI —que es código de software—, la firma digital en sí misma no es visible de forma inherente. Sin embargo, las plataformas de documentos pueden proporcionar una prueba fácilmente reconocible de que un documento ha sido firmado digitalmente. Esta representación y los detalles del certificado que se muestran varían según el tipo de documento y la plataforma de procesamiento. Por ejemplo, un PDF de Adobe muestra un indicador visual, como un icono de sello o una cinta azul en la parte superior del documento, en el que figuran el nombre del firmante y el emisor del certificado.

Además, puede aparecer en un documento de la misma forma que se estampan las firmas en un documento físico y puede incluir una imagen de tu firma manuscrita, la fecha, el lugar y el sello oficial.

Las firmas digitales también pueden ser invisibles, aunque el certificado digital siga siendo válido. Las firmas invisibles resultan útiles cuando el tipo de documento no suele mostrar la imagen de una firma física, como una fotografía. Las propiedades del documento pueden revelar información sobre el certificado digital, la autoridad de certificación emisora y una indicación de la autenticidad e integridad del documento.

Si una firma digital no es válida por cualquier motivo, los documentos muestran una advertencia indicando que no es fiable.

¿Por qué son importantes?

A medida que cada vez se realizan más operaciones en línea, los acuerdos y las transacciones que antes se firmaban en papel ahora se gestionan mediante flujos de trabajo totalmente digitales. Este cambio aumenta la necesidad de verificar la identidad y garantizar que los documentos no hayan sido alterados. Las firmas digitales proporcionan esa confianza al autenticar al firmante y proteger los documentos contra la manipulación o el fraude.

Además, permiten flujos de trabajo más rápidos y eficientes. Los documentos pueden firmarse de forma segura desde cualquier dispositivo, compartirse al instante y seguirse hasta su finalización mediante registros de auditoría claros. Dado que la firma está incrustada en el archivo, permanece intacta y verificable independientemente del lugar al que se envíe el documento.

Más allá de las grandes organizaciones, las firmas digitales son igualmente valiosas para profesionales independientes, consultores y pequeñas empresas que necesitan una forma sencilla y fiable de firmar contratos, acuerdos y documentos de clientes sin necesidad de una infraestructura compleja. Las soluciones diseñadas para particulares facilitan el establecimiento de credibilidad y el mantenimiento de flujos de trabajo seguros y conformes a la normativa.

Es fundamental que estos acuerdos firmados digitalmente sean reconocidos desde el punto de vista jurídico. Las firmas digitales garantizan el cumplimiento de normas importantes como la Ley Federal ESIGN de Estados Unidos, la GLBA, HIPAA/HITECH, la norma PCI DSS y el acuerdo «Safe Harbor» entre EE. UU. y la UE.

Casos de uso habituales de la firma digital

Hoy en día, las firmas digitales se utilizan habitualmente en una amplia gama de procesos empresariales para mejorar la seguridad, la integridad y la eficiencia de las transacciones críticas que ahora se gestionan de forma digital, entre las que se incluyen:

• Contratos y documentos legales: Las firmas digitales tienen validez legal. Por lo tanto, son ideales para cualquier documento legal que requiera una firma autenticada por una o más partes y la garantía de que el documento no ha sido modificado.
• Acuerdos de venta: Al firmar digitalmente contratos y acuerdos de venta, se autentican las identidades tanto del vendedor como del comprador, y ambas partes tienen la tranquilidad de que las firmas son legalmente vinculantes y de que los términos y condiciones del acuerdo no han sido alterados.
• Documentos financieros: Los departamentos financieros firman digitalmente las facturas para que los clientes confíen en que la solicitud de pago procede del vendedor legítimo, y no de un estafador que intente engañar al comprador para que envíe el pago a una cuenta fraudulenta.
• Datos sanitarios: En el sector sanitario, la privacidad de los datos es fundamental tanto para los historiales de los pacientes como para los datos de investigación. Las firmas digitales garantizan que esta información confidencial no haya sido alterada al compartirse entre las partes que han dado su consentimiento.
• Formularios administrativos: Los organismos públicos a nivel federal, estatal y local cuentan con directrices y normativas más estrictas en comparación con muchas empresas del sector privado. Desde la aprobación de permisos hasta el registro de la entrada en una hoja de asistencia, las firmas pueden optimizar la productividad al garantizar que el empleado adecuado participe en las aprobaciones correspondientes.
• Documentos de envío: Para los fabricantes, garantizar que los manifiestos de carga o los conocimientos de embarque sean siempre precisos ayuda a reducir los costosos errores de envío. Sin embargo, el papeleo físico resulta engorroso, no siempre es fácil acceder a él durante el transporte y puede perderse. Al firmar digitalmente los documentos de envío, los remitentes y los destinatarios pueden acceder rápidamente a un archivo, verificar que la firma está actualizada y confirmar que no se ha producido ninguna manipulación.

Protege tus documentos con Sectigo

Los certificados de firma de documentos de Sectigo verifican la identidad del firmante y confirman que un documento no ha sido alterado tras su firma. Cada firma queda vinculada criptográficamente al archivo, lo que permite a los destinatarios validar de forma independiente la autenticidad y la integridad.

Sectigo ofrece soluciones tanto para organizaciones como para particulares. Los certificados de firma de documentos dan respuesta a los casos de uso empresariales con una firma escalable y basada en políticas, mientras que Document Signing Professional está diseñado para profesionales independientes y pequeñas empresas que necesitan una forma sencilla y fiable de firmar documentos. En ambos casos, la identidad verificada se incrusta directamente en cada archivo, creando documentos a prueba de manipulaciones reconocidos por plataformas como Adobe Acrobat y Microsoft Office.

Obtenga más información sobre las soluciones de firma de documentos de Sectigo para proteger contratos, informes y otros documentos críticos para el negocio.

Echa un vistazo a tu bandeja de entrada y es posible que observes una serie de marcas de verificación azules, que aparecen junto a los nombres de los remitentes cada vez que abres un mensaje. Pasa el cursor por encima de la marca de verificación durante un momento y verás una nota importante: «El remitente de este correo electrónico ha verificado que es el propietario de [nombre del sitio web] y del logotipo que aparece en la imagen de perfil».

Esta marca de verificación es la apuesta de Google por una señal de confianza basada en la bandeja de entrada, impulsada por la tendencia generalizada a mostrar los logotipos de los remitentes directamente en las bandejas de entrada de correo electrónico. Está estrechamente vinculada a la especificación BIMI y puede garantizarse mediante la configuración de las políticas y marcos correspondientes: SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) y DMARC.

La marca de verificación en sí misma tiene valor y puede mejorar la confianza, pero gran parte de su valor reside en los mecanismos de seguridad que hacen posible dicha marca en primer lugar: el uso de múltiples capas de autenticación para demostrar la legitimidad del remitente. Esta iniciativa ayuda a proteger a los destinatarios contra la suplantación de identidad, respaldando el sistema global de confianza que protege las bandejas de entrada de correo electrónico actuales.

¿Qué se necesita para obtener la marca de verificación azul de Gmail?

Gmail solo mostrará una marca de verificación azul si se cumplen todos los requisitos de verificación de la marca: protocolos, marcos de trabajo, logotipos y certificados. Estos requisitos se combinan para confirmar la legitimidad de la marca y permitir la visualización del logotipo autenticado.

Los requisitos incluyen:

Los requisitos de BIMI deben estar configurados correctamente

BIMI es el núcleo de la actual apuesta por la confianza y la verificación en la bandeja de entrada. Esta especificación, ampliamente utilizada, determina cómo las organizaciones demuestran su identidad y autentican sus respectivos dominios.

Depende de que SPF, DKIM y DMARC funcionen correctamente. SPF identifica los servidores de envío autorizados, DKIM verifica que los mensajes no hayan sido alterados y DMARC indica a los proveedores de buzones de correo cómo gestionar los mensajes que no superan la autenticación.

Las medidas adoptadas para cumplir los requisitos de BIMI para Gmail también resultarán valiosas a la hora de trabajar con otros proveedores de correo electrónico.

Un logotipo SVG compatible con BIMI

El logotipo es una pieza fundamental del proceso de verificación. Debe cumplir unos estrictos requisitos de formato y tamaño: cada logotipo enviado debe ser un auténtico archivo vectorial, con un fondo liso. No debe contener scripts ni animaciones, y debe mostrarse con nitidez, incluso en tamaños reducidos.

Utiliza el formato SVG Tiny Portable/Secure, también conocido como SVG Tiny PS o SVG Tiny 1.2, y prepárate para realizar modificaciones manuales a fin de cumplir los requisitos de BIMI. El Grupo BIMI pone a disposición herramientas para facilitar el cumplimiento de estos requisitos.

Un certificado de marca verificada

Los certificados de marca ayudan a verificar que una marca está autorizada a utilizar un logotipo específico para su visualización en el correo electrónico mediante BIMI. Para obtener la marca de verificación azul de Gmail, se requiere un certificado de marca verificada (VMC). Un VMC verifica la autenticidad del logotipo y vincula el logotipo registrado como marca comercial a tu organización. Las directrices de Google Workspace confirman este requisito, señalando que: «En Gmail, verás una marca de verificación junto a los remitentes verificados con un VMC».

Las marcas que deseen adquirir un VMC deben estar preparadas para proporcionar datos de validación de la empresa, documentación sobre la marca registrada y archivos del logotipo que coincidan con la marca registrada.

Los certificados de marca comunes(CMC), aunque útiles para mostrar logotipos, no cumplen los requisitos para obtener la marca de verificación azul de Gmail. Si aún no cumples los requisitos para obtener un VMC porque careces de una marca registrada, un CMC sigue mereciendo la pena, pero no te proporcionará la marca de verificación azul.

Cómo obtener la marca de verificación azul de Gmail con BIMI

Para reforzar la confianza mediante la visualización del logotipo en la bandeja de entrada y la marca de verificación azul, tendrás que completar una serie de pasos de configuración técnica que incluyen la autenticación del correo electrónico, el formateo del logotipo, la validación del certificado y las actualizaciones del DNS.

Los pasos son los siguientes:

Paso 1: Configura SPF, DKIM y DMARC. Utiliza SPF para identificar los servidores autorizados a enviar correos electrónicos. Activa DKIM para aplicar firmas criptográficas verificables. Crea un par de claves DKIM y publica la clave pública como un registro DKIM en el DNS. Por último, configura DMARC con un registro TXT en los ajustes del DNS. La política debe establecerse en p=quarantine o p=reject, y pct=100 debe aplicar la política a todo el correo saliente.

Paso 2: Crea un logotipo SVG que cumpla con los requisitos. Elige una imagen de alta calidad de un logotipo registrado como marca y confirma que cumple todas las normas pertinentes: debe utilizar el formato Scalable Vector Graphics (SVG) y tener una relación de aspecto cuadrada. Confirma que el logotipo coincide con la marca registrada.

Paso 3: Obtén un certificado de marca verificada (VMC). Colabora con una autoridad de certificación para obtener un VMC. Al enviar la solicitud del VMC, proporciona una prueba de la titularidad de la marca registrada.

Paso 4: Publica tu registro DNS de BIMI. Inicia sesión con tu proveedor de dominio o DNS y añade un registro TXT de BIMI. En el caso de Gmail, el registro debe apuntar al archivo PEM emitido con su VMC. Un ejemplo compatible con Gmail podría ser: v=BIMI1;l=;a=https://yourdomain.com/certificate.pem. El archivo PEM debe estar alojado en un servidor web de acceso público a través de HTTPS.

Paso 5: Valida y prueba. Utiliza una herramienta de comprobación de BIMI para confirmar que el formato y la autenticación son correctos antes de enviar mensajes de prueba a los proveedores compatibles. Si el logotipo no aparece como se esperaba, revisa el registro DNS o el formato SVG para asegurarte de que los demás pasos se han completado correctamente. La visualización de BIMI varía según el proveedor de correo electrónico, por lo que los resultados pueden diferir en función de la bandeja de entrada.

Ventajas de la marca de verificación azul

La marca de verificación azul de Gmail se basa en la confianza y la visibilidad que aportan los logotipos verificados. Esto ofrece una garantía adicional, ya que confirma que los remitentes están totalmente verificados y que los mensajes proceden de fuentes legítimas.

• Confirmación visual rápida. Los destinatarios de los correos electrónicos toman decisiones en fracciones de segundo para poder gestionar sus bandejas de entrada abarrotadas. Una señal como la marca de verificación azul puede ayudar a los destinatarios a reconocer rápidamente a los remitentes verificados, especialmente si se observa junto a un logotipo verificado.
• Aspecto profesional. Las marcas de verificación transmiten profesionalidad, aportando un aspecto pulido a los correos electrónicos que refuerza la credibilidad existente. Juntos, los logotipos y las marcas de verificación establecen una presencia de marca segura y digna de confianza.
• Mayor confianza. Cuando los destinatarios de los correos electrónicos evalúan los mensajes, buscan las marcas de verificación como garantía. Aunque los logotipos ayudan, la doble verificación puede inspirar confianza incluso en los usuarios más escépticos.
• Mayor compromiso y aumento de las tasas de apertura. La confianza y la visibilidad pueden ayudar a los destinatarios a sentirse más seguros a la hora de abrir o interactuar con los correos electrónicos de la marca. Esto influye en que los destinatarios lean realmente los correos electrónicos e incluso puede animarlos a dar el paso: hacer clic en enlaces o rellenar formularios para fortalecer la relación con las marcas.

¿Por qué no aparece mi marca de verificación azul de Gmail?

Después de dedicar tiempo a configurar BIMI, puede resultar frustrante que no aparezcan las marcas de verificación azules. Esto podría indicar errores por tu parte, pero, incluso cuando se cumplen los requisitos técnicos, Gmail también puede tener en cuenta la reputación del remitente y otros factores de validación antes de mostrar un logotipo o una marca de verificación.

Entre las razones más comunes por las que no aparece se incluyen:

• No se aplica la política DMARC. Gmail solo muestra marcas de verificación cuando los dominios utilizan políticas de cuarentena o rechazo. Esto es fundamental, ya que permite a los proveedores saber qué hacer cuando los correos electrónicos no superan la verificación.
• El SPF o el DKIM fallan. El SPF puede fallar si se considera que el servidor de envío no está autorizado. El DKIM falla si los correos electrónicos han sido manipulados o si los registros DNS están mal configurados. Cualquiera de estos fallos impide que aparezca la marca de verificación azul.
• El logotipo SVG no cumple los requisitos. Los logotipos solo se pueden mostrar correctamente si cumplen con normas estrictas. La marca de verificación azul se basa en el logotipo, por lo que, si este no cumple las normas necesarias, la marca de verificación tampoco aparecerá.
• Falta el registro TXT de BIMI o es incorrecto. Gmail solo puede validar los logotipos si los registros BIMI tienen el formato adecuado. El registro TXT indica dónde se encuentra el logotipo verificado y, sin él, la validación no es posible.
• El archivo PEM no está alojado correctamente. Se proporciona un archivo PEM tras la emisión de un VMC, pero Gmail debe poder acceder a dicho archivo. La verificación no puede llevarse a cabo si el archivo PEM falta o está bloqueado de alguna forma.
• El logotipo no coincide con la marca registrada. Los logotipos mostrados deben coincidir con los logotipos de marcas registradas validados por los VMC, incluso en los colores y las proporciones.
• Los cambios en el DNS no se han propagado por completo. El DNS tarda un tiempo en llegar a los servidores. Si las actualizaciones aún no han llegado a los servidores que comprueba Gmail, es posible que no se reconozcan los intentos de autenticación recientes (o los cambios en BIMI).

Empieza a generar confianza en la bandeja de entrada con Sectigo

Sectigo ofrece certificados Verified Mark y Common Mark para ayudar a las organizaciones a habilitar la visualización del logotipo BIMI en Gmail y otros buzones participantes. Cualquiera de estos certificados puede mejorar la visibilidad en la bandeja de entrada.

Si tu objetivo es mostrar la marca de verificación azul de Gmail, empieza por adquirir un VMC de un proveedor de confianza, como Sectigo. Ponte en contacto con nosotros si tienes alguna pregunta o si deseas obtener más información sobre la seguridad del correo electrónico.

Fuentes:

https://bimigroup.org/creating-bimi-svg-logo-files/

https://knowledge.workspace.google.com/admin/security/set-up-bimi

¿Qué exige realmente la orden ejecutiva?

Las agencias deben:

1. Realizar la transición de todos los activos de alto valor y los sistemas de gran impacto para que utilicen la PQC en el establecimiento de claves antes del 31 de diciembre de 2030
2. Utilizar la PQC para las firmas digitales antes del 31 de diciembre de 2031

Hay dos aclaraciones importantes:

En primer lugar, estos plazos se aplican únicamente a los activos de alto valor y a los sistemas de gran impacto, y no a todos los sistemas federales. Los sistemas de seguridad nacional siguen una vía independiente bajo la autoridad de la NSA, con requisitos de información propios.

En segundo lugar, la orden no introduce ninguna nueva criptografía. Codifica las normas existentes del NIST:

• ML-KEM para el establecimiento de claves
• ML-DSA y SLH-DSA para las firmas digitales

Próximos pasos: medidas inmediatas

La orden establece un calendario de ejecución rápida:

• En un plazo de 30 días: las agencias deben nombrar a un responsable de la migración del PQC que dependa del director de sistemas de información (CIO)
• En un plazo de 90 días: la OMB debe exigir inventarios de los sistemas críticos y planes formales de migración

Para finales de 2027: el NIST completará una migración piloto que servirá de modelo.

Por qué la secuencia es más importante que las fechas

Los dos plazos están separados por un año, y la orden hace bien en diferenciarlos. El establecimiento de claves es prioritario en 2030, porque la amenaza a la confidencialidad es la que ya está en marcha.

El principio «recoger ahora, descifrar más tarde» (HNDL) convierte el establecimiento de claves en una cuestión urgente. Una clave de sesión protegida hoy mediante criptografía clásica protege datos que quizá deban permanecer secretos durante diez, veinte o treinta años. Si ese tráfico se está capturando y almacenando ahora, la migración ya llega tarde.

Las firmas digitales son diferentes. Una firma falsificada es un ataque en tiempo real. No se puede falsificar retroactivamente una actualización de software lanzada en 2026. Precisamente por eso las firmas pueden quedar en segundo lugar. La autenticación es un evento de firma y, además, un evento en tiempo real. El objetivo es secuenciar el trabajo de tal forma que se resuelva primero el problema que puede explotarse de forma retroactiva. Esa distinción es importante, porque la urgencia en este caso es real sin necesidad de exagerar lo que realmente se sabe sobre los plazos de la computación cuántica.

¿Por qué se ha adelantado la fecha límite de la PQC de 2035 a 2031?

Seamos claros. Este cambio no es señal de avances cuánticos repentinos. Por el contrario, refleja tres realidades:

• Las normas sobre PQC ya están definidas
• Los plazos de migración son largos y complejos
• Los datos sensibles ya superan los plazos de vida útil seguros de la criptografía

En otras palabras, la política no se ha acelerado; simplemente se ha puesto al día con las matemáticas.

Cómo empezar hoy mismo tu proceso de migración a la PQC

1. Elabora un inventario criptográfico; no puedes proteger lo que no ves
2. Identifica los sistemas que contienen datos sensibles de larga duración y priorízalos
3. Presiona a tus proveedores para que mejoren su agilidad criptográfica ya, y pídeles el equivalente a una lista de materiales criptográficos (CBOM)
4. Empieza por el establecimiento de claves, donde se concentra la mayor parte del riesgo de HNDL
5. Considera el año 2031 como un horizonte de planificación inmediato

Comienza hoy mismo tu camino hacia la PQC con una consulta gratuita: https://www.sectigo.com/es/quantum-labs

La mayoría de los flujos de trabajo de IA siguen un patrón familiar: consultar, analizar, recomendar. Eso funciona para la visibilidad. No resuelve la ejecución.

En las operaciones de certificados, la ejecución es el trabajo: emitir, renovar, revocar, aprobar. Cuando estas acciones se retrasan, surge un riesgo oculto y las organizaciones tienen que lidiar con certificados que no sabían que estaban caducando, lo que provoca interrupciones y problemas de cumplimiento.

Esto crea una desconexión en la que la IA puede identificar problemas, pero los humanos deben seguir moviéndose entre los sistemas para resolverlos, porque la información por sí sola no reduce el riesgo. Lo hace la ejecución.

Por qué la gobernanza se convierte en un obstáculo

La vacilación a la hora de cerrar esa brecha es válida. El acceso directo entre los agentes de IA y la infraestructura de certificados introduce riesgos como incoherencias en el acceso basado en roles, una débil separación de funciones y pistas de auditoría fragmentadas. Las empresas no deberían tener que elegir entre control y velocidad.

Lo que falta es un modelo en el que la IA opere dentro de los marcos de gobernanza existentes. No a su alrededor, ni en paralelo, sino dentro de ellos.

Esto requiere una capa de ejecución segura, que preserve los permisos, las aprobaciones y la auditabilidad, al tiempo que permite la acción.

Un enfoque gobernado para la ejecución de IA

El Servidor de Protocolo de Contexto de Modelo (MCP) de Sectigo para Sectigo Certificate Manager (SCM) introduce esa capa de ejecución, y lo hace como el primer Servidor MCP listo para producción, disponible globalmente para la gestión del ciclo de vida de certificados.

Nuestro servidor MCP actúa como una conexión segura y alojada entre los agentes de IA y SCM, permitiendo operaciones de certificados a través de lenguaje natural, sin pasar por alto la gobernanza. Para que quede claro, no se trata de un asistente de IA, un sustituto de SCM o una automatización sin límites.

En su lugar, MCP Server para SCM permite que las acciones impulsadas por la IA, como la identificación de certificados que caducan, el inicio de renovaciones o la revocación de certificados comprometidos, se ejecuten a través de las políticas, aprobaciones y controles de auditoría existentes de SCM.

Entre bastidores, el flujo de trabajo es sencillo y controlado:

• Los agentes de IA se conectan a través de MCP Server (mediante un token basado en permisos)
• Las solicitudes se ejecutan a través de las API de administración de SCM
• SCM sigue siendo el sistema de registro de permisos, aprobaciones y registros de auditoría.

El modelo de interacción evoluciona. El modelo de gobernanza no.

Diseñado para escalar sin complejidad añadida

Este enfoque se ajusta a las necesidades actuales de los equipos de las empresas: a escala, sin añadir fricción:

• IA a su medida: Utilice los agentes de IA existentes, incluidos Copilot, Claude o cualquier agente compatible con MCP.
• Sin gastos de infraestructura: Sectigo aloja completamente el servidor MCP
• La gobernanza permanece intacta: Se conservan el acceso basado en roles, los flujos de trabajo de aprobación y los registros de auditoría.
• La ejecución sustituye a la observación: La IA pasa de una visión de sólo lectura a una acción controlada en todas las operaciones de certificación.

Así es la automatización orquestada en la práctica: Ejecución impulsada por IA dentro de los controles definidos, no fuera de ellos.

Del conocimiento a la ejecución orquestada

Las empresas no necesitan más herramientas. Necesitan IA que funcione dentro de los sistemas en los que ya confían.

MCP Server para SCM marca un cambio de la experimentación desconectada a la ejecución controlada, donde la IA puede actuar, no sólo informar, y hacerlo sin comprometer el control.

Esto es sólo el principio. A medida que los ecosistemas de certificados sigan evolucionando, también lo harán las formas en que la IA se integra con ellos, ampliándose al ritmo de las necesidades de la empresa.

La siguiente fase de la gestión del ciclo de vida de los certificados no consiste en añadir inteligencia. Se trata de hacerla operativa de forma segura, predecible y a escala.

El sector TLS está experimentando una de sus transiciones operativas más importantes en años. Los mandatos de CA/Foro de Navegadores están comprimiendo los periodos de validez de los certificados y endureciendo las ventanas de reutilización de la validación de control de dominio (DCV). Para las organizaciones que gestionan certificados a gran escala, esto supone una gran preocupación para el futuro próximo.

El paso a ciclos de vida de los certificados de 47 días cambiará fundamentalmente la forma en que los equipos piensan sobre la renovación y la validación. Lo que solía ser una tarea anual se convertirá en un flujo de trabajo operativo continuo. Las organizaciones que dependen de actualizaciones manuales de DNS y procesos de renovación ad hoc se enfrentarán a una presión cada vez mayor a medida que estos cambios entren en vigor.

La presión se deja sentir de forma desigual. Las empresas que gestionan grandes conjuntos de certificados, certificados SAN complejos y dominios comodín son las primeras en sentirlo. Pero la realidad operativa es clara en todos los ámbitos: la gestión manual de certificados no se adaptará a las demandas de ciclos de vida más cortos.

Sectigo está ayudando a los clientes a adelantarse a este reto. A través del soporte para Persistent DCV en Sectigo Certificate Manager (SCM), combinado con un conjunto significativamente ampliado de integraciones de conectores DNS, los equipos pueden empezar a crear los flujos de trabajo listos para la automatización que necesitan antes de que estos cambios sean obligatorios.

¿Qué cambia? Comprender el nuevo calendario

El Foro CA/Browser ha establecido una trayectoria clara: Las pruebas DCV caducarán con más frecuencia y los certificados deberán renovarse en ciclos mucho más cortos. Para los equipos que actualmente dependen de actualizaciones ocasionales de DNS vinculadas a renovaciones anuales, la matemática operativa ya no cuadra.

El efecto acumulativo: los equipos que hoy gestionan las renovaciones manualmente se enfrentarán a las mismas tareas con una frecuencia entre cinco y ocho veces mayor. La coordinación de DNS, las aprobaciones de gestión de cambios y la validación por renovación se acumularán rápidamente, lo que supondrá un lastre operativo y un riesgo real de interrupción del servicio.

¿Qué es la DCV persistente?

La DCV persistente es un nuevo enfoque de la validación de dominios basada en DNS que elimina la necesidad de crear y actualizar repetidamente registros TXT de DNS en cada ciclo de renovación. En lugar de aprovisionar un registro temporal para cada evento de validación, una organización publica un único registro TXT persistente una vez. A continuación, la CA realiza comprobaciones de validación recurrentes contra ese registro de forma automática, sin requerir más intervención del DNS. A continuación se detallan las diferencias paso a paso:

DCV tradicional:

1. Instale el conector DNS en su entorno
2. Solicitar certificado
3. Añadir registro TXT temporal
4. Validar
5. Eliminar/actualizar registro
6. Repetir de nuevo en 100 o 47 días

DCV persistente:

1. Publicar registro TXT persistente una vez
2. La CA realiza comprobaciones de validación recurrentes automáticamente
3. Renovar certificados continuamente sin cambios repetidos de DNS

Por qué el Foro CA/Browser introdujo la DCV persistente

El método de validación de DNS TXT persistente se introdujo a través de SC088, una votación del Foro de CA/navegadores patrocinada por Sectigo. La votación surgió de la opinión directa de los clientes: a medida que aumentaba la frecuencia de renovación de certificados, la carga operativa de las repetidas actualizaciones de DCV se estaba volviendo insostenible para los equipos empresariales.

El patrocinio de Sectigo de SC088 refleja un compromiso más amplio para dar forma a estándares que equilibren fuertes garantías de seguridad con practicidad operativa. La DCV persistente no reduce el rigor de la verificación de la propiedad del dominio. Cambia cuándo y cómo se realiza esa verificación, pasando de comprobaciones basadas en eventos a una validación continua y automatizada.

El Foro CA/Browser reconoció que la reducción de la vida útil de los certificados requiere un modelo de automatización escalable. La DCV persistente es la respuesta del sector a este requisito en la capa de validación.

Por qué la DCV persistente es importante para los equipos empresariales

El contexto empresarial es importante en este caso. Las grandes organizaciones no gestionan un puñado de certificados. Gestionan miles, a menudo en entornos que pertenecen a diferentes equipos, que utilizan diferentes proveedores de DNS y que se rigen por políticas de gestión de cambios que introducen tiempo de espera en cada actualización.

Entre los retos habituales a los que se enfrentan los equipos hoy en día se incluyen

• Grandes conjuntos de certificados que abarcan varios entornos
• Certificados SAN que agregan múltiples dominios que requieren una validación coordinada
• Complejidad de los certificados Wildcard y mayor escrutinio en ciclos de vida más cortos.
• Propiedad de DNS dividida entre equipos de infraestructura, redes y plataformas
• Procesos de gestión de cambios que añaden días o semanas a las actualizaciones de DNS.
• Riesgo de interrupción cuando los registros DCV caducan antes de que se completen las renovaciones.

Persistent DCV aborda directamente cada uno de estos puntos débiles:

• Reducción de la sobrecarga operativa: Elimina el ciclo recurrente de actualización de DNS para los dominios establecidos.
• Menor riesgo de interrupción: Elimina la posibilidad de que los registros DCV caducados provoquen renovaciones fallidas.
• Mejor escalabilidad: Admite la automatización de certificados de gran volumen sin trabajo de DNS proporcional
• Mayor preparación para la automatización: Alinea la validación de dominios con ciclos de certificados de 47 días y más cortos.
• Cumplimiento simplificado: Facilita el mantenimiento y la demostración de la preparación para la validación continua.

Enfoque de Sectigo: DCV persistente y conectores DNS en SCM

Sectigo Certificate Manager ahora soporta registros Persistent DNS TXT para la automatización continua de DCV y una biblioteca significativamente expandida de integraciones de conectores DNS. Juntas, estas capacidades abordan las dos capas principales del desafío de validación de DNS: qué método se utiliza y cómo se ejecutan los cambios de DNS.

DCV persistente en SCM

La compatibilidad de SCM con DCV persistente permite a los equipos:

• Publicar registros TXT persist entes para los dominios gestionados
• Permitir la validación recurrente automatizada sin cambios de DNS adicionales
• Reducir la dependencia de la coordinación manual de DNS en el momento de la renovación
• Alinear los flujos de trabajo de validación con los requisitos operativos de ciclos de vida de certificados más cortos.

Esto es parte del enfoque más amplio de Sectigo Scalable DCV: tratar la validación de dominios como un sistema coordinado y automatizado en lugar de una tarea puntual en cada evento de renovación.

Soporte ampliado de conectores DNS

Para situaciones en las que todavía se requieren cambios de DNS (incluida la configuración inicial de registros persistentes o la gestión de nuevos dominios), los conectores de DNS de SCM automatizan la ejecución de dichos cambios directamente desde la plataforma.

Los conectores DNS de SCM se conectan directamente a su proveedor de DNS y permiten a SCM crear y validar automáticamente desafíos de registros DNS TXT en su nombre. En lugar de requerir la coordinación manual entre los equipos de certificados y los administradores de DNS, el conector gestiona la interacción DNS de forma programática, eliminando los puntos de contacto humanos y los retrasos que conllevan.

Sectigo amplía frecuentemente el soporte del conector DNS para cubrir una amplia gama de proveedores, con la cobertura más actualizada listada aquí.

Esta amplitud de cobertura refleja un esfuerzo deliberado por llegar a las organizaciones dondequiera que se encuentre su infraestructura DNS, ya sea un importante proveedor en la nube, una plataforma DNS empresarial especializada o un entorno autoalojado. La capa de integración LEGO va más allá, haciendo que la automatización de DNS de SCM sea accesible a través de más de 100 proveedores de DNS mediante una única arquitectura de conectores.

Cómo funcionan juntas las dos capacidades

Persistent DCV y los conectores DNS son complementarios, no intercambiables. Persistent DCV reduce la dependencia de los cambios de DNS durante el ciclo de renovación. Los conectores DNS automatizan los cambios de DNS que siguen siendo necesarios, incluida la publicación del registro persistente inicial. Juntos, proporcionan a los equipos dos palancas para reducir el trabajo manual de DNS:

• Cuando se pueden utilizar registros persistentes, los puntos de contacto de DNS durante la renovación se eliminan por completo.
• Cuando los cambios de DNS siguen siendo necesarios, los conectores automatizan la ejecución sin coordinación manual.

El efecto neto es un flujo de trabajo de validación que se escala limpiamente a medida que aumentan los volúmenes de certificados y las frecuencias de renovación.

Qué deben hacer los clientes ahora

La ventana para prepararse está abierta, pero se está estrechando. Las organizaciones que inicien la transición ahora estarán mejor posicionadas cuando lleguen los plazos obligatorios. Pasos recomendados:

• Realice un inventario de su patrimonio de certificados: Identifique los certificados TLS públicos que caducan después del 15 de marzo de 2026 y evalúe qué dominios son candidatos para la DCV persistente.
• Revise los registros DCV existentes: Identifique los registros DCV persistentes o antiguos que estén a punto de caducar para evitar fallos en la renovación.
• Dar prioridad a los dominios SAN y comodín: Son los que conllevan una mayor sobrecarga de coordinación y los más sensibles desde el punto de vista operativo en plazos comprimidos.
• Publicar registros TXT persistentes: Comience ahora la transición de los dominios establecidos a DCV persistentes, antes de que el aumento de la frecuencia de renovación lo exija a escala.
• Adoptar ampliamente la automatización: Utilice los flujos de trabajo automatizados de validación recurrente de SCM y las funciones de automatización del ciclo de vida para reducir la intervención manual en todo el conjunto de certificados.

De cara al futuro: Preparación para los certificados de 47 días

La transición a los ciclos de vida de los certificados de 47 días requerirá un modelo operativo fundamentalmente diferente. Las organizaciones que superarán esta transición sin problemas serán las que ya hayan creado la infraestructura de automatización necesaria para ello, no las que luchen por ponerse al día cuando lleguen los plazos.

La DCV persistente es un paso significativo en esa dirección. Elimina una importante fuente de trabajo manual del ciclo de renovación, reduce una categoría común de riesgo de interrupción y alinea la validación de dominios con los ritmos operativos que exigen los ciclos de vida más cortos. Combinado con la biblioteca de conectores DNS ampliada de SCM, ofrece a los equipos una vía práctica para automatizar el último tramo de sus flujos de trabajo de certificados.

La gestión manual de certificados con frecuencias de renovación al ritmo de las máquinas no es una estrategia viable a largo plazo. Las organizaciones que inviertan ahora en una infraestructura de validación automatizada y repetible estarán mejor posicionadas para la realidad operativa que se avecina.

Empezar

La DCV persistente y la compatibilidad con conectores DNS ya están disponibles en Sectigo Certificate Manager. Para obtener más información o comenzar su transición

• Póngase en contacto con su representante de Sectigo para hablar sobre su estado de certificados y evaluación de preparación
• Explore la configuración de DCV persistente en SCM e identifique qué dominios transicionar primero
• Revise los conectores DNS disponibles en SCM en Integraciones > Conectores DNS para encontrar la integración adecuada para su entorno.
• Programe una evaluación de preparación para crear una hoja de ruta de automatización priorizada antes de que entren en vigor los mandatos de ciclos de vida más cortos.

Persistent DCV ayuda a las organizaciones a simplificar la validación de dominios mientras se preparan para la transición de la industria a ciclos de vida de certificados dramáticamente más cortos. Al reducir las actualizaciones repetitivas de DNS y permitir una preparación de validación continua, Sectigo Certificate Manager ayuda a las empresas a modernizar las operaciones de certificados antes de que estos cambios sean obligatorios.

Así que vamos a simplificarlo.

¿Qué es X9 PKI?

En esencia, X9 PKI es un marco de certificados específico del sector financiero desarrollado por el Comité de Normas Acreditadas (ASC X9) para respaldar la comunicación segura entre bancos, sistemas de pago e infraestructuras financieras de EE.UU..

A diferencia de WebPKI, el sistema global de autoridades de certificación (CA) como Sectigo en el que confían los principales navegadores actuales, como Chrome, Safari y Firefox, X9 opera fuera de los ecosistemas de confianza de los navegadores. Esta distinción es importante.

WebPKI está diseñado para la Internet pública, donde miles de millones de usuarios y dispositivos deben confiar en los certificados. X9, por el contrario, está diseñado para un ecosistema cerrado de participantes financieros en EE.UU. que acuerdan explícitamente confiar en un marco compartido.

Una forma más sencilla de verlo:

• WebPKI = confianza pública, distribuida globalmente
• X9 PKI = confianza privada, compartida en un ecosistema definido con sede en EE.UU.

¿Por qué se creó X9?

Las instituciones financieras llevan mucho tiempo enfrentándose a las políticas impulsadas por los navegadores y lideradas por el Foro CA/Browser en el modelo WebPKI. Estas políticas, como las vinculadas a una menor vida útil de los certificados o a la preparación cuántica, están diseñadas para proteger a todas las organizaciones y a todos los usuarios de Internet a escala, pero pueden perturbar los sistemas bancarios cotidianos, como los cajeros automáticos o las redes de pago, que funcionan de forma muy diferente.

X9 se creó en respuesta a esta tensión:

• Para dar más control a las instituciones financieras
• Proporcionar coherencia en los sistemas interconectados
• Reducir la dependencia de los proveedores de navegadores.

Desde este punto de vista, el objetivo de X9 tiene sentido.

Dónde tenemos que eliminar la confusión

Los departamentos de TI pueden tener la impresión de que X9 es una nueva forma de confianza "pública" o una evolución de WebPKI. Eso no es exacto.

X9 está fundamentalmente más cerca de un modelo PKI privado con una diferencia clave: En lugar de pertenecer y ser gestionado por una única organización o CA, es compartido por múltiples organizaciones bajo un marco de política común, lo que se denomina modelo de consorcio y es bastante común en PKI.

Esto crea un modelo híbrido:

• No tiene confianza distribuida globalmente como WebPKI.
• Pero tampoco ofrece un control total como una CA privada tradicional.

En otras palabras, los participantes deben optar por confiar en ella, como en cualquier CA privada. Más concretamente, deben instalar la raíz X9 propietaria en el almacén raíz de cada sistema cliente que intente conectarse a un certificado X9. Los sistemas operativos, navegadores o dispositivos no confían automáticamente en él.

Las desventajas de una CA privada compartida

Este enfoque de "ecosistema compartido" introduce importantes ventajas y desventajas que a menudo se pasan por alto.

En una configuración tradicional de PKI privada o CA privada:

• Una organización controla sus políticas, infraestructura y riesgos.
• Las decisiones de seguridad sólo afectan a esa organización.
• Como la propia organización es la autoridad de certificación, tiene pleno conocimiento y control sobre quién puede poseer uno de estos certificados.

En X9

• Las políticas se comparten entre múltiples participantes
• Las decisiones de seguridad y los riesgos pueden afectar a todo el ecosistema.
• Es mucho más difícil para los miembros de un consorcio comprender qué indica la propiedad de un certificado.

Esto es importante porque no todas las ventajas y desventajas en materia de seguridad son iguales. Por ejemplo, el sector de las infraestructuras de clave pública (PKI) en general ha ido evolucionando hacia una menor duración de los certificados, rotaciones más frecuentes de claves y raíces, mayor automatización y jerarquías de certificados creadas específicamente. Estos cambios existen por una razón: reducir el riesgo sistémico en grandes entornos de confianza.

X9 adopta intencionadamente un enfoque diferente, dando prioridad a la estabilidad y compatibilidad de los sistemas financieros. Pero cuando ese enfoque se aplica en un ecosistema compartido, el perfil de riesgo cambia.

En pocas palabras, en una PKI privada o en una configuración de CA privada, un cambio más lento puede ser aceptable. Pero en una instancia PKI compartida como X9, un cambio más lento afecta a todos los que confían en ella. Y mientras que muchos esquemas PKI de consorcio están limitados a miembros probados del consorcio que cumplen criterios específicos definidos, X9 está disponible para cualquier miembro del público. Esto significa que las organizaciones no pueden confiar en un certificado X9 como atestación de la identidad del suscriptor que lo posee.

¿Qué deben tener en cuenta las organizaciones a la hora de considerar X9 PKI?

X9 PKI no es intrínsecamente "buena" o "mala", pero a menudo se malinterpreta.

Es:

• Un modelo de confianza específico del sector diseñado para la interoperabilidad financiera
• Una CA privada compartida, no una infraestructura de confianza pública
• Un sistema que requiere participación explícita y decisiones de confianza

No es:

• Un sustituto de la WebPKI
• Un sistema de confianza distribuido globalmente
• Una forma de eludir las realidades de la evolución de las normas de seguridad
• Un indicador de la identidad del titular de un certificado X9

X9 se creó para resolver problemas reales en entornos financieros. Pero representa un modelo de confianza diferente con distintas compensaciones, no una evolución directa de la WebPKI pública existente.

A medida que la confianza digital se vuelve más compleja, impulsada por la menor vida útil de los certificados, el crecimiento de la identidad de las máquinas y los cambios criptográficos, esas compensaciones importan más que nunca.

Entender qué es realmente X9 constituye el primer paso para asegurarse de que está eligiendo el enfoque correcto. Entender dónde encaja, y dónde no, es lo que en última instancia ayuda a las organizaciones a tomar la decisión correcta.

¿Por qué este cambio y por qué ahora?

El entorno en el que operan nuestros clientes ha cambiado radicalmente:

• Vida útil de los certificados más corta
• Crecimiento explosivo de las identidades automáticas impulsadas por la IA
• Mayores exigencias normativas
• Aceleración de los plazos para la criptografía post-cuántica (PQC)

El resultado suele ser un riesgo oculto: más certificados, que caducan más a menudo, en más entornos. Todo ello fuera del alcance de los procesos manuales.

Esta complejidad repercute en el tiempo de actividad, el cumplimiento de normativas y la continuidad del negocio. Las herramientas aisladas y la automatización fragmentada simplemente no pueden seguir el ritmo.

Una forma más sencilla de ampliar la gestión del ciclo de vida de los certificados

Nuestra respuesta es clara: simplificar el funcionamiento de la confianza digital a escala.

No más herramientas superpuestas en complejidad. No más secuencias de comandos unidas.

En su lugar, un enfoque coordinado y basado en plataformas que unifica la visibilidad, el control y la automatización.

Estamos redefiniendo la gestión del ciclo de vida de los certificados (CLM) en torno a tres resultados:

• Control sin complejidad: visibilidad clara y gestión centralizada
• Obtención de valor más rápida: despliegue rápido de la automatización sin un gran esfuerzo.
• Confianza por diseño: gobernanza, fiabilidad y seguridad ancladas en una autoridad de certificación (CA) de confianza.

Juntos, permiten a los CISO, CIO y sus equipos recuperar el control en un entorno cada vez más complejo.

Redefinir la automatización con orquestación

Aquí es donde entra en juego nuestra plataforma. Hemos pasado años construyendo Sectigo Certificate Manager (SCM) exactamente para este momento, un CLM nativo en la nube que hace posible un enfoque fundamentalmente diferente de la gestión de certificados.

El núcleo es la automatización orquestada.

En lugar de tratar la gestión de certificados como una serie de tareas aisladas, la automatización orquestada coordina el ciclo de vida completo del certificado, aportando visibilidad, control y automatización en un único sistema coordinado. Esto permite a las organizaciones:

• Ver todo a través de sus entornos
• Actuar desde un punto de control centralizado
• Automatizar de principio a fin todo el ciclo de vida
• Adaptarse continuamente a medida que evolucionan los requisitos

Este cambio ya está tomando forma en SCM, incluyendo:

• Ciclo de vida del certificado centralizado y automatizado: emisión, validación, despliegue, renovación, sustitución y revocación, todo desde un único sistema, sin excepciones ni lagunas.
• Integración directa en flujos de trabajo impulsados por IA, lo que permite la interacción en lenguaje natural al tiempo que se mantiene la gobernanza y el control sin concesiones.
• Visibilidad ampliada de las CA públicas y privadas, lo que proporciona a las organizaciones una visión unificada de la confianza en entornos complejos.
• Reducción de la fricción en la validación de dominios, lo que ayuda a los equipos a mantener el ritmo a medida que se aceleran los ciclos de validación y se acorta la vida útil de los certificados.
• Preparación temprana para el cambio criptográfico, lo que permite a las organizaciones empezar a prepararse para el PQC dentro de los flujos de trabajo existentes.

Así es como la simplicidad a escala se hace realidad, convirtiendo la complejidad en claridad.

Sectigo está construido para el futuro de la confianza digital

CLM sigue siendo nuestra base, pero la categoría está evolucionando y nosotros también. Nuestra marca refleja una dirección muy clara para nuestros clientes y socios:

• Claridad sobre complejidad
• Resultados frente a actividad
• Confianza a largo plazo frente a soluciones a corto plazo

El ritmo del cambio no hará sino acelerarse. Los ciclos de vida de los certificados seguirán reduciéndose, los ecosistemas de identidad se ampliarán y surgirán nuevos estándares criptográficos. Nuestro papel es simple: ayudar a las organizaciones a mantenerse a la vanguardia sin añadir cargas.

Este próximo capítulo para Sectigo consiste en cumplir con esa responsabilidad con mayor enfoque, claridad y liderazgo para que nuestros clientes y socios puedan operar con confianza.

Le invitamos a explorar más sobre nuestra nueva marca en https://www.sectigobrandlaunch.com/.