KeyTalk Perguntas Frequentes (FAQ)
O KeyTalk pode manipular certificados de várias Autoridades de Certificação (CAs)?
Sim, o KeyTalk pode lidar com várias Autoridades Certificadoras (CAs). Tanto CAs privadas, como o Microsoft Active Directory Certificate Server, quanto CAs públicas, como a GMO GlobalSign, Digicert ou DigiCert QuoVadis e ainda este ano (no quarto trimestre) também com suporte para a Sectigo.
Quero usar uma Autoridade Certificadora, mas o KeyTalk parece não ter suporte para isso! Isso é possível?
O KeyTalk pode gerir chaves criptográficas públicas/privadas assimétricas?
O KeyTalk suporta certificados X. 509 de curta duração?
Nossa definição de certificados X.509 de curta duração: certificados que não duram mais do que o tempo necessário para uma Lista de Revogação de Certificados (CRL) atual ser atualizada e distribuída a partir do momento em que são emitidos. Normalmente, você trabalha com CRLs que são atualizadas uma vez por dia? Nesse caso, os certificados de curta duração são válidos por 24 horas a menos. Os protocolos de Status de Certificado Online (OCSP) teoricamente são muito mais rápidos do que as CRLs para atualizar, mas na prática, geralmente leva mais tempo do que o tempo médio para atualizar uma CRL para estabelecer a necessidade de incluir um certificado em um OCSP, até a inclusão efetiva de um certificado em um OCSP. Isso significa que os OCSPs geralmente não são mais práticos do que uma CRL quando se trata de certificados X.509 de curta duração.
O KeyTalk pode atribuir qualquer período de validade a um certificado a ser emitido, desde que a Autoridade Certificadora de destino o suporte. A validade mais curta que o KeyTalk pode atribuir a um certificado é de 1 segundo.
O KeyTalk pode atribuir qualquer tempo de validade a um certificado a emitir, desde que a Autoridade Certificadora de destino suporte esta opção. A validade mais curta que o KeyTalk pode atribuir a um certificado é de 1 segundo.
Os certificados emitidos pelo sistema de Gerenciamento de Certificados KeyTalk provam a identidade digital de uma pessoa ou máquina?
Uma identidade digital válida é comprovada por um certificado X.509, por vários fatores:
- A validade: O certificado está em um ponteiro de revogação como CRL ou OCSP? O certificado ainda não expirou em termos de data/hora máxima?
- A cadeia da CA é confiável pelo computador que quer validar a identidade digital? Isso requer que a CA raiz emissora seja confiável, e que as CAs intermediárias possam ser validadas ou sejam conhecidas e confiáveis no computador que quer validar a identidade digital.
- O nome da identidade digital aparece não só no Common Name (CN) do certificado, mas também no Subject Alternative Name (SAN)?
- A identidade que requer validação pode ser usada para autenticação de cliente, autenticação de servidor, ou ambos?
- O nome da identidade digital que requer validação é validado e corresponde a uma entrada de Domain Name Server (DNS)? Ou corresponde ao endereço de e-mail que está sendo acessado?
- A identidade digital que requer validação possui o certificado público X.509, bem como a chave privada correspondente?
O sistema KeyTalk lida com todos esses fatores de identidade digital para a emissão e gestão de certificados. Isso nos permite comprovar a identidade de uma pessoa, dispositivo móvel, computador, servidor, dispositivo de rede e/ou dispositivo Internet das Coisas (IoT).
Se um certificado (e chave privada) emitido pelo KeyTalk for instalado pelo cliente/app KeyTalk, meu servidor precisa ser reiniciado?
Não, aplicações comuns de servidor como IIS, Apache, TomCat, NGINX não requerem reinício de servidor se o certificado SSL for substituído pelo cliente/app KeyTalk. Simplificando, os servidores não ficam fora do ar com essas aplicações e, portanto, não interferem no serviço.
A plataforma KeyTalk sempre precisa criar e gerenciar a chave privada?
Não, não precisa. O KeyTalk também pode lidar com certificados cuja chave privada é gerada no sistema alvo ou em um HSM.
A solução KeyTalk funciona com um Trusted Platform Module (TPM) disponível para gerar/guardar uma chave privada?
Sim, a solução KeyTalk pode lidar com TPMs, pois eles podem ser considerados como um Virtual Smart Card (VSC). A maioria dos TPMs se encontra em sistemas Windows onde os VSCs são ativados via Microsoft ou outros fornecedores de software.
Neste caso, o sistema KeyTalk enviará os metadados da Certificate Signing Request (CSR) para o cliente/app KeyTalk, que por sua vez, transferirá esses dados para o TPM/VSC.
A CSR é então gerada e enviada via cliente/app KeyTalk para o servidor KeyTalk, deixando a chave privada seguramente no TPM.
O servidor KeyTalk envia o certificado X.509 assinado de volta para o cliente/app KeyTalk, que por sua vez, emite o certificado no VSC.
O KeyTalk (Qualified) (Trusted) Certificate Service Provider ((Q)TCSP) pode funcionar de forma independente?
Sim, a plataforma KeyTalk pode emitir certificados e chaves privadas associadas de um (Q)TCSP vinculado. Quando você alternar para outro (Q)TCSP, vinculará este novo (Q)TCSP à plataforma KeyTalk e todos os novos certificados serão emitidos diretamente via este novo (Q)TCSP.
Você pode até revogar todos os certificados emitidos sob o antigo (Q)TCSP de uma vez, e dentro do tempo de processamento da Certificate Revocation List (CRL) ou Online Certificate Status Protocol (OCSP), serão automaticamente substituídos por certificados emitidos sob o novo (Q)TCSP.
O KeyTalk pode localizar os certificados na minha rede?
Sim, via o KeyTalk Smart Certificate Security Scanner. Você pode fazer a rede ser escaneada em todas as portas para IP, faixa de IP e Fully Qualified Domain Name(s) para identificar os certificados usados.
Se você instalar o app proxy do KeyTalk Smart Certificate Security Scanner, também pode realizar uma varredura mais profunda em qualquer servidor. Assim, você localizará certificados que não estão necessariamente vinculados a uma porta TCP.
A plataforma KeyTalk pode publicar meus certificados válidos de criptografia de e-mail e assinatura digital (S/MIME)?
Sim, a plataforma KeyTalk pode publicar certificados S/MIME válidos emitidos por padrão tanto no Active Directory quanto no Azure Active Directory e (Open)LDAP.
O certificado é armazenado nos atributos comuns do AD/LDAP: UserCertificate e AltSecurityIdentities.
Deseja usar um livro de endereços LDAP empresarial S/MIME / servidor de chaves para fins públicos? Isso é fornecido como servidor virtual separado na plataforma KeyTalk.
A criptografia de e-mail S/MIME e os certificados para assinatura digital devem ser configurados no Outlook para Windows. O KeyTalk pode suportar isso?
Sim. Embora a Microsoft geralmente declare que isso não é possível, essa configuração automática tem sido possível por anos via cliente/app KeyTalk. Sem mais interação humana, com configurações comuns de SHA256 e AES256.
Se um certificado de criptografia e assinatura digital S/MIME for publicado em um livro de endereços LDAP público, como pode ser usado com clientes de e-mail comuns?
O cliente/app KeyTalk pode configurar automaticamente qualquer livro de endereços LDAP no Outlook para Windows, mesmo que seu livro LDAP use configurações de pesquisa personalizadas.
Outros clientes de e-mail, assumindo que suportem livros LDAP, podem ser configurados manualmente com base em instruções claras escritas.
Posso executar a plataforma KeyTalk em alta disponibilidade (HA) / redundante?
Sim, todos os appliances virtuais KeyTalk da nossa solução principal podem rodar em HA. Você precisa de um Load Balancer para isso. Também pode configurar facilmente HA seguindo nosso manual de administração passo a passo.
Meu servidor está rodando Server Name Indication (SNI). Isso é suportado pelo KeyTalk em termos de gerenciamento de certificados e implantação/instalação automática?
Sim, a plataforma KeyTalk suporta SNI. No cliente/app KeyTalk para cada site hospedado no servidor, você configura o link do template de certificado desejado, autenticação e IP necessário para ligação (bind), após o qual a plataforma KeyTalk gerenciará automaticamente cada certificado SNI/SSL.
Meus usuários têm múltiplos dispositivos para ler e-mails. Como o KeyTalk garante o uso do mesmo certificado válido S/MIME e chave privada em todos esses dispositivos?
O KeyTalk suporta a chamada “troca (roll-over) de certificado e chave privada”.
Simplificando, isso significa que o KeyTalk pode reemitir um certificado e chave para o dispositivo de um usuário final, desde que a autenticação seja positiva. A condição é que a chave privada possa ser recuperada em algum lugar (HSM, própria base de dados criptografada do KeyTalk, outro sistema de gerenciamento de chaves).
KeyTalk emite certificados S/MIME válidos para meus usuários finais, mas o S/MIME não funciona em minha área. Por quê?
Podem haver várias razões pelas quais o S/MIME não funciona para um usuário final. Estas são as mais comuns:
- S/MIME não está configurado no cliente de e-mail. O cliente de e-mail deve ser configurado para usar certificados S/MIME para assinatura digital e/ou criptografia de e-mails a serem enviados. Verifique se as configurações do cliente para uso do S/MIME estão corretas.
- Do destinatário do e-mail criptografado, não é conhecido um certificado S/MIME válido e confiável. A maioria dos clientes usa o Active Directory ou Azure Active Directory como livro de endereços onde certificados públicos S/MIME são publicados. Se não existir um certificado válido e confiável no (Azure) Active Directory, e o cliente de e-mail não conhecer o certificado S/MIME do destinatário como endereço armazenado localmente, não será possível enviar um e-mail criptografado (mas sim um e-mail assinado digitalmente).
Como opção extra, alguns clientes também podem configurar um “LDAP Key Server” ou “livro de endereços S/MIME LDAP” para armazenar e buscar certificados S/MIME pertencentes a endereços conhecidos. O KeyTalk fornece esse livro LDAP S/MIME como parte da sua solução.
- Para assinar digitalmente, normalmente é necessário configurar um algoritmo de hash no cliente de e-mail. SHA1 é muito comum, mas não é confiável desde 2007. Garanta que o algoritmo configurado para assinatura digital seja ‘moderno’, como SHA256. Ao usar algoritmo desatualizado, o e-mail geralmente é enviado, mas o destinatário não poderá abrir a mensagem ou receberá uma advertência. Em alguns casos, o e-mail com algoritmo desatualizado é rejeitado.
- Para permitir a criptografia de um e-mail, normalmente deve-se configurar um algoritmo de criptografia no cliente de e-mail. Garanta que o algoritmo seja ‘moderno’, como AES256. Ao usar algoritmo desatualizado, ocorre o mesmo problema descrito acima.
- O S/MIME funciona em cliente de e-mail em desktop ou laptop, mas não no iOS ou Android combinado com Exchange Online ou Outlook Web Access (OWA)? Então, configurações adicionais são necessárias. Consulte:
Como configuro o Office 365 Exchange Online para confiar e habilitar a criptografia e assinatura digital de e-mail S/MIME?
A resposta para essa questão é bastante técnica. KeyTalk disponibilizou um documento que pode ser usado como guia para ajudar a configurar o Exchange Online. O documento pode ser encontrado aqui: Anything You Ever Wanted To Know About SMIME Email Encryption and Digital Signing Configurations, But Were Afraid To Ask
