KeyTalk Preguntas Frecuentes (FAQ)

Sí, KeyTalk puede manejar múltiples CAs. Tanto CAs privadas, como Microsoft Active Directory Certificate Server, como CAs públicas, como GMO GlobalSign o DigiCert QuoVadis.

Sí, KeyTalk desarrolla funcionalidades e integraciones basadas en la demanda del cliente y el caso de negocio. Cuando una integración requerida aún no está soportada y es técnicamente factible, puede lograr una integración exitosa junto con la Unidad de Negocios de KeyTalk. Esta integración se incorporará íntegramente en nuestro software y será mantenida.

Sí, KeyTalk puede generar claves privadas con suficiente entropía, como parte de las Solicitudes de Firma de Certificado (CSR) generadas centralmente. Estos pares de claves asimétricas pueden almacenarse en su propia base de datos de gestión cifrada con AES256 o en un Módulo de Seguridad de Hardware (HSM) vinculado. Cuando un par de claves expira o se vuelve inválido, la plataforma KeyTalk regenerará este par y el certificado asociado, ya sea automáticamente o semi-automáticamente mediante un proceso de flujo de trabajo.

Nuestra definición de certificados X.509 de corta duración: certificados que no duran más que el tiempo que tarda una Lista de Revocación de Certificados (CRL) actual en ser actualizada y distribuida desde el momento en que se emiten. ¿Normalmente trabaja con CRLs que se actualizan una vez al día? Entonces, los certificados de corta duración son válidos 24 horas menos. Los protocolos OCSP teóricamente son mucho más rápidos que las CRLs para actualizarse, pero en la práctica generalmente tardan más que el tiempo promedio para actualizar una CRL en establecer la necesidad de incluir un certificado en un OCSP y su inclusión real. Esto significa que los OCSP generalmente no son más prácticos que una CRL en cuanto a certificados X.509 de corta duración.

KeyTalk puede asignar cualquier tiempo de vida a un certificado emitido, siempre que la Autoridad de Certificación destino lo soporte. La validez más corta que KeyTalk puede asignar a un certificado es de 1 segundo.

Una identidad digital válida se prueba mediante un certificado X.509, a través de varios factores:

• La validez: ¿Está el certificado en una lista de revocación como CRL u OCSP? ¿No ha expirado el certificado en términos de fecha/hora máxima?
• ¿La cadena CA es de confianza para el ordenador que desea validar la identidad digital? Esto requiere que la CA raíz emisora sea confiable, y que las CAs intermedias puedan ser validadas o sean conocidas y confiables en el equipo que valida la identidad.
• ¿El nombre de la identidad digital aparece no solo en el Common Name (CN) del certificado, sino también en el Subject Alternative Name (SAN)?
• ¿La identidad que se valida puede ser usada para autenticación de cliente, servidor o ambos?
• ¿El nombre de la identidad que se valida es validado y corresponde a una entrada en el DNS? ¿O coincide con la dirección de correo electrónico que se está accediendo?
• ¿La identidad digital que se valida tiene el certificado público X.509 y la clave privada correspondiente?

El sistema KeyTalk maneja todos estos factores para la emisión y gestión de certificados. Esto nos permite probar la identidad de una persona, dispositivo móvil, computadora, servidor, dispositivo de red y/o dispositivo Internet de las Cosas (IoT).

No, las aplicaciones comunes de servidor como IIS, Apache, TomCat, NGINX no requieren reinicio si el certificado SSL es reemplazado por el cliente/app KeyTalk. En pocas palabras, los servidores no se caerán con estas aplicaciones y no interferirán con el servicio.

No, no es obligatorio. KeyTalk también puede manejar certificados cuya clave privada se genere en el sistema objetivo o en un HSM.

Sí, la solución KeyTalk puede gestionar TPMs, ya que pueden considerarse como una Tarjeta Inteligente Virtual (VSC). La mayoría de los TPMs se encuentran en sistemas Windows donde las VSCs se activan vía Microsoft u otros proveedores de software.

En este caso, el sistema KeyTalk enviará los metadatos de la Certificate Signing Request (CSR) al cliente/app KeyTalk, que a su vez transferirá estos datos a la TPM/VSC.

La CSR se genera y pasa vía cliente/app KeyTalk al servidor KeyTalk, dejando la clave privada de forma segura en la TPM.

El servidor KeyTalk envía el certificado X.509 firmado de vuelta al cliente/app KeyTalk, que a su vez emite el certificado a la VSC.

Sí, la plataforma KeyTalk puede emitir certificados y claves privadas asociadas de un (Q)TCSP conectado. Cuando cambias a otro (Q)TCSP, conectas este nuevo (Q)TCSP a la plataforma KeyTalk y todos los nuevos certificados se emiten directamente vía este nuevo (Q)TCSP.

Incluso puedes revocar todos los certificados emitidos bajo el antiguo (Q)TCSP de una vez, y dentro del tiempo de procesamiento de la CRL u OCSP, serán reemplazados automáticamente por certificados emitidos bajo el nuevo (Q)TCSP.

Sí, mediante el KeyTalk Smart Certificate Security Scanner. Puede escanear la red en todas las puertas para IP, rango IP y nombre(s) de dominio completamente calificado (FQDN) para identificar los certificados usados.

Si instalas la app proxy del KeyTalk Smart Certificate Security Scanner, puedes realizar un escaneo más profundo en cualquier servidor. De este modo, localizarás certificados que no necesariamente están ligados a un puerto TCP.

Sí, la plataforma KeyTalk puede publicar certificados S/MIME válidos emitidos por defecto tanto en Active Directory como en Azure Active Directory y en (Open)LDAP.

El certificado se almacena en los atributos habituales de AD/LDAP: UserCertificate y AltSecurityIdentities.

¿Desea usar un libro de direcciones LDAP empresarial S/MIME / servidor de llaves para fines públicos? Esto se suministra como un servidor virtual separado en la plataforma KeyTalk.

Sí. Aunque Microsoft dice que esto no es posible, esta configuración automática ha sido posible durante años vía el cliente/app KeyTalk. Sin más interacción humana y con los ajustes comunes SHA256 y AES256.

El cliente/app KeyTalk puede configurar automáticamente cualquier libro LDAP en Outlook para Windows, incluso si su libro LDAP utiliza configuraciones de búsqueda personalizadas.

Otros clientes de correo, asumiendo que soporten libros LDAP, pueden configurarse manualmente basándose en instrucciones claras.

Sí, todos los appliances virtuales KeyTalk de nuestra solución core pueden ejecutarse en HA. Para esto necesita un balanceador de carga. También puede configurar fácilmente HA siguiendo nuestro manual de administración paso a paso.

Sí, la plataforma KeyTalk soporta SNI. En el cliente/app KeyTalk para cada sitio alojado en el servidor, se establece el enlace de plantilla de certificado deseado, autenticación y la IP requerida para el binding, después de lo cual KeyTalk gestionará automáticamente cada certificado SNI/SSL.

KeyTalk soporta el llamado “reciclaje de certificado y clave privada”.

En resumen, esto significa que KeyTalk puede volver a emitir un certificado y clave al dispositivo de un usuario final, siempre que la autenticación sea positiva. La condición es que la clave privada se pueda recuperar de algún lugar (HSM, base de datos cifrada propia de KeyTalk, otro sistema de gestión de claves).

Puede haber varias razones por las cuales S/MIME no funcione para un usuario final. Las más comunes son:

• S/MIME no está habilitado en el cliente de correo. Este debe configurarse para usar certificados S/MIME para la firma digital y/o cifrado de correos. Verifique que la configuración sea correcta.
• En el destinatario del correo cifrado no se conoce un certificado S/MIME válido y confiable. La mayoría de los clientes usan Active Directory o Azure Active Directory como libreta de direcciones donde se publican certificados públicos S/MIME. Si un certificado válido no está en el AD o no está en la libreta local, no se podrá enviar correo cifrado (pero sí firmado digitalmente).
• Como opción adicional, algunos clientes pueden configurar un “servidor de llaves LDAP” o “libreta S/MIME LDAP” para almacenar y buscar certificados S/MIME asociados a direcciones conocidas. KeyTalk provee esta libreta LDAP como parte de la solución.
• Para firmar digitalmente, usualmente se debe configurar un algoritmo de hash en el cliente mail. SHA1 era estándar pero no se confía en él desde 2007. Use algoritmos modernos como SHA256 para evitar errores.
• Para cifrar, se debe configurar un algoritmo moderno como AES256.
• ¿S/MIME funciona en cliente de escritorio/laptop pero no en iOS o Android con Exchange Online u Outlook Web Access (OWA)? Se requieren configuraciones adicionales:
  I) https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/outlook-for-ios-and-android/sensitive-labeling-and-protection-outlook-for-ios-android
  II) https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/s-mime-for-message-signing-and-encryption

La respuesta es bastante técnica. KeyTalk ha puesto a disposición un documento que sirve como guía para configurar Exchange Online. El documento se llama: “Anything You Ever Wanted To Know About SMIME Email Encryption and Digital Signing Configurations, But Were Afraid To Ask“.