Stai utilizzando un browser obsoleto. Per un'esperienza di navigazione più rapida e sicura, esegui subito l'upgrade gratuito.

Trust ItaliaFAQ

Le nostre FAQ forniscono utili risposte a numerosi interrogativi sulla sicurezza informatica e sono un valido ausilio nella scelta del prodotto più adatto alle esigenze di ognuno.

  • Home
  • Supporto
  • Informazioni
  • FAQ

Il Secure Socket Layer (SSL) e il suo successore Transport Layer Security (TLS ) sono un protocolli crittografici che permettono una comunicazione sicura sulle reti TCP/IP (come, per esempio, Internet) fornendo autenticazione, crittografia e integrità dei dati.

Sviluppato da Netscape nel 1996 il protocollo SSL, poi TLS, fu successivamente adottato, in maniera pressoché universale, come metodo per proteggere le trasmissioni di dati in Internet.

Il protocollo TLS/SSL, supportato e utilizzato - tra l'altro - da browser e web server, fa uso di un sistema di crittografia asimmetrica, quindi a coppia di chiavi (pubblica e privata).

Tale sistema di crittografia fu sviluppato, nel 1978, dai ricercatori Ronald Rivest, Adi Shamir e Leonard Adleman mediante il loro algoritmo RSA.

Per poter avviare una connessione TLS/SSL tra un client (il browser) e un server è necessario che almeno su quest'ultimo sia installato un certificato digitale: un file elettronico, cioè, capace di identificare in maniera univoca server e client.

Il certificato digitale installato sul server consente al client di autenticare il server stesso.

I certificati digitali sono firmati, di norma, da una terza parte affidabile e indipendente che ne garantisce la validità. Tale terza parte si chiama Autorità di Certificazione o Certification Authority (CA). DigiCert è la più riconosciuta CA del mondo.

Il protocollo TLS/SSL consente, come detto, comunicazioni in rete sicure fornendo i tre seguenti importanti elementi: 1- autenticazione - un certificato digitale per server è indissolubilmente associato a uno specifico nome di dominio.

In particolare, prima di rilasciare un certificato digitale per server, le CA eseguono una serie di verifiche volte a confermare l'identità dell'organizzazione che richiede il certificato e il suo diritto a utilizzare il dominio al quale il certificato stesso verrà associato.

Questo legame tra il certificato e il nome di dominio offre agli utenti la garanzia di interagire con il sito web di un'organizzazione autorizzata e legalmente riconosciuta;

2- crittografia - attraverso il processo di cifratura le informazioni trasmesse in rete vengono trasformate in modo tale da risultare comprensibili, una volta decifrate, al solo destinatario.
Un certificato SSL lega un'identità a una coppia di chiavi elettroniche che può essere usata per cifrare e firmare le informazioni trasmesse in rete attraverso il protocollo "https";

3- integrità dei dati - i dati scambiati nelle connessioni TLS/SSL sono protetti contro il tentativo, da parte di eventuali terzi malintenzionati, di apportarvi modifiche durante la trasmissione.
Le parti coinvolte nella connessione sanno, dunque, con certezza che le informazioni da loro ricevute sono esattamente quelle partite dall'altro capo del collegamento.

Il protocollo TLS/SSL risulta essere, dunque, un mezzo estremamente potente per la conduzione di transazioni online, autenticate e cifrate, con i clienti del vostro sito web.

Con un certificato SSL DigiCert installato sul vostro sito web, i vostri utenti o i vostri clienti potranno inviarvi i numeri delle loro carte di credito, o altre informazioni sensibili, nella più totale garanzia, non solo di interagire realmente con voi, ma anche di trasmettere tali informazioni in modo tale che esse non possano essere comprese, né alterate da alcuno durante la comunicazione.

La crittografia è la scienza che si occupa di proteggere le informazioni, rendendole incomprensibili a chiunque le dovesse intercettare, in modo tale che possano essere decifrate soltanto dal legittimo destinatario.

Il messaggio da proteggere viene detto testo in chiaro, mentre quello trasformato, in modo da essere incomprensibile, viene detto testo cifrato.
La trasformazione da testo in chiaro a testo cifrato si dice cifratura, mentre la trasformazione inversa si dice decifratura.

La trasformazione crittografica è detta algoritmo di cifratura e specifica la procedura che trasforma il testo in chiaro in quello cifrato.
Questa trasformazione è parametrica e il parametro è detto chiave: ciò significa che la trasformazione in sé è soltanto un procedimento, il quale però per essere attuato ha bisogno di un'informazione ulteriore da cui dipende il risultato.

Per decifrare il messaggio non basta conoscere l'algoritmo di cifratura utilizzato, ma è necessario conoscere anche la chiave.

In genere, nello studio degli algoritmi crittografici e della loro sicurezza, si ipotizza che l'algoritmo sia noto a tutti e che ciò che non è noto sia esclusivamente la chiave: questo perché oggi si considera inaffidabile un sistema crittografico la cui sicurezza si basi sulla segretezza dell'algoritmo.

La crittografia tradizionale si basa su un meccanismo per cui cifratura e decifratura sono effettuate utilizzando la stessa chiave: per questo si parla di crittografia simmetrica, o anche, dato che tale chiave deve essere nota solo ai due interlocutori, di crittografia a chiave segreta.
Un noto algoritmo di questo tipo è il DES (Data Encryption Standard).

Il grosso problema di questo approccio è però la distribuzione delle chiavi: se due interlocutori vogliono usare un algoritmo di questo tipo, per comunicare in modo sicuro, devono prima accordarsi in qualche modo sulla chiave, per esempio vedendosi di persona.

Infatti, dato che il canale che usano per la trasmissione dei messaggi non è sicuro (altrimenti non avrebbero bisogno di cifrarli), non possono utilizzarlo per trasmettere la chiave.

Il problema è stato risolto nel decennio tra il 1970 e il 1980 con l'invenzione della crittografia asimmetrica o a chiave pubblica.

Con algoritmi di quest'ultimo tipo ogni soggetto ha due chiavi complementari: una pubblica, da distribuire a tutti quelli con cui vuole comunicare, e una privata da tenere segreta.

Ciò che viene cifrato con la chiave pubblica può essere decifrato solo con la chiave privata corrispondente e viceversa.

L'operazione di cifratura con la chiave pubblica può essere effettuata da chiunque, mentre quella mediante la chiave privata può essere fatta soltanto dal proprietario della chiave medesima.
Poiché la chiave (pubblica) è nota a tutti non esiste più il problema della sua distribuzione: per comunicare in modo sicuro con una persona basta cifrare il messaggio con la sua chiave pubblica.

Il più noto tra gli algoritmi di questo tipo è probabilmente l'RSA (dalle iniziali dei suoi tre inventori: Ronald Rivest, Adi Shamir e Leonard Adleman).

L'avvento della crittografia asimmetrica o a chiave pubblica, alla fine degli anni settanta del secolo scorso, ha eliminato il problema della distribuzione delle chiavi nell'ambito dagli algoritmi di crittografia simmetrica o a chiave segreta.

Questa sua caratteristica ha subito reso gli algoritmi di crittografia a chiave pubblica ideali per le transazioni online.

Nella crittografia asimmetrica o a chiave pubblica ogni soggetto possiede una coppia di chiavi complementari, una delle chievi è denominata pubblica e l'altra privata. Qualsiasi informazione cifrata utilizzando la chiave pubblica può essere decifrata soltanto utilizzando la corrispondente chiave privata e viceversa.

Cerchiamo di chiarire con un esempio il funzionamento del meccanismo di crittografia asimmetrica.

Bob ha due chiavi complementari: ciò che viene cifrato con una chiave può essere, come detto, decifrato dall'altra.
Egli mantiene una delle due chiavi chiave privata (cioè segrata) e rende l'altra disponibile a chiunque voglia scambiare messaggi, in sicurezza, con lui (chiave pubblica).

Alice, dovendo mandare un messaggio a Bob, lo cifrerà dunque utilizando la chiave pubblica di quest'ultimo e glielo invierà.
Bob, una volta ricevuto il messaggio di Alice, lo decifrerà con la propria chiave privata: l'unica in grado di compiere tale operazione.

Il meccanismo crittografia a chiave pubblica presenta, rispetto a quello a chiave segreta, molti vantaggi:

Bob non deve affatto preoccuparsi dell'invio, ad Alice, in una qualche modalità protetta della chiave, essendo questa destinata a essere resa pubblica. Se qualcuno, infatti, ne entrasse in possesso tutto quello che potrebbe farci sarebbe inviare a Bob dei messaggi cifrati. L'eventale intruso che dovesse procurarsi la chiave pubblica di Bob non potrebbe chiaramente usarla né per decifrare i messaggi inviati a Bob (operazione per la quale è necessaria la chiave privata di Bob), né tantomeno per inviare messaggi dall'account di quest'ultimo.
Bob dunque può, in assoluta tranquillità, inviare per email la propria chiave pubblica ad Alice, oppure addirittura pubblicarla in una qualsiasi directory pubblica.

Bob ed Alice non devono neanche preoccuparsi del fatto che qualcuno potrebbe aver intercettato il messaggio inviato: solo Bob, infatti, utilizzando la propria chiave privata, della quale è l'unico possessore, può decifrarlo.

Una delle grosse innovazioni indotte dalla crittografia asimmetrica è la firma digitale: il mittente di un messaggio può infatti firmarlo digitalmente grazie alla propria chiave privata (che solo lui possiede), ma chiunque è in grado di verificare l'autenticità della firma grazie alla chiave pubblica dello stesso mittente(che è globalmente nota).

La firma digitale può essere abbinata alla normale cifratura, ottenendo così messaggi firmati digitalmente e cifrati.
Si ipotizzi che Alice voglia mandare un messaggio a Bob: per prima cosa lo cifrerà con la propria chiave privata (firma digitale) e poi con quella pubblica dello stesso Bob (cifratura), infine invierà il messaggio.
Quando Bob lo riceverà prima lo decifrerà con la propria chiave privata (operazione che solo lui può fare, per cui è garantita la confidenzialità) e poi con quella pubblica di Alice: se l'operazione andrà a buon fine Bob avrà la certezza che il mittente è realmente Alice, perché soltanto lei può aver cifrato (firmato) il messaggio con la propria chiave privata.

In realtà il modo in cui si realizza la firma digitale è leggermente più complicato. Ciò che il mittente cifra con la propria chiave privata per garantire l'autenticità non è l'intero messaggio, ma una sua "impronta", detta digest, ottenuta mediante una particolare funzione detta di hash: il digest cifrato viene poi allegato al messaggio e ne costituisce la firma. Il destinatario calcola il digest del messaggio ricevuto (la funzione di hash è pubblica) e lo confronta con quello che ottiene decifrando con la chiave pubblica del mittente la firma allegata: se coincidono la firma è autentica.

Si potrebbe pensare che, dopo l'invenzione della crittografia a chiave pubblica, quella a chiave segreta abbia perso interesse, ma le cose non stanno così. Gli algoritmi asimmetrici sono infatti computazionalmente molto più onerosi di quelli simmetrici, per cui il loro uso risulta, in tali termini, molto più pesante. Una soluzione comunemente adottata è l'uso della crittografia asimmetrica per concordare una chiave segreta da utilizzare poi per scambiarsi i messaggi tramite un algoritmo a chiave simmetrica: in questo modo il computazionalmente pesante algoritmo a chiave pubblica viene usato solo per trasmettere una piccola quantità di dati (la chiave segreta), mentre per il resto si usa il più leggero algoritmo a chiave segreta.

Un'Autorità di Certificazione o Certification Authority (CA) è una terza parte fidata che rilascia, revoca, rinnova e fornisce online le directory dei certificati digitali dalle quali è possibile scaricare le chiavi pubbliche.

Le Autorità di Certificazione più serie eseguono controlli molto rigorosi prima di rilasciare un certificato.
Tali controlli, nel loro insieme detti Procedure di Validazione, hanno lo scopo di verificare e autenticare l'identità dei soggetti che richiedono i certificati.

Tutti i certificati rilasciati sono firmati con la chiave privata dell'Autorità di Certificazione per garantirne l'autenticità.

In genere la chiave pubblica di un'Autorità di Certificazione è ampiamente distribuita.
La maggior parte dei browser normalmente accetta in maniera automatica i certificati server rilasciati da Autorità di Certificazione universalmente note, come per esempio DigiCert, dal momento che la chiave pubblica di queste CA viene installata nei browser prima che questi ultimi siano distribuiti agli utenti.

Nella crittografia asimmetrica, o a chiave pubblica, se Alice vuole inviare un messaggio segreto a Bob deve procurarsi una copia della chiave pubblica di quest'ultimo. Nel fare tale operazione, però, Alice deve sincerarsi che la chiave che sta, per esempio, scaricando da una directory pubblica appartenga realmente a Bob.

I certificati digitali risolvono proprio questo problema: un certificato è infatti un documento elettronico che lega una chiave pubblica a un soggetto.
I certificati digitali sono rilasciati da una terza parte fidata denominata Autorità di Certificazione o Certification Authority (CA) come, per esempio, DigiCert. Prima di rilasciare un certificato, ogni buona CA, esegue delle procedure di verifica volte allo scopo di accertare che il soggetto richiedente sia realmente chi afferma di essere.

Un certificato con chiave pubblica contiene le seguenti informazioni:

- il soggetto del certificato. Nel caso di un certificato SSL per soggetto si intendono il nome dell'organizzazione richiedente e il common name per il quale è effettuata la richiesta: per esempio Trust Italia Spa per il common name www.trustitalia.it;
- il periodo di validità del certificato;
- la chiave pubblica;
- l'ente emittente, cioè la Certification Autority, una terza parte indipendente e fidata come, per esempio, DigiCert;
- la firma dell'ente emittente.

Una Certificate Revocation List (CRL) è un elenco di certificati digitali che sono stati revocati prima della loro scadenza. Ci sono diversi motivi per cui un certificato deve essere revocato e inserito in una CRL. Ad esempio la chiave privata può essersi corrotta.

Le CRL sono curate direttamente dalle Autorità di Certificazione e forniscono informazioni sui certificati revocati rilasciati dalle Autorità di Certificazione stesse. Le CRL in genere non elencano i certificati scaduti; quindi i certificati revocati e nel frattempo anche scaduti vengono rimossi dalla CRL. Nonostante le CRL vengano distribuite, esistono anche delle Central Repositories delle CRL, vale a dire siti che contengono le CRL più aggiornate della maggior parte delle Autorità di Certificazione.

L'OCSP (Online Certificate Status Protocol) è un protocollo che fa parte dello standard X.509 e permette di verificare la validità di un certificato digitale senza dover ricorrere alle liste di revoca. Esso ha infatti sostituito il precedente protocollo CRL (Certificate Revocation List), presentando notevoli vantaggi rispetto a quest'ultimo.

L'architettura del protocollo OCSP è di tipo client-server: da un lato ci sono i vari client che effettuano le richieste (OCSP requests) per controllare la validità dei certificati, mentre dall'altro c'è il server (responder) che cerca di soddisfarle inviando messaggi di validità (valido, revocato o sconosciuto).

L'Online Certificate Status Protocol è lo standard emergente dell'IETF (Internet Engineering ask Force), destinato al controllo della validità dei certificati digitali nel corso di una determinata transazione. Esso permette infatti di condurre le verifiche in tempo reale, consentendo un notevole risparmio di tempo e di denaro e fornendo alle attività di e-business un sistema più rapido, semplice e affidabile rispetto a quello offerto dal tradizionale scaricamento ed elaborazione delle CRL.

I principali vantaggi del protocollo OSCP rispetto al CRL sono:

- l'eliminazione della necessità per i client di scaricare e analizzare le liste di revoca;
- il migliore utilizzo della banda, dal momento che un messaggio OCSP ha una dimensione trascurabile rispetto alle CRL;
- il supporto di una catena fidata di OCSP richiesta tra i vari responder: questo permette ai client di comunicare con un responder fidato per interrogare un altro responder.

In breve il protocollo OCSP è notevolmente più efficiente delle CRL.

Una volta iniziate le procedure di validazione e autenticazione, il rilascio di un certificato SSL per server richiede dai 5 ai 7 giorni lavorativi di tempo per i prodotti Secure Site, Secure Site Pro e Secure Site WildCard.

Per i prodotti Secure Site with EV e Secure Site Pro with EV richiede, invece, circa 15 giorni lavorativi di tempo, sempre dall'inizio delle procedure di validazione e autenticazione.

Il certificato richiesto sarà inviato, via email, all’account del Contatto Tecnico.

Subito dopo il completamento della procedura di registrazione e acquisto online, una volta verificato l'avvenuto pagamento, inizieranno le procedure di validazione e autenticazione dei dati immessi.

Tali procedure si articolano nei punti di seguito descritti.

Viene verificata, in primo luogo, l’identità dell’azienda od organizzazione che richiede il certificato. Tale verifica viene condotta attraverso la consultazione del database di infoimprese (www.infoimprese.it), per le società che vi sono iscritte, e di quello di Dun & Bradstreet (www.dnb.it), per le società od organizzazioni in possesso di un numero DUNS.
In base alle procedure di validazione comuni a tutte le affiliate DigiCert quanto inserito nel campo Organization, durante la generazione del CSR, deve corrispondere esattamente alla ragione sociale riportata nel database di infoimprese o in quello di Dun & Bradstreet. Nel caso in cui non vi sia corrispondenza (perché, per esempio, la ragione sociale della società è stata abbreviata) gli operatori si vedranno costretti a respingere la richiesta di certificato.

La verifica successiva riguarda la registrazione del dominio riportato nel Common Name; per eseguirla vengono consultati i database WHOIS.
La società od organizzazione alla quale è intestata la registrazione del dominio deve essere la stessa che richiede il certificato. In caso contrario gli operatori invieranno, via email, una Lettera di Autorizzazione per il Dominio, cioè un documento (accompagnato dalle indicazioni per la sua compilazione) con il quale il titolare del dominio concede a chi sta richiedendo il certificato il diritto di utilizzare il dominio stesso. Qualora il dominio fosse intestato a una società od organizzazione non più esistente, o la cui denominazione è errata verrà richiesto l'aggiornamento del dominio.

Viene infine verificato, telefonicamente, che la persona indicata come Contatto Organizzativo, durante la procedura di registrazione, sia effettivamente un dipendente dell’azienda che richiede il certificato, conosca i dettagli della richiesta e confermi che la persona indicata come Contatto Tecnico sia autorizzata a ricevere e a installare il certificato stesso. Un operatore dovrà poter raggiungere il Contatto Organizzativo attraverso il numero telefonico intestato all’azienda richiedente. Tale numero deve essere reperibile attraverso una terza parte affidabile e ufficiale (infoimprese, Dun & Bradstreet, elenchi telefonici pubblici delle compagnie telefoniche). Non potranno essere utilizzati numeri telefonici interni, numeri telefonici intestati a società diverse da quella che richiede il certificato o numeri di cellulare, salvo che non si tratti di cellulari aziendali i cui numeri compaiano sulla bolletta o fattura telefonica intestata all’azienda stessa. Per i motivi sopra indicati ribadiamo il consiglio di designare come Contatto Organizzativo una persona facilmente raggiungibile attraverso il centralino dell’azienda.

Il primo passo da compiere, per richiedere un certificato digitale per server, è generare un CSR.
L’acronimo CSR significa Certificate Signing Request, cioè Richiesta di Firma di Certificato.

Il CSR deve essere generato sul server sul quale è ospitato il sito web che si intende certificare, utilizzando il software che il server stesso mette a disposizione.

La lunghezza del CSR deve essere minino 2048 bit.

Durante la procedura di generazione del CSR ha luogo anche la creazione della coppia di chiavi crittografiche, cioè della chiave pubblica e della chiave privata.

Una volta creata la coppia di chiavi, la chiave pubblica viene inclusa nel CSR mentre quella privata rimane sul server.

La chiave pubblica, inclusa nel CSR, viene inviata, attraverso le procedure di registrazione del sito di Trust Italia Spa, a DigiCert che provvede a firmarla con la propria chiave privata e a reinviarla, infine, sotto forma di certificato digitale.

E’ per questo motivo che il CSR e la coppia di chiavi (che, ricordiamo, è sempre univoca) devono essere generati sulla stessa macchina sulla quale il certificato verrà installato. Infatti il certificato, cioè la chiave pubblica firmata da DigiCert, dovrà essere installato in corrispondenza della rispettiva chiave privata. Nel caso in cui ciò non avvenga, la procedura di installazione del certificato non potrà in nessun caso andare a buon fine.

Il Common Name, ovvero il Fully Qualified Domain Name (FQDN), di un sito è composto dal nome del dominio (per esempio trustitalia.it, digicert.com, cariplo.it) più il nome dell'host (per esempio www, digitalid, trading).

Esempi di Common Name sono, dunque, www.trustitalia.it, digitalid.digicert.com, trading.miabanca.it, secure.rsasecurity.com.

In un Common name non possono essere usati i seguenti caratteri speciali: ! @ $ & * ) ( _ # : " > ? '.
Non possono essere altresì usati indirizzi IP (per esempio 192.168.2.52), né numeri di porta (come per esempio 80 o 443), né http:// o https://.

Nel caso in cui si desideri certificare una intranet il Common Name potrà essere composto da una sola parola, come per esempio il nome del server o localhost.

E’ importante ricordare che i certificati digitali sono, in ogni caso, specifici rispetto al Common Name per il quale vengono richiesti e rilasciati: anche nel caso di una intranet, pertanto, nel campo Common Name va specificato l’URL che gli utenti dovranno digitare per accedere alla intranet stessa.

La verifica dell'identità dell'organizzazione richiedente è un elemento di fondamentale importanza per il rilascio di un certificato.

Quando un utente o un cliente si collega a un sito certificato da Symentec ha la certezza, infatti, non solo di trovarsi in un sito protetto ma anche che l'organizzazione titolare è regolarmente autorizzata a esercitare quell'attività.

Il contratto che viene sottoscritto con Trust Italia e con DigiCert, nel momento in cui si acquista un certificato digitale, non prevede il divieto di utilizzare lo stesso su più di un server fisico, anche se questa pratica è assolutamente poco raccomandabile dal punto di vista della sicurezza.

Del resto, quando le chiavi private sono spostate da un server all'altro, attraverso CD o anche via rete, la sicurezza diminuisce e i controlli diventano più difficili da compiere. Condividendo uno stesso certificato su due o più server, le aziende non fanno che esporsi a rischi enormi e a complicare il controllo degli accessi a una chiave privata nel caso di danno subito da un server.

Inoltre, in tutti i casi di seguito elencati è fortemente raccomandata l'utilizzazione di un certificato diverso per ogni combinazione server/fully qualified domain name:

- server di backup (clustering);
- server multipli che supportano siti multipli (virtual server);
- server multipli che supportano un solo sito (load balancing o round robin);
- virtual hosting o shared hosting.

Nel 2006 le principali autorità di certificazione (CA) mondiali e i maggiori sviluppatori e distributori di browser hanno approvato unanimemente, attraverso il CA/Browser Forum, le pratiche standard per la validazione dei certificati.

Per rilasciare un certificato SSL conforme allo standard Extended Validation (EV) la CA deve adottare le policy stabilite e superare un Webtrust audit.

Il processo di validazione prevede che la CA autentichi l'organization name (ragione sociale) della organizzazione che richiede il certificato e la proprietà del dominio per il quale tale certificato viene richiesto.

Come per i certificati digitali non EV, anche in questo caso, le procedure di validazione si concludono con la telefonata di verifica effettuata al contatto organizzativo.

PASSO 1
Contatta il Supporto per ricevere la URL di accesso al Guest Access.

PASSO 2
Inserisci le apposite credenziali (l'indirizzo email può essere quello del contatto tecnico o del contatto organizzativo indicati nell'ordine originale).
L'operazione comporterà l'invio all'indirizzo indicato nel form di una mail con un security code che ti sarà richiesto per accedere ai dettagli dell'ordine.

PASSO 3
Accedi ai dettagli dell'ordine e fai clic su Certificate Actions.

PASSO 4
Fai clic su Reissue per avviare la richiesta di sostituzione.

Quando i clienti scaricano applicazioni online, installano plug-in e componenti aggiuntivi o interagiscono con sofisticate applicazioni Web, devono avere la certezza che il codice sia autentico e che non sia stato infettato o alterato.

Nelle tradizionali vendite di software un acquirente è in grado di verificare l'origine dell'applicazione e la sua integrità esaminando la confezione, cosa che non è evidentemente possibile quando l'applicazione acquistata viene scaricata attraverso la Rete.
La firma del codice crea però una sorta di contenitore digitale che indica ai clienti l'identità dell'organizzazione o della persona responsabile del codice e conferma che questo non è stato modificato dal momento in cui è stata applicata la firma.

DigiCert Code Signing protegge il marchio e la proprietà intellettuale applicando una Firma Digitale per rendere le applicazioni identificabili e più difficili da falsificare o danneggiare.

La firma del codice e del contenuto è basata sulla crittografia a chiave pubblica.

Gli sviluppatori e gli editori di software utilizzano quindi una chiave privata per aggiungere una firma digitale ai propri codici o ai propri contenuti. Le piattaforme software e le applicazioni utilizzano, conseguentemente, una chiave pubblica per decifrare la firma durante il download e confrontano poi l'hash utilizzato per firmare il codice con quello dell'applicazione scaricata.

Il codice firmato da uno sviluppatore attendibile potrà essere accettato automaticamente oppure sarà possibile visualizzare le informazioni sulla firma e decidere, di conseguenza, se accettarlo o meno.

Durante la di registrazione per l'acquisto di un certificato Code Signing Trust Italia raccoglierà le informazioni necessarie sulla vostra azienda.

Il processo di convalida può richiedere da alcune ore ad alcuni giorni, a seconda delle informazioni fornite e dalla facilità con la quale esse possono essere verificate.

La fornitura del certificato è subordinata all'effettiva ricezione, da parte di Trust Italia, del pagamento: il pagamento tramite carta di credito consente quindi un rilascio in tempi più brevi rispetto a quello tramite bonifico bancario.

Ogni certificato di firma del codice viene acquistato con un periodo di validità associato. Durante il periodo di validità il certificato digitale può essere utilizzato senza limitazioni.

Quando il certificato digitale scade, tutte le firme digitali che dipendono dal certificato digitale scadono, a meno che la firma non includa l'indicazione di data e ora.

L'opzione di indicazione di data e ora specifica quando il codice è stato firmato, consentendo così di verificare, una volta scaduto, che il certificato era valido al momento dell'apposizione della firma.

Trust Italia consiglia agli sviluppatori, per motivi di sicurezza e di gestione, di acquistare certificati di firma del codice aggiuntivi, piuttosto che condividerli. Se un certificato viene compromesso e deve quindi essere revocato, tutte le applicazioni firmate con quel certificato verranno infatti disattivate.

È preferibile inoltre acquistare un certificato di firma del codice per ogni Piattaforma di sviluppo.
Per utilizzare un unico certificato su più piattaforme è necessario un processo di conversione con l'ausilio di utilità aggiuntive.

Un certificato digitale è un file presente nel vostro computer che ha la funzione di identificarvi. Alcune applicazioni software fanno uso di questo file per provare la vostra identità ad un'altra persona o ad un altro computer. Esempi:

Quando accedete al vostro conto corrente online la vostra banca deve essere certa che siate proprio voi ad accedere ai vostri dati. Esattamente come una patente di guida o un passaporto, il certificato digitale garantisce la vostra identità presso la banca.

Quando inviate a qualcuno un'email importante, il vostro programma di posta può utilizzare un certificato digitale per firmare digitalmente la vostra email. In questo caso una firma digitale riveste due ruoli: in primo luogo dà al destinatario la certezza che l'email gli è stata inviata da voi, ed inoltre garantisce che il messaggio email non è stato alterato nell'arco di tempo trascorso tra l'invio e la ricezione.

In genere un certificato digitale contiene queste informazioni:

La vostra chiave pubblica;
I vostri nome ed indirizzo email;
La data di scadenza della chiave pubblica;
Il nome dell'Autorità di Certificazione che ha rilasciato il vostro certificato;
Il numero di serie del certificato;
La firma digitale della CA.

Le applicazioni software, le reti ed i computer possono utilizzare un certificato digitale in diversi modi: Cifratura: è un modo per proteggere le informazioni prima di inviarleda un computer all'altro. In genere, per cifrare un’email, i programmi di postausano il certificato digitale che appartiene al destinatario. Perché voiriusciate ad inviare a qualcuno un messaggio cifrato, avete bisogno della suachiave pubblica. Questo significa che è possibile scambiare email cifrate solocon interlocutori a loro volta in possesso di un certificato digitale.

Autenticazione Client: è il modo in cui il 'client' può provare la propria identità a qualcun altro o ad un computer in formato digitale. Ad esempio, le banche online hanno bisogno di essere assolutamente certe che chi cerca di accedere ad un conto corrente sia realmente il titolare del conto stesso. In questo caso, per provare la vostra identità alla banca in genere presentate un documento di identità. Nel caso di una banca online la vostra applicazione software presenta al server della banca il vostro certificato digitale. Alcuni siti web, inoltre, possono richiedervi il vostro certificato digitale prima di farvi accedere alle proprie pagine riservate (ad esempio le pagine per iscriversi a particolari servizi web).

Firma digitale: come una firma autografa, il certificato digitale è la dimostrazione che una persona ha creato o quanto meno ha dato il proprio consenso alla creazione del documento che contiene la firma. Una firma digitale offre un maggior livello di sicurezza rispetto ad una firma autografa, dal momento che la firma digitale verifica sia che il messaggio firmato è stato creato da una persona ben individuabile, sia che il messaggio non è stato modificato né intenzionalmente né accidentalmente. Inoltre, se firmate un documento, non potete, in un secondo momento, negare di aver scritto e firmato quel messaggio (Non Ripudio).

I negozi virtuali, le banche elettroniche, ed altri servizi online stanno ormai diventando sempre più comuni. Tuttavia, la vostra diffidenza nei confronti dell'effettiva tutela della privacy e della sicurezza può impedirvi di godere dei benefici di questi nuovi mezzi nella vostra vita quotidiana. Un certificato digitale può essere utile a darvi le garanzie di cui avete bisogno.

Ancora, la società per cui lavorate potrebbe avere una rete che vi richiede di avere un certificato digitale da utilizzare con le applicazioni che impiegate normalmente per il vostro lavoro. Dal momento che userete questa tecnologia sul lavoro, dovrete imparare ad usare un certificato digitale rapidamente.

I certificati digitali sono usati dai siti web e dalle applicazioni di rete per cifrare i dati che transitano tra due o più computer. La cifratura è uno strumento potente, ma da sola non può costituire una protezione sufficiente per le vostre informazioni. La cifratura, infatti, non può in alcun modo provare la vostra identità, o l'identità di qualcuno che vi invia delle informazioni cifrate. Ad esempio un broker finanziario che opera online può avere un sito che cifra i dati inviati agli utenti attraverso le pagine web. Il suo sito può addirittura richiedervi di accedere con username e password. Tuttavia, questo genere di autenticazione è facilmente intercettabile, e non può essere ritenuto un modo sicuro per garantire l'identità di qualcuno. Senza misure di protezione aggiuntive, chiunque può sostituirsi a voi online e avere accesso alle vostre informazioni strettamente private (conto corrente online e altri dati).

I certificati digitali rappresentano una valida soluzione a questo problema, offrendo un mezzo elettronico per verificare la vostra identità. I certificati digitali infatti offrono una soluzione senz'altro più completa, garantendo l'identità di tutte le parti coinvolte in una transazione.

In virtù del modo in cui i certificati digitali funzionano, essi sono in grado di garantire, tra le altre cose, il cosiddetto Non Ripudio, che fondamentalmente impedisce a chi invia un messaggio firmato con un certificato di negare di averlo inviato. Ad esempio, quando usate la vostra carta di credito, dovete firmare una ricevuta che autorizza il pagamento con la vostra carta. Dal momento che la firma della ricevuta è obbligatoria, nelle transazioni non online potete dimostrare che qualcuno ha rubato o usato impropriamente la vostra carta di credito confrontando la vostra firma con la sua. Attraverso il Non Ripudio offerto dal certificato digitale, la vostra "autorizzazione" viene data automaticamente non appena inviate il vostro certificato digitale. Se qualcuno riuscisse ad impossessarsi illecitamente del vostro certificato, non potrebbe comunque usarlo, a meno che non entri in possesso anche delle relative password e chiave privata. Ecco perché è fondamentale che nessuno al di fuori di voi conosca la password da voi scelta.

L'autenticazione client è il processo attraverso il quale un computer conferma la vostra identità. L'esempio seguente illustra il modo in cui un sito web può avvalersi dell'autenticazione client. Si badi bene tuttavia, che l'autenticazione client non si limita ai siti web. Altre applicazioni, come ad esempio le reti, possono ricorrere all’autenticazione client, ma il meccanismo rimane sempre fondamentalmente lo stesso.

Quando accedete ad un sito web che richiede un certificato digitale, il vostro browser presenta il vostro certificato al sito. Quest'ultimo quindi visualizza le informazioni contenute nel vostro certificato per 'capire' se siete autorizzati ad accedere o meno. (Spesso i certificati usati per l'autenticazione client sono chiamati certificati client.)

A seconda del vostro browser potreste dover confermare che volete presentare il vostro certificato al sito web. In genere compare una finestra di dialogo nella quale dovete inserire la password del certificato (vale a dire la password della chiave privata). Dopo aver inserito la password corretta il browser invia il vostro certificato al sito web. Ecco perché è importante per voi proteggere la password.

Se qualcuno venisse a conoscenza della password di accesso al vostro certificato, ed avesse accesso al vostro computer, questi potrebbe accedere facilmente anche alle vostre informazioni private o compiere transazioni online, di qualsiasi natura, a vostro nome.

Non appena il sito web riceve il vostro certificato, ne verifica la validità. In primo luogo, il sito controlla che il certificato non sia scaduto. Inoltre il sito può prendere in considerazione la CA che ha rilasciato il certificato. Se non la riconosce come fidata, potrà negarvi l'accesso. Ecco spiegato il motivo per cui è importante affidarsi ad una CA riconosciuta universalmente.

Il sito web può usare qualsiasi informazione contenuta nel certificato digitale nel determinare che tipo di autorizzazioni avete. In sintesi il certificato può contenere alcune o tutte le informazioni riepilogate di seguito:

La vostra chiave pubblica;
Il vostro nome;
La data di scadenza della chiave pubblica;
Il nome della CA che ha rilasciato il certificato;
Il numero di serie del certificato;
La firma digitale della CA;
Varie informazioni richieste dalla CA,

Dopo aver confermato la vostra identità, il sito web vi permette di accedere.

Alcuni siti web o reti usano le informazioni contenute nel vostro certificato per personalizzare le informazioni che vedete. Questa personalizzazione a volte è definita controllo degli accessi, ma fate attenzione a non confondere il controllo degli accessi con l'autenticazione client. Quest'ultima è semplicemente una dimostrazione della vostra identità.

Se due persone vogliono scambiarsi email cifrate hanno entrambe bisogno di un certificato. Per procurarvi la chiave pubblica di un altro utente, vi sarà sufficiente chiedergli di inviarvi un'email firmata. La chiave pubblica verrà inviata automaticamente insieme all'email, e si installerà nel vostro browser. A questo punto, se volete inviare un'email cifrata, selezionate l'opzione relativa nel programma di posta, e la chiave pubblica abbinata all'indirizzo email, sarà usata per cifrare il messaggio. Una volta ricevuto questo messaggio, il destinatario dovrà utilizzare la propria chiave privata (in genere protetta con una password) per decifrarla. La chiave privata è memorizzata localmente sulla vostra macchina, e nel caso la perdiate, non potrete leggere le email cifrate.

A partire dal 7 Aprile 2021, l'utilizzo di una nuova piattaforma Digicert permetterà di avere accesso ad un servizio più flessibile e ricco di funzionalità.

Le caratteristiche principali dei prodotti non cambiano. I nostri Certificati Client di Classe 1 e 2 continuano a dare la possibilità di firmare email e di ricevere messaggi cifrati, di essere riconosciuti dai maggiori client di posta ed anche di autenticarsi a servizi on-line.

Il cambio di piattaforma aggiunge la compatibilità per un numero maggiore di browser: oltre a Internet Explorer potranno essere utilizzati Micorsoft® Edge, Google Chrome, Apple Safari e Mozilla Firefox.

Inoltre la nuova modalità di emissione permette di scaricare il certificato utilizzando un browser (o un PC) diverso da quello utilizzato per richiederlo, nel caso lo si voglia.

La catena di certificazione cambia: nuova Root CA e nuove Intermediate CA. Anche il cambio nella catena di certificazione porta nuovi vantaggi, come ad esempio una nuova e più estesa validità delle CA, l'utilizzo di una catena moderna legata direttamente alla Certification Authority DigiCert (esce definitivamente di scena la “storica” Verisign, in via di dismissione nei prossimi mesi), e soprattutto la possibilità di avere accesso ad una catena di certificazione totalmente in SHA2 (sia Root che Intermediate), con un algoritmo di hashing che permette l'utilizzo di questi certificati anche nelle piattaforma più moderne (che richiedono infatti meccanismi di hashing più lunghi).

La nuova catena di certificazione:
Di seguito come varia la catena di certificazione.

Tipologia Precedente Nuova Download
Root CA Class1 VeriSign Class 1 Public Primary Certification Authority - G3    
Root CA Class2 VeriSign Class 2 Public Primary Certification Authority - G3    
Unified Root CA   DigiCert Assured ID Root G2 Scarica
Class 1 Intermediate Trust Italia Class 1 Consumer Individual Subscriber CA - G2 Trust Italia S.p.A. Class 1 - Public Trust CA Scarica
Class 2 Intermediate Trust Italia Class 2 Consumer Individual Subscriber CA - G2 Trust Italia S.p.A. Class 2 - Public Trust CA Scarica

Come ottengo il certificato:
A termine della richiesta la piattaforma invierà una mail che ha il duplice scopo di verificare la correttezza della mail stessa e di permettere il completamento della procedura.
All'interno del messaggio è presente un link attraverso cui accedere alla pagina per il download del certificato e tutte le istruzioni utili alla sua installazione.

Quando si utilizza un servizio con HTTPS abilitato, il sistema deve permettere o bloccare il servizio stesso in base al livello di fiducia che viene riconosciuto al certificato utilizzando il protocollo SSL/TLS: il sistema riceve un certificato SSL dal servizio a cui si sta tentando di accedere e il suo compito è di verificare che questo certificato sia stato derivato da un certificato chiamato Root Certificate, emesso da una fonte riconosciuta chiamata Certification Authority (CA).

Ogni browser o sistema operativo possiede degli archivi chiamati Root Store ed Intermediate Store dove vengono salvati tutti i certificati che sono stati già verificati perché rilasciati direttamente da una CA o perché sono già stati verificati nelle derivazioni precedenti.

Sistemi che svolgono queste verifiche sono ad esempio:
1 - Browser (ad esempio Chrome o Firefox) se si sta accedendo a un sito web.
2 - Client di posta (ad esempio Microsoft Outlook o Mozilla Thunderbird) se si riceve una mail firmata.
3 - Server web (ad esempio Apache Web Server, Microsoft IIS o Ngnix) se eseguono una autenticazione client.
4 - Server VPN per verificare l'accesso di un nuovo utente.

Il processo di "derivazione" è svolto come segue:
1 - Ottenuto il certificato del servizio si recupera l’identificativo della CA che lo ha distribuito, ovvero di un certificato intermedio.
2 - Si verifica se questo identificativo corrisponde ad un certificato presente negli "store" o se è stato inviato insieme al precedente dal servizio.
3 - Nel caso sia un certificato "intermedio" ("Intermediate CA") si reitera il processo fino ad ottenere il certificato di Root CA, riconoscibile in quanto è distribuito e verificato da sé stesso e che deve essere presente nel Root Store.

L'elenco dei certificati necessari per risalire dal certificato presentato ad un certificato di Root CA riconosciuto è la Catena di Certificazione.

La presenza di diversi certificati intermedi prima della Root CA è dettata dalla necessità di assicurare ordine e sicurezza all'intero sistema: i certificati intermedi premettono di separare il complesso dei certificati emessi in gruppi omogenei riconducibili ad uno specifico certificato emittente. Nel caso sia identificato un problema in un gruppo (e quindi di uno specifico certificato Intermedio), solo i certificati riconducibili a questo Intermedio saranno coinvolti.

Il protocollo SSL/TLS, utilizzato dai certificati, si basa sulla cifratura delle comunicazioni e degli scambi di informazioni. Per poter procedere ai processi di cifratura e de-cifratura il protocollo ha necessità di verificare la correttezza delle informazioni scambiate, e che queste non siano modificate nel transito. Per fare questo utilizza dei sistemi per calcolare un "message digest”, o "impronta del messaggio", di lunghezza fissa partendo da un messaggio di lunghezza variabile.

Questi meccanismi sono detti di "hash", e lo SHA (acronimo dell'inglese Secure Hash Algorithm) è uno di questi. Il numero dopo indica la lunghezza del digest prodotto (nel nostro caso 256 bit).

Le caratteristiche di questi meccanismi di hashing sono che è impossibile risalire al messaggio originale a partire dall'impronta, e, cosa più importante, che in nessun caso due messaggi diversi possano avere la stessa impronta.

Con l’aumentata capacità di calcolo dei computer queste condizioni sono mano a mano venute meno nei meccanismi che ritornavano un digest più corto. Per questo motivo alcuni sistemi e server (ad esempio i sistemi Apple) non validano più certificati la cui catena contenga certificati con meccanismi di hash minori allo SHA256.

Una catena completa SHA256 quindi assicura la piena compatibilità con tutti i sistemi.

Nella maggioranza dei casi queste modifiche non richiederanno alcun intervento specifico da parte degli utenti: in fase di installazione di un certificato è infatti sempre raccomandato importare il certificato con tutte le sue intermedie, e questo assicura il corretto riconoscimento e validazione del certificato dai servizi in cui viene usato.

In alcuni casi i nuovi certificati Client potrebbero non essere automaticamente riconosciuti, e quindi richiedere l'installazione della nuova catena di certificazione.

Potrebbe essere necessaria la re-installazione ad esempio:
1 - Per i servizi di posta elettronica nel caso in cui il client di posta utilizzato da una delle controparti non sia aggiornato o non lo sia il suo Root Store.
2 - Per i servizi di autenticazione, se il Server fornitore del servizio non include la Root CA o più probabilmente la nuova Intermediate CA.
3 - Per sistemi di autenticazione proprietari, che verificano in una propria lista di certificati Intermedi e di Root.

Nel caso dei servizi di posta, chi svolge la verifica è il client di posta, quindi l'importazione della catena deve essere effettuata sul client che non riconosce il certificato (potrebbe essere il proprio o quello della controparte).

Nel caso di servizi di autenticazione, innanzitutto è da verificare che nel software che viene utilizzato per accedere al servizio (browser, client VPN, etc.) siano state importate oltre al certificato anche le relative intermedie, come raccomandato. Se questo è stato correttamente eseguito, si dovrà procedere alla importazione della catena sul Server che fornisce il servizio.

Le modalità di importazione variano a seconda dei servizi, dei software e delle specifiche versioni. Raccomandiamo quindi in questi casi di fare riferimento alla documentazione fornita dal software utilizzato.

Come ottengo il certificato?
Come già in precedenza, a termine della richiesta la piattaforma invierà una mail che ha il duplice scopo di verificare la correttezza della mail stessa e di permettere il completamento della procedura.
All'interno del messaggio è presente un link attraverso cui accedere alla pagina per il download del certificato e tutte le istruzioni utili alla sua installazione.
Il nostro Servizio Clienti è a disposizione per supportare gli utenti: supporto@trustitalia.it

La Posta Elettronica Certificata (PEC) è il sistema che consente di inviare Email con Valore Legale equivalente a quello delle Raccomandate con Ricevuta di Ritorno.

Il sistema, oltre a recapitare i messaggi, produce e invia Ricevute (firmate digitalmente e marcate temporalmente) attestanti che il messaggio:

è stato spedito;
è stato consegnato;
non è stato alterato.

Il sistema inoltre, grazie ai protocolli di Sicurezza utilizzati, garantisce l'Integrità del contenuto rendendo impossibile la modifica dei messaggi inviati, eventuali allegati compresi.

Affinché un messaggio di PEC abbia pieno Valore Legale, come quello di una raccomandata con ricevuta di ritorno, è necessario naturalmente che venga inviato a un'altra casella di PEC: in altre parole anche quella del destinatario deve essere una casella di PEC.

La Posta Elettronica Certificata è uno strumento di indubbia utilità per tutti coloro che hanno l'esigenza di inviare e ricevere messaggi (ed eventuali allegati) con pieno Valore Legale, in modo sicuro, semplice e immediato, comodamente dal o sul proprio computer.

L'uso della PEC rispetto a quello di altri strumenti di comunicazione, quali fax e raccomandate tradizionali, consente un notevole Risparmio di tempo e denaro.
Il canone annuo di una Casella PEC è molto contenuto e fisso, indipendente cioè dalla quantità e dalla dimensione dei messaggi spediti e di quelli ricevuti.

Valore legale: i messaggi di Posta Elettronica Certificata, a differenza da quelli della tradizionale posta elettronica, hanno pieno Valore Legale. Le loro ricevute possono essere usate come prove dell'invio, della ricezione e anche del contenuto del messaggio inviato. Le principali informazioni riguardanti la trasmissione e la consegna di un messaggio vengono conservate dai Gestori di PEC per 30 mesi e sono anch’esse opponibili a terzi.

Sicurezza: il servizio utilizza i protocolli sicuri POP3s, IMAPs, SMTPs ed HTTPs.
Tutte le comunicazioni sono Crittografate e Firmate Digitalmente, quindi protette, e garantiscono l’Integrità dei messaggi inviati e ricevuti.

Semplicità: il servizio di Posta Elettronica Certificata si usa come la normale posta elettronica, cioè sia tramite programma Client (come, per esempio, Outlook Express o Mozilla Thunderbird) che tramite Webmail.

Comodità: una casella PEC può essere utilizzata tramite qualsiasi computer collegato a Internet.

Risparmio: confrontando il costo di una casella PEC con quello degli strumenti alternativi, quali fax e raccomandate tradizionali, appare subito evidente come il Risparmio, sia in termini economici che di tempo, è notevole.

Trasmissione immediata: ogni PEC viene normalmente consegnata pochi secondi dopo l'invio.

Costo fisso: il costo di una casella PEC è fisso e non prevede oneri aggiuntivi in base all'utilizzo.

Nessun Virus e nessuna Spam: l'identificazione certa del mittente di ogni messaggio ricevuto e il fatto che non si possono ricevere messaggi non certificati, rendono il servizio PEC pressoché immune dalla fastidiosa posta spazzatura.

La Posta Elettronica Certificata si utilizza come la normale posta elettronica, cioè tramite un programma Client (come, per esempio, Outlook Express o Mozilla Thunderbird) oppure tramite Webmail.

Il Verified Mark Certificate è un certificato di nuova tecnologia che consente di visualizzare accanto al campo "mittente", nelle mail inviate ai propri clienti, il proprio logo aziendale, registrato e autenticato, sui più diffusi client di posta. Conferma lo stato DMARC del tuo dominio e l'identità autenticata della tua organizzazione.

Prima di richiedere un certificato VMC dovresti verificare che:
1. Il dominio per il quale viene richiesto il certificato deve essere DMARC compliant.
2. Il logo della tua organizzazione deve essere un marchio legalmente registrato.
3. Il logo che sarà utilizzato nel certificato VMC deve essere in formato SVG.

Il processo di validazione per i VMC si basa sui passaggi adottati per i certificati SSL/TLS con Extended Validation, ai quali si aggiungono nuovi step, che includono:

1. Confermare che il marchio della tua azienda è legalmente registrato.
2. Fornire copie autenticate dei documenti di identità personale che confermano l'identità della persona presso l'organizzazione che richiede il VMC.
3. Svolgere una video call con un membro del team di validazione di DigiCert per confermare che la tua identità corrisponda a quella presente nei documenti.