¿Qué son los certificados digitales? Una guía completa sobre los tipos de certificados, los formatos y la confianza

Cada vez que accedes a una página HTTPS, inicias sesión en un servidor a través de SSH, envías un correo electrónico cifrado o conectas un dispositivo a una red, un certificado digital está funcionando discretamente en segundo plano. Estas credenciales son la base de la comunicación segura tanto en Internet como en los entornos empresariales. Vinculan una identidad verificada a una clave criptográfica, de modo que los sistemas puedan confiar entre sí sin haberse conocido previamente.

Esa función, antes discreta, se ha convertido en un importante motivo de preocupación operativa. Las organizaciones gestionan ahora más máquinas, servicios y dispositivos que nunca, y el volumen de certificados en producción ha crecido al mismo ritmo. Al mismo tiempo, está previsto que la vigencia máxima de un certificado de confianza pública se reduzca a tan solo 47 días a partir de marzo de 2029, lo que acorta los plazos de renovación y hace que el seguimiento manual resulte insostenible.

Esta guía explica qué es un certificado, cuáles son las principales familias de formatos con las que te encontrarás, cómo se establece la confianza a través de las autoridades de certificación y las cadenas de certificación, y cómo se invalidan los certificados antes de que caduquen. Al finalizar, comprenderás no solo los mecanismos, sino también por qué la gestión de certificados se ha convertido en un pilar fundamental de la confianza digital.

¿Qué es un certificado digital?

Un certificado digital es un archivo que vincula una identidad verificada —como un nombre de dominio, una organización, una persona o un dispositivo— a un par de claves criptográficas. Esa vinculación permite que dos sistemas se autentiquen mutuamente y cifren los datos en tránsito, incluso si nunca han interactuado anteriormente.

Una forma de imaginárselo es como un pasaporte digital. Un pasaporte contiene información sobre su titular y lo expide una autoridad de confianza que avala dicha información. Un certificado hace lo mismo para un equipo o un usuario: incluye datos de identidad y una clave pública, y está firmado por una autoridad en la que otros sistemas ya confían.

En el núcleo de cada certificado hay un par de claves. La clave pública está integrada en el certificado y se difunde abiertamente, mientras que la clave privada correspondiente permanece bajo el control seguro de la entidad a la que representa el certificado. Ese par asimétrico es lo que hace posible la verificación de la identidad.

Cómo funciona un certificado digital

En la práctica, un certificado sigue un proceso sencillo. Contiene una clave pública y datos de identidad. Una autoridad de confianza lo firma para confirmar que la identidad es legítima. Una parte que confía en él, como un navegador o una aplicación, comprueba esa firma antes de aceptar que la conexión es fiable.

El ejemplo más evidente es el protocolo de enlace « TLS », que protege el tráfico web. A grandes rasgos, funciona así:

1. Saludo del cliente:El cliente abre la conexión enviando la versión de « TLS » que admite y los conjuntos de cifrado, junto con un valor aleatorio conocido como «nonce».
2. Presentación del certificado:El servidor responde con su certificado firmado y una firma sobre el nonce, presentando así su identidad verificada.
3. Validación:El cliente verifica la firma del nonce con la clave pública del certificado y, a continuación, remonta la cadena de firmas del certificado hasta una raíz de confianza. De este modo, se confirma que el servidor es quien dice ser.
4. Intercambio de claves:Una vez confirmada la identidad, ambas partes acuerdan una clave simétrica compartida.
5. Canal seguro:Esa clave simétrica cifra el resto de la sesión, protegiendo los datos frente a posibles interceptaciones o manipulaciones.

La firma es lo que hace que todo el modelo funcione. Dado que cualquiera puede obtener una copia de un certificado público, comprobar que el nonce se ha firmado correctamente demuestra que la otra parte posee realmente la clave privada correspondiente. En la mayoría de las conexiones web, solo el servidor presenta un certificado, pero el protocolo de autenticación mutua « TLS » (mTLS) exige que ambas partes se autentiquen, un modelo cada vez más habitual en la seguridad de las API, las arquitecturas «zero-trust» y los sistemas industriales.

Otro ejemplo conocido es SSH, que garantiza la seguridad de la administración remota. A continuación se ofrece una descripción general del protocolo.

1. Saludo del cliente:El cliente abre la conexión, intercambiando mensajes de identificación de la versión del protocolo y una lista de los algoritmos compatibles para el intercambio de claves, la clave de host, el cifrado y el MAC.
2. Intercambio de claves:Ambas partes generan pares de claves efímeras e intercambian los valores públicos, obteniendo así un secreto compartido que ninguna de las partes transmite. Todo lo dicho hasta ahora se integra en un único hash de intercambio.
3. Autenticación del host:El servidor presenta su certificado o su clave pública sin cifrar, junto con una firma sobre el hash de ese intercambio, lo que demuestra que controla la clave privada del host correspondiente y vincula la identidad a este intercambio concreto.
4. Validación:El cliente comprueba la firma y, a continuación, comprueba si confía en la propia clave del servidor, ya sea porque dicha clave ya figura en su lista de servidores conocidos o porque la clave se incluye en un certificado firmado por una autoridad en la que el cliente confía. A partir de este momento, el canal queda cifrado.
5. Autenticación del usuario:Dentro del canal, ahora cifrado, el cliente demuestra quién es el usuario, normalmente firmando un desafío con una clave privada cuya parte pública ya ha sido aceptada por el servidor.

Cabe mencionar que, en el caso de SSH, los certificados son opcionales. El modelo sin certificados funciona bien a pequeña escala, donde cada cliente mantiene una lista de hosts conocidos y cada servidor mantiene una lista de claves autorizadas. Sin embargo, se vuelve complicado a medida que la flota crece, por dos razones. En primer lugar, el número de relaciones de confianza que hay que distribuir crece con el producto de usuarios por hosts, mientras que una autoridad de certificación lo reduce a una única clave de confianza en cada lado. En segundo lugar, las entradas de estos archivos no tienen fecha de caducidad, por lo que el acceso persiste hasta que alguien las elimina manualmente, mientras que los certificados caducan por sí solos. También existe una laguna que el modelo basado en archivos no puede subsanar: en la primera conexión a un host desconocido, el cliente no tiene nada con lo que validar la conexión y recurre a pedir al usuario que acepte una huella digital que rara vez se verifica.

¿Cuántos tipos de certificados digitales hay?

Existen tres tipos funcionales principales de certificados digitales:

• Los certificados de servidorprotegen los datos en tránsito a través de Internet y confirman que un sitio web es realmente lo que dice ser. Proporcionan la clave pública que sustenta la seguridad del protocolo y ayudan a prevenir la suplantación de dominios y los ataques de «hombre en medio».
• Los certificados de firma de códigoacreditan quién ha publicado un fragmento de software y confirman que el código no ha sido modificado desde que se firmó. Una marca de tiempo aplicada en el momento de la firma mantiene la validez de esta incluso después de que el propio certificado haya caducado, lo cual es importante para los software de larga duración.
• Los certificados de usuario o clientesirven para autenticar a personas o dispositivos. Funcionan como una alternativa mucho más segura que las contraseñas y se adaptan perfectamente a la autenticación de dos factores y a los sistemas de acceso «zero-trust».

Las tres se diferencian en su finalidad, pero comparten una característica común: la confianza. Cada una de ellas se basa en una identidad verificada y en un par de claves que una parte que confía en ellas puede comprobar.

Familias de formatos de certificados

No existe un formato de certificado único que se adapte a todas las aplicaciones. Los distintos protocolos requieren formatos diferentes, cada uno de ellos diseñado en función de las necesidades del sistema al que da servicio. El estándar X.509, por ejemplo, señala que SSH utiliza deliberadamente un tipo de certificado diferente porque el protocolo SSH tiene sus propios requisitos, y que PGP se basa en un modelo descentralizado en lugar de en autoridades centrales.

Hay cuatro familias que abarcan la mayor parte de lo que te encontrarás en la práctica: X.509, SSH, OpenPGP y los formatos JOSE basados en JSON. En las secciones siguientes se analizan uno por uno antes de compararlos entre sí.

Certificados X.509

X.509 es la base de la infraestructura de clave pública (PKI). Tiene su origen en el estándar de directorios X.500, fue introducido por la Unión Internacional de Telecomunicaciones y ha sido adoptado como estándar de Internet en el RFC 5280. Vincula una identidad verificada a un par de claves y define los campos exactos que hacen que un certificado sea interoperable entre sistemas. A continuación ofrecemos una breve descripción general de este formato. Para obtener más información al respecto, consulta nuestraguía completa sobre los certificados X.509.

Campos principales.
Cada certificado X.509 contiene un conjunto definido de datos, entre los que se incluyen un número de versión, un número de serie asignado por la autoridad certificadora emisora, un identificador del algoritmo de firma, el nombre del emisor, un período de validez y la información de la clave pública del sujeto. El período de validez viene determinado por dos marcas de tiempo —«no antes» y «no después»— que limitan el tiempo durante el cual se puede confiar en el certificado y reducen el daño que puede causar la filtración de una clave privada.

Extensiones de la versión 3.
La versión 3introdujo un marco de extensiones que amplió considerablemente la información que puede contener un certificado. Cada extensión tiene un identificador, un indicador de criticidad y un valor. Si un destinatario no reconoce una extensión marcada como crítica, debe rechazar el certificado. Entre las extensiones más comunes se incluyen las restricciones de uso de la clave, los nombres alternativos del sujeto (que permiten que un único certificado cubra varios dominios), las políticas de certificado y las restricciones básicas que distinguen los certificados de las autoridades de certificación (CA) de los certificados de las entidades finales.

Historial de versiones.
La versión 1 (1988) definió la estructura básica. La versión 2 (1993) añadió identificadores únicos para el emisor y el sujeto, que actualmente se consideran obsoletos. La versión 3 (a partir de 1996) incorporó el marco de extensiones, y prácticamente todos los certificados que se utilizan actualmente son de la versión 3.

Codificación: DER frente a PEM.
La norma define qué contiene un certificado, pero no cómo codificarlo para su almacenamiento o transporte. Hay dos formatos predominantes. DER (Distinguished Encoding Rules) es un formato binario compacto, que los navegadores, los sistemas operativos y las aplicaciones Java procesan de forma eficiente, y que suele utilizar las extensiones .der o .cer. PEM (Privacy Enhanced Mail) toma esos datos binarios y los convierte a texto Base64, reconocible por su encabezado «BEGIN CERTIFICATE», y es la opción habitual en sistemas Linux, servidores web y herramientas de línea de command como OpenSSL. Ambos contienen datos idénticos; la única diferencia es la representación, y la conversión entre ambos formatos es sencilla.

Casos de uso.
Los certificados X.509 garantizan la seguridad web a través de HTTPS, la seguridad del correo electrónico mediante S/MIME, la firma de código, la autenticación de dispositivos, la autenticación VPN y la autenticación mutua TLS para las API. También protegen la tecnología operativa, donde normas como OPC UA se basan en ellos y la norma IEC 62443 exige una seguridad basada en certificados a partir de un determinado nivel de garantía.

Certificados SSH

La autenticación mediante clave SSH simple obliga tanto al cliente como al servidor a almacenar y gestionar manualmente listas de claves de confianza, lo cual resulta difícil de escalar y es vulnerable a la suplantación de identidad durante el intercambio de claves. Los certificados SSH resuelven este problema vinculando una identidad a una clave y reduciendo el punto de confianza a una única autoridad de certificación (CA) capaz de autenticar tanto a los clientes como a los servidores.

SSH define dos tipos de certificados: los certificadosde usuariopara los clientes y los certificadosde hostpara los servidores. En lugar de los nombres distinguidos que utiliza X.509, los certificados SSH se basan enentidades, que vinculan un certificado a identidades específicas: nombres de usuario para los clientes y nombres de host para los servidores. Los certificados también pueden incluir opciones críticas que restringen su uso, entre ellas:

• force-command, lo que vincula el certificado a un único command , independientemente de lo que escriba el usuario.
• «dirección de origen»: una lista de direcciones desde las que se puede utilizar el certificado.
• «verify-required», que exige la verificación del usuario mediante FIDO, como un PIN o datos biométricos, para los tipos de llaves de seguridad.

SSH admite RSA de cualquier tamaño, los tipos de curva elíptica EC P256, P384 y P521, y ed25519. Cabe destacar que el algoritmo de firma no se selecciona por separado; en SSH viene definido por el tipo de clave. Y dado que SSH no define una jerarquía de CA, las CA de SSH suelen ser autofirmadas, basándose únicamente en la clave pública.

Certificados OpenPGP

Los certificados OpenPGP adoptan un enfoque fundamentalmente diferente en materia de confianza. En lugar de canalizar todas las decisiones a través de una autoridad central, OpenPGP utiliza una «red de confianza» descentralizada en la que cualquier usuario puede avalar la identidad de otro usuario firmando su clave. La confianza se acumula a partir de los avales de muchos pares, en lugar de proceder de una única raíz.

Este modelo refleja los orígenes de OpenPGP en el correo electrónico seguro y la firma de archivos entre individuos y comunidades, donde no existe ni se desea una autoridad central compartida. Su punto fuerte es la autonomía: ningún «guardián» decide quién puede participar. Su punto débil es la escala y la coherencia, ya que la confianza depende de lo bien conectada que esté una clave determinada dentro de la red y del cuidado con el que los participantes se verifiquen entre sí antes de firmar. Por ese motivo, la red de confianza tiende a funcionar mejor en comunidades muy unidas que en Internet abierto, que es donde el modelo jerárquico se ha impuesto.

Formatos JOSE (JWT, JWS, JWK)

La familia JOSE, abreviatura de «JSON Object Signing and Encryption» (Firma y cifrado de objetos JSON), aporta identidad e integridad a los sistemas basados en JSON, en lugar de a las estructuras binarias en las que se basa el estándar X.509. Merece la pena conocerla a modo de referencia, ya que aparece constantemente en el desarrollo web y de API moderno, aunque no sea un formato de certificado en el sentido tradicional.

• JWT (JSON Web Token)es un token compacto y compatible con URL que contiene información sobre un sujeto; se conoce sobre todo por los tokens de portador que se utilizan en la autenticación web y el inicio de sesión único.
• JWS (JSON Web Signature)define cómo firmar ese contenido JSON para que el destinatario pueda comprobar que no ha sido manipulado.
• JWK (JSON Web Key)representa una clave criptográfica como un objeto JSON, lo que facilita la distribución de claves para los servicios que ya utilizan JSON.

Mientras que el protocolo X.509 agrupa una identidad y una clave pública en un certificado firmado y validado a través de una cadena de CA, los formatos JOSE suelen transferir afirmaciones firmadas y claves entre servicios que ya comparten una relación de confianza, como un proveedor de identidad y las aplicaciones que dependen de él. Ambos suelen coexistir: una pasarela de API podría establecer una conexión TLS con un certificado X.509 y, a continuación, autorizar la solicitud mediante un JWT.

Comparación de las familias de formatos de un vistazo

Formato	Modelo de confianza	Uso habitual	Codificación
X.509	Autoridades de certificación jerárquicas	TLS, S/MIME, firma de código, autenticación de dispositivos y mTLS	DER (binario) o PEM (texto Base64)
SSH	Una única CA de SSH, normalmente autofirmada	Autenticación de cliente y servidor para el acceso remoto	Formato de certificado SSH, con clave RSA, EC o ed25519
OpenPGP	Red de confianza descentralizada	Firma y cifrado de correos electrónicos y archivos	Formato de los mensajes y las claves de OpenPGP
JOSE (JWT/JWS/JWK)	Confianza compartida entre servicios	Tokens web y de API, reclamaciones e intercambio de claves	Texto JSON

La línea divisoria más clara es el modelo de confianza. X.509 y SSH se basan en autoridades designadas, OpenPGP distribuye la confianza entre pares y JOSE da por hecho que ya existe una relación de confianza entre los servicios que intercambian tokens.

El modelo de confianza: cómo los certificados generan confianza

Detrás de cada formato se esconde una cuestión de confianza: ¿por qué debería una parte que confía en él creer en un certificado? Hay dos modelos que dan respuesta a esta pregunta.

Elmodelo jerárquicositúa a las autoridades de certificación en la cúspide. Un pequeño número de raíces que gozan de amplia confianza sirven de base al sistema, y todo lo demás deriva su confianza de ellas. Lared de confianza descentralizada, utilizada por OpenPGP, distribuye la confianza entre pares que responden unos por otros sin un punto de referencia central.

Ambas son válidas, pero se adaptan de forma diferente. El modelo jerárquico es el que sustenta el uso empresarial y de Internet, ya que las decisiones de confianza centralizadas y la validación automatizada son precisamente lo que necesitan los entornos grandes y dinámicos. La red de confianza, por el contrario, prospera en comunidades más pequeñas en las que los participantes pueden verificarse personalmente entre sí.

Cadenas de certificados y autoridades de certificación

La confianza jerárquica funciona mediante una cadena que el cliente puede recorrer desde el certificado que tiene ante sí hasta una raíz en la que ya confía. Una cadena típica tiene tres niveles:

1. Uncertificado de CA raíz autofirmado, preinstalado en los almacenes de confianza del navegador y del sistema operativo, cuya clave privada se conserva de forma segura fuera de línea.
2. Uncertificado de CA intermedio, que se encarga de la tarea diaria de firmar certificados para que la clave raíz permanezca protegida.
3. El certificado de entidad finalque presenta un sitio web, un servidor o un dispositivo.

Cuando un cliente recibe un certificado de entidad final, valida cada firma a lo largo de la cadena y solo acepta el certificado si todos los eslabones son válidos y se llega a una raíz de confianza. Los almacenes de confianza varían según el cliente. Firefox mantiene su propio almacén con unas 120 raíces de confianza para TLS, según laLista de certificados de CA incluidos de Mozilla, mientras que Chrome suele recurrir al almacén del sistema operativo, con excepciones como su lista independiente para la validación extendida y su requisito de transparencia de certificados. La confianza puede incluso extenderse entre organizaciones mediante la certificación cruzada, en la que dos raíces firman los certificados de la otra, de modo que los clientes que confían en una aceptarán los certificados emitidos bajo la otra.

Niveles de validación

Todo sistema de certificados, sea cual sea su formato, debe responder a la misma pregunta antes de emitir cualquier certificado: ¿qué grado de confianza tenemos en que el sujeto es quien dice ser? La respuesta nunca es binaria, por lo que cada familia desarrolla una forma de calificarla y de comunicar esa calificación a quien posteriormente vaya a confiar en el certificado. En TLS , se trata de la conocida escala de «Validación de dominio», que solo demuestra el control sobre un nombre; «Validación de organización», que verifica además que existe una entidad jurídica y que está vinculada a ese nombre; y «Validación ampliada», que añade registros de constitución, presencia física y confirmación de la autoridad de firma. La firma de código utiliza la misma lógica de niveles, habiendo eliminado su nivel más bajo, de modo que la identidad del editor ahora siempre está verificada a nivel de organización con claves almacenadas en hardware. Los certificados de cliente y S/MIME siguen el mismo patrón, desde el control del buzón de correo hasta la identidad individual verificada respaldada por documentos oficiales. En cada caso, el nivel se registra como un OID de política dentro del certificado, de modo que una parte que confía en él pueda leer el nivel de garantía en lugar de deducirlo.

Ese mismo instinto aparece siempre que se utilizan certificados, incluso en sistemas que no se parecen en nada al modelo de CA pública. PGP lo registra como un valor de confianza que el firmante asocia a cada firma, lo que permite a la parte que confía en ella sopesar varias certificaciones en lugar de basarse únicamente en una. SSH lo registra de forma implícita, en el proceso de aprovisionamiento que subyace a la CA: un certificado emitido solo después de que el host se haya inscrito en la gestión de la configuración, o después de que el usuario se haya autenticado ante un proveedor de identidad, ofrece exactamente el mismo nivel de garantía que proporcionan esas comprobaciones previas; por eso las CA de SSH pueden emitir certificados de forma segura en cuestión de horas. Lo que difiere entre las distintas familias es dónde se consigna el grado de confianza y en quién se confía para asignarlo. Lo que comparten es el reconocimiento de que un certificado solo es tan sólido como la verificación de identidad realizada antes de su firma, y que la solidez de esa verificación debe acompañar al certificado en lugar de dejarse a la especulación de la parte que confía en él.

Certificados autofirmados frente a certificados emitidos por una autoridad de certificación

Un certificado autofirmado está firmado por la misma entidad que lo ha creado. Aunque permite la autenticación, no ofrece ninguna verificación independiente de la identidad. La analogía con el pasaporte es acertada: escribir tu propio nombre en un trozo de papel y presentarlo en una frontera da como resultado un documento bonito, pero sin ninguna identidad contrastada que lo respalde. Los expertos describen los certificados autofirmados como no gestionados y no verificados, ya que nadie realiza un seguimiento de la fecha de caducidad que el creador ha establecido discretamente. Cuando esos certificados caducan, el resultado suele ser una interrupción del servicio, y los problemas con los certificados autofirmados son una causa habitual de las mismas.

Por ese motivo, los certificados autofirmados solo son adecuados en entornos controlados y que no sean de producción, como el desarrollo local, los laboratorios internos aislados y las demostraciones de prueba de concepto. Para la producción se requieren certificados emitidos por una CA, ya que proporcionan una cadena de confianza verificable que los navegadores y las aplicaciones validan automáticamente, respaldada por una autoridad que ha comprobado la identidad del titular y un ciclo de vida gestionado que realiza un seguimiento de la caducidad. Hay un matiz que conviene señalar: los certificados de la CA raíz son, en sí mismos, autofirmados, pero se trata de una propiedad estructural de un ancla de confianza, cuya fiabilidad se deriva de su distribución en los almacenes de confianza y no de la firma.

Revocación de certificados

Los certificados tienen una fecha de caducidad incorporada, pero la caducidad por sí sola no es suficiente. A veces es necesario invalidar un certificado mucho antes de su fecha de «no más tarde de», por ejemplo, cuando se produce una filtración de la clave privada, se retira un sistema del servicio o, simplemente, el certificado ya no es necesario. En el momento en que se detecta que la clave privada se ha visto comprometida, el certificado deja de ser válido, independientemente del tiempo de validez que le quede.

Es útil diferenciar dos conceptos.La caducidades el plazo de validez pasivo incorporado en cada certificado.La revocaciónes la medida activa de retirar la confianza antes de que finalice dicho plazo. La revocación es una etapa fundamental de la gestión del ciclo de vida de los certificados y el mecanismo de control que garantiza la integridad de la cadena de confianza cuando las condiciones del mundo real cambian más rápido de lo que permiten los plazos de validez.

Cómo funciona la comprobación de revocaciones (CRL y OCSP)

Las partes que confían en los certificados necesitan una forma de saber que un certificado ha sido revocado. Existen dos mecanismos principales.

Unalista de revocación de certificados (CRL)es un archivo firmado y con marca de tiempo publicado por una autoridad de certificación (CA) que recoge los números de serie de los certificados revocados antes de su vencimiento. Tal y como se define en el RFC 5280, cada entrada incluye el número de serie, la fecha de revocación y, opcionalmente, un código de motivo, como la compromisión de la clave o el cese de la actividad. Una parte que confía en el certificado localiza la lista a través de la extensión «Puntos de distribución de CRL» del certificado, la descarga y comprueba si el número de serie aparece en ella. Las CRL son sencillas y compatibles universalmente, pero pueden alcanzar un tamaño considerable, por lo que existen las CRL particionadas y las CRL delta para que las descargas sean manejables. En esta guía puedes profundizar enqué es una lista de revocación de certificados.

ElProtocolo de Estado de Certificados en Línea (OCSP), definido en el RFC 6960, invierte este modelo. En lugar de descargar una lista completa, el cliente solicita información sobre un único certificado consultando al servidor OCSP indicado en la extensión «Authority Information Access» del certificado. El servidor devuelve una breve respuesta firmada con los valores «válido», «revocado» o «desconocido». El «stapling» de OCSP mejora aún más este proceso al permitir que el servidor web recupere y almacene en caché la respuesta, para luego entregarla durante el protocolo de enlace de la capa de conexión ( TLS ), lo que reduce la latencia y protege la privacidad del usuario. Para conocer los detalles técnicos, consulta esta explicación sobrecómo funciona el OCSP.

Ambos enfoques suponen un equilibrio entre la actualidad y la eficiencia, y muchos equipos utilizan ambos. Si estás valorando por cuál decantarte, esta comparación entreCRL y OCSPte ayudará a tomar la decisión.Cabe destacar que, en la web pública, los navegadores están pasando a utilizar datos de revocación distribuidos localmente, mientras que OCSP y las CRL siguen siendo fundamentales para las PKI empresariales y privadas.

Revocación en todos los formatos

La revocación no es idéntica en todos los tipos de certificados. SSH, por ejemplo, utiliza listas de revocación de claves (KRL) en lugar de listas de revocación de certificados (CRL) al estilo X.509, y se basa en gran medida en certificados de corta duración, a veces incluso efímeros. Cuando un certificado tiene una vigencia de tan solo unas horas, el margen de tiempo en el que la revocación resulta relevante se reduce drásticamente, lo que, en primer lugar, disminuye la dependencia de la comprobación de la revocación. Este patrón, que privilegia las vigencias cortas frente a la invalidación activa, está cobrando cada vez más importancia en el ámbito general de los certificados, a medida que la vigencia pública se reduce hasta los 47 días.

Cómo Keyfactor ayudarte Keyfactor

Gestionar un certificado es fácil. Gestionar todos los certificados y formatos de una empresa, sin interrupciones ni lagunas en las políticas, es el verdadero reto, y ahí es donde la automatización se vuelve imprescindible. A medida que la vigencia se acorta hasta renovaciones cada 47 días, el volumen operativo de las renovaciones se multiplica por ocho aproximadamente, y las hojas de cálculo y los recordatorios por correo electrónico dejan de ser eficaces.

Keyfactor Aborda esta cuestión con un enfoque integral para la automatización del ciclo de vida de los certificados en los estándares X.509 y SSH. EJBCA, su plataforma PKI empresarial, emite y gestiona certificados a gran escala, es compatible con protocolos de inscripción estándar como SCEP, CMP, EST y ACME, y ofrece la «criptoagilidad» necesaria para la transición a la era poscuántica. Keyfactor Command Se integra con todas las CA del entorno para proporcionar funciones de detección, inventario, supervisión, renovación y revocación desde un único punto, junto con la supervisión de puntos finales CRL y OCSP, de modo que nunca pase desapercibida una lista caducada o un servidor de respuesta inaccesible. Para los equipos que prefieran no gestionar la infraestructura por sí mismos, «PKI as a Service» ofrece una infraestructura gestionada de PKI y revocación.

Los beneficios están directamente relacionados con los retos que se plantean en esta guía: menos interrupciones del servicio, una aplicación coherente de las políticas, la preparación para una vida útil más corta de los certificados y una ventaja inicial en materia de criptografía poscuántica.