Domande frequenti su KeyTalk (FAQ)
KeyTalk può gestire certificati provenienti da più Autorità di Certificazione (CA)?
Sì, KeyTalk può gestire più CA. Sia CA private, come Microsoft Active Directory Certificate Server, sia CA pubbliche, come GMO GlobalSign o DigiCert QuoVadis.
Vorrei utilizzare un'autorità di certificazione, ma KeyTalk non sembra supportarla! È possibile?
KeyTalk può gestire chiavi crittografiche pubbliche/private asimmetriche?
KeyTalk supporta i certificati X.509 di breve durata?
La nostra definizione di certificati X.509 di breve durata: certificati che non durano più del tempo necessario per l’aggiornamento e la distribuzione di una Certificate Revocation List (CRL) corrente dal momento della loro emissione. Di solito lavori con CRL che vengono aggiornate una volta al giorno? Allora i certificati a vita breve hanno una validità inferiore di 24 ore. I radiatori OCSP (Online Certificate Status Protocol) sono teoricamente molto più veloci da aggiornare rispetto alle CRL, ma in pratica ci vuole più tempo del tempo medio di aggiornamento di una CRL per stabilire la necessità di includere un certificato in un OCSP fino all’effettiva inclusione di un certificato in un OCSP. Ciò significa che gli OCSP di solito non sono più pratici di una CRL quando si tratta di certificati X.509 di breve durata.
KeyTalk può assegnare qualsiasi durata a un certificato da emettere, se l’Autorità di Certificazione di destinazione lo supporta. La validità più breve che KeyTalk può assegnare a un certificato è di 1 secondo.
I certificati emessi attraverso il sistema di gestione dei certificati KeyTalk dimostrano l'identità digitale di una persona o di una macchina?
Un’identità digitale valida è dimostrata da un certificato X.509, attraverso diversi fattori:
- La validità: il certificato è presente in un indicatore di revoca come CRL o OCSP? Il certificato non è ancora scaduto in termini di data/ora massima?
- La catena di CA è attendibile per il computer che vuole convalidare l’identità digitale? Ciò richiede che la CA Root emittente sia affidabile e che anche le CA intermedie possano essere convalidate o siano conosciute e affidabili dal computer che vuole convalidare l’identità digitale.
- Il nome dell’identità digitale non compare solo nel Common Name (CN) del certificato, ma anche nel Subject Alternative Name (SAN) del certificato?
- L’identità che richiede la convalida può essere utilizzata per l’autenticazione del cliente, per l’autenticazione del server o per entrambe?
- Il nome dell’identità digitale da convalidare viene convalidato e corrisponde a una voce del Domain Name Server (DNS)? Oppure corrisponde all’indirizzo e-mail a cui si accede?
- L’identità digitale da convalidare possiede il certificato pubblico X.509 e la chiave privata corrispondente?
Il sistema KeyTalk si occupa di tutti questi fattori di identità digitale per l’emissione e la gestione dei certificati. Questo ci permette di dimostrare l’identità di una persona, di un dispositivo mobile, di un computer, di un server, di un dispositivo di rete e/o di un dispositivo Internet o delle cose (IoT).
Se un certificato (e una chiave privata) emesso da KeyTalk viene installato dal client/app KeyTalk, il mio server deve essere riavviato?
No, le comuni applicazioni server come IIS, Apache, TomCat, NGINX non richiedono il riavvio del server se il certificato SSL viene sostituito dal client/app KeyTalk. In parole povere, i server non si spegneranno con queste applicazioni e quindi non interferiranno con il servizio.
La piattaforma KeyTalk deve sempre creare e gestire la chiave privata?
No, non è necessario farlo. KeyTalk può anche gestire certificati la cui chiave privata è generata sul sistema di destinazione o su un HSM.
La soluzione KeyTalk funziona con un Trusted Platform Module (TPM) disponibile per generare/salvare una chiave privata?
Sì, la soluzione KeyTalk può gestire i TPM, in quanto possono essere considerati come una Smart Card Virtuale (VSC). La maggior parte dei TPM si trova nei sistemi Windows, dove le VSC sono attivate da Microsoft o da altri produttori di software.
In questo caso, il sistema KeyTalk invierà i metadati della Certificate Signing Request (CSR) al client/app KeyTalk, che a sua volta trasferirà i dati CSR al TPM/VSC.
Il CSR viene quindi generato e trasmesso tramite il client/app KeyTalk al server KeyTalk, lasciando la chiave privata al sicuro sul TPM.
Il server KeyTalk invia il certificato X.509 firmato al client/app KeyTalk, che a sua volta rilascia il certificato al VSC.
KeyTalk (Qualified) (Trusted) Certificate Service Provider ((Q)TCSP) può lavorare in modo indipendente?
Sì, la piattaforma KeyTalk può emettere certificati e chiavi private associate da un (Q)TCSP collegato. Quando passerai a un altro (Q)TCSP, collegherai questo nuovo (Q)TCSP alla piattaforma KeyTalk e tutti i nuovi certificati verranno emessi direttamente tramite questo nuovo (Q)TCSP.
Puoi anche revocare tutti i certificati emessi con il vecchio (Q)TCSP in una sola volta e, entro il tempo di elaborazione della Certificate Revocation List (CRL) o dell’Online Certificate Status Protocol (OSCP), sostituirli automaticamente con certificati emessi con il nuovo (Q)TCSP.
KeyTalk è in grado di localizzare i certificati nella mia rete?
Sì, tramite il KeyTalk Smart Certificate Security Scanner. Puoi fare in modo che la rete su tutti i cancelli venga scansionata per IP, IP-range e nomi di dominio pienamente qualificati per identificare i certificati utilizzati.
Se installi l’applicazione proxy KeyTalk Smart Certificate Security Scanner puoi anche eseguire una scansione più approfondita su qualsiasi server. In questo modo, potrai individuare i certificati che non sono necessariamente legati a una porta TCP.
La piattaforma KeyTalk può pubblicare i certificati di crittografia e firma digitale (S/MIME) da me emessi?
Sì, la piattaforma KeyTalk è in grado di pubblicare certificati S/MIME validi emessi di default sia in Active Directory che in Azure Active Directory e (Open)LDAP.
Il certificato viene memorizzato nei soliti attributi AD/LDAP: UserCertificate e AltSecurityIdentities.
Vuoi utilizzare una rubrica/un server di chiavi Enterprise LDAP S/MIME per scopi pubblici? Questo viene fornito come server virtuale separato nella piattaforma KeyTalk.
La crittografia delle e-mail S/MIME e i certificati per la firma digitale devono essere configurati su Outlook per Windows. KeyTalk è in grado di supportarlo?
Sì. Anche se Microsoft afferma spesso che non è possibile, questa configurazione automatica è possibile da anni tramite il client/app KeyTalk. Senza ulteriore interazione umana, con le comuni impostazioni SHA256 e AES256.
Se una crittografia di posta S/MIME e un certificato firmato digitalmente sono pubblicati in una rubrica LDAP pubblica, come possono essere utilizzati con i comuni client di posta elettronica?
Il client/app KeyTalk può impostare automaticamente qualsiasi rubrica LDAP su Outlook per Windows, anche se la rubrica LDAP utilizza impostazioni di ricerca personalizzate.
Gli altri client di posta elettronica, a patto che supportino le rubriche LDAP, possono essere configurati manualmente sulla base di chiare istruzioni scritte.
Posso far funzionare la piattaforma KeyTalk in modalità High Available (HA) / ridondante?
Sì, tutte le appliance virtuali KeyTalk della nostra soluzione principale possono funzionare in HA. A tal fine è necessario un Load Balancer. Puoi configurare facilmente l’HA seguendo passo dopo passo il nostro manuale per l’amministratore.
Il mio server utilizza la Server Name Indication (SNI). È supportato da KeyTalk in termini di gestione dei certificati e di roll-out/installazione automatica?
Sì, la piattaforma KeyTalk supporta l’SNI. Sul client/app KeyTalk per ogni sito ospitato dal server, si imposta il link al modello di certificato desiderato, l’autenticazione e il bind IP richiesto, dopodiché la piattaforma KeyTalk gestirà automaticamente ogni certificato SNI/SSL.
I miei utenti hanno diversi dispositivi su cui leggono le e-mail. Come fa KeyTalk a garantire che lo stesso certificato S/MIME valido e la stessa chiave privata siano utilizzati su tutti i dispositivi degli utenti?
KeyTalk supporta il cosiddetto “roll-over di certificati e chiavi private”.
In parole povere, questo significa che KeyTalk può riemettere un certificato e una chiave al dispositivo di un utente finale, a patto che l’autenticazione sia positiva. La condizione è che la chiave privata possa essere recuperata da qualche parte (HSM, database criptato di KeyTalk, un altro sistema di gestione delle chiavi).
KeyTalk rilascia certificati S/MIME validi ai miei utenti finali, ma S/MIME non funziona nella mia zona. Perché?
Ci possono essere diversi motivi per cui S/MIME non funziona per un utente finale. Queste sono le più comuni:
- S/MIME non è impostato per il client di posta elettronica. Il client di posta elettronica deve essere configurato per utilizzare i certificati S/MIME per la firma digitale e/o la crittografia delle e-mail da inviare. Verifica che le impostazioni del client di posta elettronica per l’utilizzo di S/MIME siano corrette.
- Il destinatario dell’email criptata non conosce alcun certificato S/MIME valido e affidabile. La maggior parte dei client di posta utilizza Active Directory o Azure Active Directory come rubrica in cui sono pubblicati i certificati S/MIME pubblici. Se un certificato valido e affidabile non è presente nell’Active Directory (Azure) e il client di posta non conosce il certificato S/MIME del destinatario come indirizzo di posta memorizzato localmente nella rubrica, non sarà possibile inviare un’e-mail crittografata (ma un’e-mail firmata digitalmente).
Come opzione aggiuntiva, alcuni client di posta elettronica possono anche impostare un cosiddetto “server di chiavi LDAP” o “rubrica LDAP S/MIME” per memorizzare e cercare i certificati S/MIME appartenenti a indirizzi e-mail noti. KeyTalk fornisce questa rubrica LDAP S/MIME come parte della sua soluzione KeyTalk.
- Per apporre la firma digitale, spesso è necessario impostare un algoritmo di hashing nel client di posta elettronica. SHA1 è spesso uno standard, ma dal 2007 i destinatari non si fidano più di lui. Assicurati che l’algoritmo di hashing impostato per la firma digitale sia un algoritmo “moderno”, come SHA256. Se si utilizza un algoritmo obsoleto, spesso l’e-mail viene inviata, ma il destinatario non è in grado di aprire il messaggio o di ricevere un avviso. In alcuni casi, un’e-mail ricevuta con un algoritmo obsoleto viene rifiutata.
- Per abilitare la crittografia di un’e-mail, spesso è necessario impostare un algoritmo di crittografia nel client di posta elettronica. Assicurati che l’algoritmo di crittografia sia un algoritmo “moderno”, come AES256. Se si utilizza un algoritmo obsoleto, spesso l’e-mail viene inviata, ma il destinatario non è in grado di aprire il messaggio o di ricevere un avviso. In alcuni casi, un’e-mail ricevuta con un algoritmo obsoleto viene rifiutata.
- S/MIME funziona tramite un client di posta elettronica su un computer desktop o portatile, ma non su iOS o Android icm Exchange Online o Outlook Web Access (OWA)? In questo caso sono necessarie ulteriori impostazioni. Ti rimandiamo a questo articolo:
Come faccio a configurare Office 365 Exchange Online in modo che sia affidabile e abiliti la crittografia delle email S/MIME e la firma digitale?
La risposta a questa domanda è piuttosto tecnica. KeyTalk ha reso disponibile un documento che può essere utilizzato come guida per aiutarti a configurare Exchange Online. Il documento è disponibile qui: Tutto quello che avresti voluto sapere sulle configurazioni della crittografia e-mail SMIME e della firma digitale, ma che avevi paura di chiedere
