KeyTalk Preguntas Frecuentes (FAQ)
¿Puede KeyTalk gestionar certificados de varias autoridades de certificación (CA)?
Sí, KeyTalk admite varias CA: privadas, como Microsoft Active Directory Certificate Server, y públicas, como GMO GlobalSign o DigiCert QuoVadis.
Quiero usar una autoridad de certificación, pero KeyTalk no parece ser compatible. ¿Es posible?
¿Puede KeyTalk gestionar claves criptográficas públicas/privadas asimétricas?
¿KeyTalk admite certificados X.509 de corta duración?
Nuestra definición de certificados X.509 de corta duración: certificados cuya duración no supera el tiempo que tarda en actualizarse y distribuirse una Lista de Revocación de Certificados (CRL) desde su emisión. ¿Suele trabajar con CRL que se actualizan una vez al día? En ese caso, los certificados de corta duración tienen una validez de 24 horas menos. Los radiadores del Protocolo de Estado de Certificados en Línea (OCSP) se actualizan, en teoría, mucho más rápido que las CRL, pero en la práctica, suele tardar más que el tiempo promedio en actualizar una CRL para determinar la necesidad de incluir un certificado en un OCSP, incluso hasta su inclusión. Esto significa que los OCSP no suelen ser más prácticos que una CRL cuando se trata de certificados X.509 de corta duración.
KeyTalk puede asignar cualquier duración a un certificado que se va a emitir, siempre que la autoridad de certificación de destino lo admita. La validez mínima que KeyTalk puede asignar a un certificado es de 1 segundo.
¿Los certificados emitidos a través del sistema de gestión de certificados KeyTalk prueban la identidad digital de una persona o máquina?
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).
Si un certificado (y clave privada) emitido por KeyTalk es instalado por el cliente/app de KeyTalk, ¿mi servidor necesita reiniciarse?
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.
¿La plataforma KeyTalk siempre tiene que crear y gestionar la clave privada?
No, no es obligatorio. KeyTalk también puede manejar certificados cuya clave privada se genere en el sistema objetivo o en un HSM.
¿La solución KeyTalk funciona con un Trusted Platform Module (TPM) disponible para generar/guardar una clave privada?
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.
¿Puede KeyTalk (Qualified) (Trusted) Certificate Service Provider ((Q)TCSP) operar de forma independiente?
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.
¿Puede KeyTalk ubicar los certificados en mi red?
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.
¿Puede la plataforma KeyTalk publicar mis certificados válidos de cifrado de correo electrónico y firma digital (S/MIME)?
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.
La encriptación de correo S/MIME y los certificados para firma digital deben configurarse en Outlook para Windows. ¿KeyTalk puede soportar esto?
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.
Si se publica un certificado S/MIME para cifrado de correo y firma digital en un libro de direcciones LDAP público, ¿cómo se puede usar con clientes de correo comunes?
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.
¿Puedo ejecutar la plataforma KeyTalk con alta disponibilidad (HA) / redundante?
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.
Mi servidor está corriendo Server Name Indication (SNI). ¿Esto es soportado por KeyTalk en términos de gestión de certificados y despliegue/instalación automática?
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.
Mis usuarios tienen múltiples dispositivos para leer correos. ¿Cómo asegura KeyTalk que se use el mismo certificado válido S/MIME y clave privada en todos estos dispositivos?
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).
KeyTalk emite certificados S/MIME válidos a mis usuarios finales, pero S/MIME no funciona en mi entorno. ¿Por qué?
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:
¿Cómo configuro Office 365 Exchange Online para confiar y habilitar la encriptación y firma digital S/MIME?
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
