KeyTalk Perguntas Frequentes (FAQ)

Sim, o KeyTalk pode lidar com múltiplas CAs. Tanto CAs privadas, como o Microsoft Active Directory Certificate Server, quanto CAs públicas, como a GMO GlobalSign ou DigiCert QuoVadis.

Sim, o KeyTalk desenvolve funcionalidades e integrações com base na demanda do cliente e no business case. Quando uma integração necessária ainda não é suportada e é tecnicamente viável, você pode possibilitar uma integração bem-sucedida junto com a Unidade de Negócios KeyTalk. Essa integração será então incorporada integralmente em nosso software e, portanto, mantida.

Sim, o KeyTalk pode gerar chaves privadas com entropia suficiente, como parte das Certificate Signing Requests (CSRs) centralmente geradas. Esses pares de chaves assimétricas podem ser armazenados em seu próprio banco de dados de gerenciamento criptografado AES256 ou em um Hardware Security Module (HSM) vinculado. Assim que um par de chaves expira ou se torna inválido, a plataforma KeyTalk regenera esse par de chaves e o certificado associado, automaticamente ou semi-automaticamente através de um processo de workflow.

Nossa definição de certificados X.509 de curta duração: certificados que não duram mais que o tempo que leva para uma Certificate Revocation List (CRL) atual ser atualizada e distribuída desde o momento em que são emitidos. Normalmente você trabalha com CRLs que são atualizadas uma vez por dia? Então, certificados de curta duração são válidos 24 horas a menos. Online Certificate Status Protocol (OCSP) radiators são teoricamente muito mais rápidos que 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 inclusão de um certificado no OCSP até e incluindo a inclusão real. Isso significa que os OCSP 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 tempo de vida a um certificado a ser emitido, desde que a Autoridade Certificadora destino suporte isso. A validade mais curta que o KeyTalk pode atribuir a um certificado é 1 segundo.

Here are the translations of the previously supplied texts into Portuguese, maintaining the IT jargon as used in Portuguese:

KeyTalk Perguntas Frequentes (FAQ)

O KeyTalk pode lidar com certificados de múltiplas Autoridades Certificadoras (CAs)?

Sim, o KeyTalk pode lidar com múltiplas CAs. Tanto CAs privadas, como o Microsoft Active Directory Certificate Server, quanto CAs públicas, como a GMO GlobalSign ou DigiCert QuoVadis.

Quero usar uma Autoridade Certificadora, mas o KeyTalk parece não suportá-la! Isso é mesmo possível?

Sim, o KeyTalk desenvolve funcionalidades e integrações com base na demanda do cliente e no business case. Quando uma integração necessária ainda não é suportada e é tecnicamente viável, você pode possibilitar uma integração bem-sucedida junto com a Unidade de Negócios KeyTalk. Essa integração será então incorporada integralmente em nosso software e, portanto, mantida.

O KeyTalk pode gerenciar chaves criptográficas públicas/privadas assimétricas?

Sim, o KeyTalk pode gerar chaves privadas com entropia suficiente, como parte das Certificate Signing Requests (CSRs) centralmente geradas. Esses pares de chaves assimétricas podem ser armazenados em seu próprio banco de dados de gerenciamento criptografado AES256 ou em um Hardware Security Module (HSM) vinculado. Assim que um par de chaves expira ou se torna inválido, a plataforma KeyTalk regenera esse par de chaves e o certificado associado, automaticamente ou semi-automaticamente através de um processo de workflow.

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 que o tempo que leva para uma Certificate Revocation List (CRL) atual ser atualizada e distribuída desde o momento em que são emitidos. Normalmente você trabalha com CRLs que são atualizadas uma vez por dia? Então, certificados de curta duração são válidos 24 horas a menos. Online Certificate Status Protocol (OCSP) radiators são teoricamente muito mais rápidos que 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 inclusão de um certificado no OCSP até e incluindo a inclusão real. Isso significa que os OCSP 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 tempo de vida a um certificado a ser emitido, desde que a Autoridade Certificadora destino suporte isso. A validade mais curta que o KeyTalk pode atribuir a um certificado é 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).

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.

Não, não precisa. O KeyTalk também pode lidar com certificados cuja chave privada é gerada no sistema alvo ou em um HSM.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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:
  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

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”.