certification practice statement - actalis.it · certification practice statement certificati ssl...
TRANSCRIPT
Certification Practice Statement
Certificati SSL Server e Code Signing
Versione: 3.0
Data: 28 Agosto 2017
Certification Practice Statement
Certificati SSL Server e Code Signing
Redatto da: Adriano Santoni
Responsabile Sicurezza
Data Verificato da: Rosalia Valsecchi
Responsabile Certificazione
Data Verificato da: Marco Grassi
Responsabile Esercizio
Data Verificato da: Roberta Giommoni
Responsabile Auditing
Data Approvato da: Giorgio Girelli
Direttore Generale
Data
Codice documento:
CAACT-03-01-04
Distribuzione:
PUBBLICA
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 2 di 55 28 Agosto 2017
Storia delle modifiche
DATA VERS. PARAGRAFI MODIFICHE AUTORE
14 dicembre 2005 1 - Prima versione del documento FP
24 giugno 2009 2 tutti Revisione dell’intero documento; ristrutturazione secondo RFC 3647
FP, AS
19 novembre 2009 2.0.1 1.3.1 Cambiato il nome del Presidente AS
13 maggio 2010 2.0.2 3.4 Rimossa la frase relativa all’eventuale inserimento di indirizzi IP privati nei certificati (possibilità non prevista)
AS
18 maggio 2010 2.0.3 4.2, 8.1, 8.2, 8.4, 8.5, 8.6,
9.5.2, 9.8
Precisazioni e integrazioni relative alle RA
AS
18 maggio 2010 2.0.3 1.3.1 Aggiornato l’indirizzo di Actalis; corretto il nome del Presidente
AS
23 giugno 2011 2.0.4 1.3.1, 3.1, 4.1 Modificato il rappresentante legale di Actalis. Aggiunti chiarimenti relativi a I&A
e verifiche per i certificati wildcard e multi-SAN
AS
28 settembre 2011 2.1.0 Tutti Introdotta PKI a due livelli. Aggiunti dettagli sulla gestione delle chiavi di Root CA e Sub CA. Necessità di autenticazione a due fattori per le utenze che consen-tono l’emissione dei certificati. I numeri di serie devono includere almeno 8 byte random. SHA256 usato per la firma dei
certificati e delle CRL. Aggiornate lunghezze minime delle chiavi.
AS
19 settembre 2013 2.2.0 Tutti Aggiornato frontespizio secondo l’attuale organizzazione. Precisato in §5.1 che il
data center di Actalis è gestito da Aruba. Diverse revisioni e precisazioni per conformità alle linee guida del CAB
Forum (BR+EVGL) e alla norma ETSI TS 102 042.
AS
8 ottobre 2013 2.2.1 Tutti Dichiarazione esplicita di rispetto dei [BR] e delle [EVGL]. Integrazione elenco delle circostanze per la revoca. Revoca imme-
diata per attività criminali svolte col certi-ficato. Dual control nell’emissione dei
certificati. Altre precisazioni.
AS
16 ottobre 2013 2.2.2 3.6, 7.1, 6.10.3 Correzione refusi. La massima durata dei certificati SSL Server EV è 24 mesi. Il tito-
lare deve assicurare la riservatezza del PIN o password di attivazione della
propria chiave. Policy OID = “anyPolicy” nel certificato della SubCA.
AS
21 ottobre 2013 2.2.3 4.9.4, 9.5.3 Precisazioni sulla revoca. Precisazioni sugli obblighi del titolare.
AS
13 novembre 2013 2.2.4 Diversi Aggiornato il nome dell’Amministratore di Actalid nel par 1.3.1. Nuovo par 4.13 su
segnalazione problemi sui certificati e relativa gestione. Modifica al par 1.3.2
per introduzione Enterprise RA. Introdotti profili OV nel par 1.4 e nel capitolo 7.
Modificato il 3.1 per maggiore chiarezza. Precisazioni nel par 3.3 sulle verifiche.
AS
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 3 di 55 28 Agosto 2017
Precisazioni sull’uso di CNames per l’accesso a CRL e al servizio OCSP.
14 febbraio 2014 2.2.5 Diversi Precisazione sulla conformità ai requisiti del CAB Forum all’inizio del capitolo 3.
Precisazione sugli IDN.
AS
03 settembre 2014 2.2.6 3.1.1, 4.13, 6.3.3
Precisato che gli hostname non sono ammessi nei certificati per Code Signing e
che un certificato per Code Signing emesso erroneamente con un hostname
all’interno sarà revocato. Possibilità di inviare segnalazioni ad Actalis anche per telefono. La lunghezza chiavi utente di
1024 bit non è più consentita.
AS
20 ottobre 2014 2.2.7 Diversi Supporto per i certificati di classe DV (Domain Validated). Firma digitale accet-tata come mezzo per venificare l’identità individuale. Correzione di refusi e alcune
precisazioni.
AS
9 dicembre 2014 2.3 Diversi Correzione refusi. AS
13 marzo 2015 2.4 Diversi Nuovo paragrafo 1.3.5 (rivenditori). Correzioni e precisazioni nel §1.4 (uso dei certificati), nel §4.1 (richiesta del certifi-
cato) e nel 4.9.6 (procedura per la sospensione o revoca).
AS
1 aprile 2015 2.4.1 Diversi Precisazioni sugli URL delle CRL e del servizio OCSP. Precisazioni su
Comunicazioni e assistenza. Ampliate le possibilità per la verifica di controllo del
dominio. Spostato o rinominati alcuni paragrafi per maggior chiarezza.
AS
23 giugno 2015 2.5 Diversi SubCA dedicata per i certificati di classe EV. Informazioni di Certificate Trans-
parency nei certificati di classe EV. Aggiunti policy OID del CAB Forum ai
certificati delle varie classi.
AS
22 marzo 2016 2.6 1.3.1, 4.13 Cambiati l’indirizzo di Actalis e i numeri di telefono. Modifiche nel frontespizio a seguito dei cambiamenti organizzativi. Cambiato n. telefono per segnalazione
problemi sui certificato.
AS
5 ottobre 2016 2.7 3.4, 1.4 Precisazione sui CAA records. Precisazione sui domini .onion.
AS
6 ottobre 2016 2.8 1.3, 7 Precisazioni sulle CA. Introduzione cAIssuers nella estensione AIA. SubCA dedicata per SSL Server di classe DV.
AS
24 Luglio 2017 2.9 1.7, 3.2, 4.3 Cambiato da ETSI 102 042 a 319 411 nei Riferimenti. Aggiunto controllo dei CAA
Record. Per certificati EV, firma autografa accettabile se autenticata da notaio.
Chiarimenti sulla verifica di autenticità e sulle informazioni non verificate.
AS
28 Agosto 2017 3.0 4.3, 7.3 Correzione refusi. Nuovo paragrafo 7.3 con il profilo delle risposte OCSP.
AS
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 4 di 55 28 Agosto 2017
Sommario
1 INTRODUZIONE ........................................................................................................................................ 8 1.1 SCOPO DEL DOCUMENTO................................................................................................................................ 8 1.2 IDENTIFICAZIONE DEL DOCUMENTO .................................................................................................................. 8 1.3 PARTECIPANTI ALLA PKI ................................................................................................................................. 9
1.3.1 Certification Authorities ................................................................................................................... 9 1.3.2 Registration Authorities ................................................................................................................. 10 1.3.3 Utenti finali (titolari) ...................................................................................................................... 11 1.3.4 Relying parties ............................................................................................................................... 11 1.3.5 Rivenditori ...................................................................................................................................... 11
1.4 USO DEI CERTIFICATI .................................................................................................................................... 11 1.5 AMMINISTRAZIONE DEL CPS ......................................................................................................................... 12 1.6 DEFINIZIONI E ACRONIMI .............................................................................................................................. 12 1.7 RIFERIMENTI .............................................................................................................................................. 13
2 PUBBLICAZIONI E REPOSITORY ................................................................................................................14 2.1 GESTIONE DEL REPOSITORY ........................................................................................................................... 14 2.2 INFORMAZIONI PUBBLICATE .......................................................................................................................... 14 2.3 TEMPI E FREQUENZA DELLE PUBBLICAZIONI ...................................................................................................... 14 2.4 CONTROLLO DEGLI ACCESSI ........................................................................................................................... 14
3 IDENTIFICAZIONE ED AUTENTICAZIONE (I&A) .........................................................................................15 3.1 REGOLE DI NAMING ..................................................................................................................................... 15
3.1.1 Per tutte le classi di certificato....................................................................................................... 15 3.1.2 Per i certificati di classe EV ............................................................................................................ 16 3.1.3 Per i certificati di classe DV ............................................................................................................ 16 3.1.4 Internationalized Domain Names (IDN) ......................................................................................... 16
3.2 VALIDAZIONE INIZIALE DELL’IDENTITÀ .............................................................................................................. 16 3.2.1 Dimostrazione del possesso della chiave privata ........................................................................... 16 3.2.2 Autenticazione dell’organizzazione richiedente ............................................................................ 16 3.2.3 Autenticazione delle identità individuali ........................................................................................ 17 3.2.4 Informazioni del titolare non verificate ......................................................................................... 17 3.2.5 Verifica dell’autorizzazione ............................................................................................................ 17 3.2.6 Criteri di interoperabilità ............................................................................................................... 18
3.3 ULTERIORI VERIFICHE SVOLTE DALLA CA .......................................................................................................... 18 3.3.1 Per tutte le classi di certificato SSL Server ..................................................................................... 18 3.3.2 Per i certificati di classe EV ............................................................................................................ 19
3.4 INFORMAZIONI NON VERIFICATE DALLA CA ...................................................................................................... 19 3.5 I&A PER LE RICHIESTE DI RINNOVO ................................................................................................................. 20 3.6 I&A PER LE RICHIESTE DI SOSPENSIONE O REVOCA ............................................................................................. 20
4 REQUISITI OPERATIVI DI GESTIONE DEI CERTIFICATI ...............................................................................21 4.1 RICHIESTA DEL CERTIFICATO .......................................................................................................................... 21 4.2 ELABORAZIONE DELLE RICHIESTE .................................................................................................................... 22 4.3 EMISSIONE DEL CERTIFICATO ......................................................................................................................... 23 4.4 ACCETTAZIONE DEL CERTIFICATO .................................................................................................................... 23 4.5 USO DELLA COPPIA DI CHIAVI E DEL CERTIFICATO ............................................................................................... 23 4.6 RINNOVO DEL CERTIFICATO ........................................................................................................................... 24 4.7 RIGENERAZIONE DELLA CHIAVE ...................................................................................................................... 24 4.8 MODIFICA DEL CERTIFICATO .......................................................................................................................... 24 4.9 SOSPENSIONE E REVOCA DEL CERTIFICATO ........................................................................................................ 24
4.9.1 Circostanze per la sospensione ...................................................................................................... 24 4.9.2 Chi può richiedere la sospensione .................................................................................................. 25 4.9.3 Procedura per la sospensione ........................................................................................................ 25 4.9.4 Circostanze per la revoca ............................................................................................................... 25
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 5 di 55 28 Agosto 2017
4.9.5 Chi può richiedere la revoca ........................................................................................................... 26 4.9.6 Procedura per la sospensione o revoca ......................................................................................... 26 4.9.7 Frequenza di emissione della CRL .................................................................................................. 27
4.10 SERVIZI INFORMATIVI SULLO STATO DEL CERTIFICATO ......................................................................................... 27 4.10.1 Caratteristiche operative ............................................................................................................... 27 4.10.2 Disponibilità del servizio ................................................................................................................ 28
4.11 CESSAZIONE DEL CONTRATTO ........................................................................................................................ 28 4.12 KEY ESCROW E KEY RECOVERY........................................................................................................................ 28 4.13 SEGNALAZIONE DI PROBLEMI ......................................................................................................................... 28
5 MISURE DI SICUREZZA FISICA ED OPERATIVA ..........................................................................................30 5.1 SICUREZZA FISICA ........................................................................................................................................ 30 5.2 SICUREZZA DELLE PROCEDURE ....................................................................................................................... 30 5.3 SICUREZZA DEL PERSONALE ........................................................................................................................... 31 5.4 REGISTRAZIONE DEGLI EVENTI ....................................................................................................................... 31 5.5 ARCHIVIAZIONE DEI DATI .............................................................................................................................. 31 5.6 RINNOVO DELLA CHIAVE DELLA CA ................................................................................................................. 31
5.6.1 Root CA .......................................................................................................................................... 31 5.6.2 SubCA ............................................................................................................................................. 31
5.7 COPIE DI SICUREZZA (BACKUP) ....................................................................................................................... 31 5.8 COMPROMISSIONE E DISASTER RECOVERY ........................................................................................................ 32 5.9 CESSAZIONE DELLA CA ................................................................................................................................. 32
6 MISURE DI SICUREZZA TECNICA ..............................................................................................................33 6.1 GENERAZIONE DELLE CHIAVI .......................................................................................................................... 33
6.1.1 Root CA .......................................................................................................................................... 33 6.1.2 Sub CA ............................................................................................................................................ 33 6.1.3 Titolari............................................................................................................................................ 33
6.2 DISTRIBUZIONE DELLA CHIAVE PUBBLICA .......................................................................................................... 33 6.2.1 Root CA .......................................................................................................................................... 33 6.2.2 Sub CA ............................................................................................................................................ 33 6.2.3 Titolari............................................................................................................................................ 33
6.3 LUNGHEZZA DELLE CHIAVI ............................................................................................................................. 34 6.3.1 Root CA .......................................................................................................................................... 34 6.3.2 Sub CA ............................................................................................................................................ 34 6.3.3 Titolari............................................................................................................................................ 34
6.4 PARAMETRI DI GENERAZIONE E QUALITÀ DELLE CHIAVI ........................................................................................ 34 6.4.1 Root CA .......................................................................................................................................... 34 6.4.2 Sub CA ............................................................................................................................................ 34 6.4.3 Titolari............................................................................................................................................ 34
6.5 KEY USAGE (ESTENSIONE X.509V3) ............................................................................................................... 34 6.5.1 Root CA .......................................................................................................................................... 34 6.5.2 Sub CA ............................................................................................................................................ 34 6.5.3 Titolari............................................................................................................................................ 35
6.6 PROTEZIONE DELLA CHIAVE PRIVATA ............................................................................................................... 35 6.6.1 Root CA .......................................................................................................................................... 35 6.6.2 Sub CA ............................................................................................................................................ 35 6.6.3 Titolari............................................................................................................................................ 35
6.7 STANDARD DI SICUREZZA DEI MODULI CRITTOGRAFICI ......................................................................................... 35 6.8 MULTI-PERSON CONTROL (N DI M) DELLA CHIAVE PRIVATA ................................................................................ 35
6.8.1 Root CA .......................................................................................................................................... 35 6.8.2 Sub CA ............................................................................................................................................ 35 6.8.3 Titolari............................................................................................................................................ 35
6.9 BACKUP E RIPRISTINO DELLA CHIAVE PRIVATA ................................................................................................... 35 6.9.1 Root CA .......................................................................................................................................... 35 6.9.2 Sub CA ............................................................................................................................................ 36 6.9.3 Titolari............................................................................................................................................ 36
6.10 DATI DI ATTIVAZIONE DELLA CHIAVE ................................................................................................................ 36
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 6 di 55 28 Agosto 2017
6.10.1 Root CA .......................................................................................................................................... 36 6.10.2 Sub CA ............................................................................................................................................ 36 6.10.3 Titolari............................................................................................................................................ 36
6.11 REQUISITI DI SICUREZZA DEGLI ELABORATORI .................................................................................................... 36 6.12 SICUREZZA DI RETE ...................................................................................................................................... 37 6.13 RIFERIMENTO TEMPORALE ............................................................................................................................ 37
7 PROFILO DEI CERTIFICATI, DELLE CRL E OCSP ...........................................................................................38 7.1 PROFILO DEL CERTIFICATO ............................................................................................................................ 38
7.1.1 Root CA .......................................................................................................................................... 38 7.1.2 Sub CA per certificati di classe DV .................................................................................................. 38 7.1.3 Sub CA per certificati di classe OV ................................................................................................. 39 7.1.4 Sub CA per certificati di classe EV .................................................................................................. 40 7.1.5 SSL Server EV (Extended Validation) .............................................................................................. 41 7.1.6 Code Signing EV (Extended Validation).......................................................................................... 42 7.1.7 SSL Server OV (Organization Validated) ........................................................................................ 42 7.1.8 SSL Server Wildcard OV (Organization Validated) ......................................................................... 43 7.1.9 Code Signing OV (Organization Validated) .................................................................................... 44 7.1.10 SSL Server DV (Domain Validated) ................................................................................................. 45 7.1.11 SSL Server Wildcard DV (Domain Validated) ................................................................................. 46
7.2 PROFILO DELLA CRL .................................................................................................................................... 46 7.3 PROFILO OCSP .......................................................................................................................................... 47
8 VERIFICHE DI CONFORMITÀ ....................................................................................................................47 8.1 FREQUENZA E CIRCOSTANZE DALLE VERIFICHE ................................................................................................... 47
8.1.1 Root CA .......................................................................................................................................... 47 8.1.2 Sub CA ............................................................................................................................................ 47 8.1.3 Registration Authorities ................................................................................................................. 47
8.2 IDENTITÀ E QUALIFICAZIONE DEGLI ISPETTORI ................................................................................................... 48 8.3 RELAZIONI TRA LA CA E GLI ISPETTORI ............................................................................................................. 48 8.4 ARGOMENTI COPERTI DALLE VERIFICHE ............................................................................................................ 48 8.5 AZIONI CONSEGUENTI ALLE NON-CONFORMITÀ ................................................................................................. 48 8.6 COMUNICAZIONE DEI RISULTATI DELLE VERIFICHE .............................................................................................. 48
9 CONDIZIONI GENERALI DEL SERVIZIO ......................................................................................................49 9.1 TARIFFE DEL SERVIZIO .................................................................................................................................. 49 9.2 RESPONSABILITÀ FINANZIARIA ....................................................................................................................... 49 9.3 TUTELA DELLA RISERVATEZZA E TRATTAMENTO DEI DATI PERSONALI ...................................................................... 49
9.3.1 Informativa ai sensi del D.Lgs. 196/03 ........................................................................................... 49 9.3.2 Archivi contenenti dati personali ................................................................................................... 49 9.3.3 Misure di tutela della riservatezza ................................................................................................. 50
9.4 DIRITTI DI PROPRIETÀ INTELLETTUALE .............................................................................................................. 50 9.5 OBBLIGHI E GARANZIE .................................................................................................................................. 50
9.5.1 Certification Authority ................................................................................................................... 50 9.5.2 Registration Authority ................................................................................................................... 51 9.5.3 Titolari di certificati ........................................................................................................................ 51 9.5.4 Relying party .................................................................................................................................. 52
9.6 ESCLUSIONE DI GARANZIE ............................................................................................................................. 52 9.7 LIMITAZIONI DI RESPONSABILITÀ .................................................................................................................... 52 9.8 RISARCIMENTI ............................................................................................................................................ 52 9.9 DURATA E TERMINAZIONE ............................................................................................................................ 52 9.10 COMUNICAZIONI E ASSISTENZA ...................................................................................................................... 53 9.11 EMENDAMENTI .......................................................................................................................................... 53 9.12 RISOLUZIONE DELLE DISPUTE ......................................................................................................................... 53 9.13 LEGGE APPLICABILE ..................................................................................................................................... 53 9.14 CONFORMITÀ CON LE NORME APPLICABILI ....................................................................................................... 53 9.15 FORZA MAGGIORE ...................................................................................................................................... 53 9.16 LIVELLI DI SERVIZIO ...................................................................................................................................... 53
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 7 di 55 28 Agosto 2017
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 8 di 55 28 Agosto 2017
1 Introduzione
1.1 Scopo del documento
Actalis S.p.A., primario certificatore attivo dal 2002, accreditato presso l’AgID ai sensi della Direttiva Europea
sulle Firme Elettroniche, quindi secondo il Regolamento EiDAS (EU n.910/2014), offre diverse tipologie di certi-
ficati e relativi servizi di gestione, oltre a diversi altri servizi e soluzioni (www.actalis.it).
Un certificato lega una chiave pubblica ad un insieme d’informazioni che identificano un soggetto (individuo od
organizzazione). Tale soggetto, titolare del certificato, possiede ed utilizza la corrispondente chiave privata. Il
certificato viene generato e fornito al titolare da una terza parte fidata detta Certification Authority (CA). Il cer-
tificato è firmato digitalmente dalla CA.
L’affidabilità di un certificato, ovvero l’associazione certa tra una data chiave pubblica ed il soggetto identifi-
cato, dipende anche dalle procedure operative del certificatore , dagli obblighi e responsabilità che si assu-
mono certificatore e titolare, dalle misure di sicurezza fisiche e logiche del certificatore. Tali aspetti sono de-
scritti in un documento pubblico chiamato Certification Practice Statement (CPS).
Questo documento è il CPS di Actalis relativo all’emissione e gestione di due tipi di certificati:
certificati per SSL Server
certificati per Code Signing
La struttura di questo CPS si basa sulla specifica pubblica [RFC 3647].
Nell’ambito del servizio di CA descritto in questo CPS, Actalis rispetta la versione corrente dei Baseline Requi-
rements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates del CA/Browser
Forum pubblicata su http://www.cabforum.org. In caso di conflitto tra il presente documento e tali Requisiti,
questi ultimi hanno la precedenza.
Inoltre, per quanto riguarda i certificati di classe EV (vedere la sezione 1.4), Actalis rispetta la versione corrente
delle Guidelines for Issuance and Management of Extended Validation Certificates del CA/Browser Forum,
pubblicata su http://www.cabforum.org. In caso di conflitto tra il presente documento e tali Linee Guida, que-
ste ultime hanno la precedenza.
1.2 Identificazione del documento
Questo documento è il Certification Practice Statement (CPS) relativo ai Certificati SSL Server e Code Signing
emessi da Actalis S.p.A. La versione e la data di ultima revisione del documento sono indicate nella sua prima
pagina. Questo documento è pubblicato sul sito web di Actalis in due lingue: Italiano e Inglese. Nel caso di dif-
formità tra le due versioni, fa fede la versione in Italiano.
Actalis emette anche certificati di altro tipo (es. SSL Client, S/MIME) nel rispetto di policy descritte in documenti
separati. Tali policy possono fare riferimento a questo CPS per quanto riguarda gli aspetti comuni (per es. infra-
struttura, organizzazione, sicurezza fisica e operativa, Root CA, ecc.).
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 9 di 55 28 Agosto 2017
1.3 Partecipanti alla PKI
1.3.1 Certification Authorities
La Certification Authority (CA) è il soggetto terzo e fidato che emette i certificati, firmandoli con la propria chia-
ve privata (chiave di CA). La CA, inoltre, gestisce lo stato dei certificati.
La PKI (Public Key Infrastructure) di Actalis su cui si basa il servizio di emissione e gestione dei certificati SSL
Server e Code Signing è organizzata su due livelli, come mostrato nello schema seguente:
Root CA
Sub CA 1 Sub CA 2 Sub CA ...
La Root CA è usata esclusivamente per emettere i certificati di SubCA e le relative CRL, ed è mantenuta off-line
quando non in uso. Le Sub CA sono le CA che emettono i certificati degli utenti finali.
Nell’ambito del servizio qui descritto, il ruolo di Root CA è ricoperto dalla società Actalis S.p.A. (in seguito solo
“Actalis”), identificata come segue:
Denominazione sociale: Actalis S.p.A.
Indirizzo della sede legale: Via S. Clemente 53 – 24036 Ponte San Pietro (BG)
Legale rappresentante: Simone Braccagni (Amministratore Delegato)
P.IVA e Codice Fiscale: 03358520967
N° di telefono (centralino): +39 0575.050.350
DUNS number: 440-489-735
ISO Object Identifier (OID): 1.3.159
Sito web generale (informativo): http://www.actalis.it
Sito web del servizio di certificazione: https://portal.actalis.it
Indirizzo di posta elettronica (informativo): [email protected]
1.3.1.1 Root Certification Authority
Come già detto, il ruolo di Root CA è gestito da Actalis S.p.A. Alla data di revisione del presente CPS, le chiavi di
Root CA di Actalis sono quelle identificate di seguito; per ulteriori dettagli vedere anche il capitolo 7.
Subject DN Subject Key ID netBefore notAfter
CN = Actalis Authentication Root CA
O = Actalis S.p.A./03358520967
L = Milan
C = IT
52 d8 88 3a c8
9f 78 66 ed 89
f3 7b 38 70 94
c9 02 02 36 d0
22 settembre 2011 22 settembre 2030
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 10 di 55 28 Agosto 2017
1.3.1.2 Subordinate Certification Authority
Alla data di revisione del presente CPS, le Subordinate CA gestite da Actalis sono quelle identificate di seguito;
per ulteriori dettagli vedere anche il capitolo 7.
Subject DN Subject Key ID netBefore notAfter
CN = Actalis Authentication CA G3
O = Actalis S.p.A./03358520967
L = Milano
S = Milano
C = IT
AA AA FD CA 8C 1D
4D F1 2E 83 E1 06
FC FA 8E EA 0E 23
AE 3D
13 febbraio 2014 13 febbraio 2024
CN = Actalis Extended Validation Server CA G1
O = Actalis S.p.A./03358520967
L = Milano
S = Milano
C = IT
61 C1 E4 86 1E 4D
6D 74 74 BC D9 97
3B 31 71 78 CB 3F
9F DC
14 maggio 2015 14 maggio 2030
CN = Actalis Domain Validation Server CA G1
O = Actalis S.p.A./03358520967
L = Ponte San Pietro
S = Bergamo
C = IT
1B 42 7F 5C 45 7E
FF 7E 1E 1E 41 9C
F3 AD AE 35 C6 65
EB C5
6 ottobre 2016 22 settembre 2030
CN = Actalis Client Authentication CA G1
O = Actalis S.p.A./03358520967
L = Milano
S = Milano
C = IT
7E 60 FC F8 6C A7
3D 3D D7 AE 93 A1
79 02 8F B3 74 29
3B F5
14 maggio 2015 14 maggio 2030
Possono essere rilasciati certificati di SubCA, sotto la Root CA di Actalis, per CA esterne (ossia non gestite da
Actalis) previa stipula di un contratto col quale i gestori di tali CA si impegnano, tra l’altro, a rispettare i Baseli-
ne Requirements del CAB Forum [BR]1.
A meno che non siano “technically constrained” come descritto nel par. 7.1.5 dei [BR], tali SubCA devono sotto-
porsi annualmente ad un audit di conformità ai [BR] da parte di un auditor indipendente e qualificato, nel ri-
spetto dei requisiti di cui al cap. 8 dei [BR], e fornire tempestivamente ad Actalis l’attestazione di conformità
emessa annualmente dall’auditor. In mancanza di tale attestazione, il certificato di SubCA sarà revocato.
1.3.2 Registration Authorities
La Registration Authority (RA) è la persona, struttura od organizzazione che svolge le attività di:
accoglimento e validazione delle richieste di emissione e gestione dei certificati;
registrazione del soggetto richiedente e dell’organizzazione di appartenenza;
autorizzazione all’emissione, da parte della CA, del certificato richiesto.
Per i certificati di classe EV (Extended Validation), l’attività di RA è svolta esclusivamente da Actalis.
Per i certificati di classe OV (Organization Validated) e DV (Domain Validated), l’attività di RA può essere svolta
dal Titolare in qualità di “Enterprise RA”, ove ne sussistano le condizioni, limitatamente ai domini Internet di
pertinenza del Titolare.
1 Non è prevista l’emissione di certificati di classe EV da parte di SubCA esterne, sotto la Root CA di Actalis.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 11 di 55 28 Agosto 2017
1.3.3 Utenti finali (titolari)
Gli utenti finali del servizio, ovvero i titolari dei certificati, sono le organizzazioni o enti che richiedono un certi-
ficato per SSL Server o per la firma digitale di software (code signing) e che detengono la corrispondente chiave
privata. In particolare, con riferimento alla classificazione riportata nel §7.2 delle [EVGL], Actalis fornisce certifi-
cati ai seguenti tipi di organizzazioni:
Private Organization (aziende private)
Government Entity (enti pubblici)
Con “titolare del certificato” si intende l’entità chiamata “Subscriber” o “Subject” in [BR] ed [EVGL].
Nel caso dei certificati di classe OV ed EV, il titolare del certificato è sempre un’organizzazione (persona giuridi-
ca). Solo nel caso dei certificati di classe DV, il titolare può essere una persona fisica.
Il contratto con la CA viene normalmente stipulato col soggetto che diverrà titolare del certificato, il quale dun-
que coincide col cliente (“Customer”); è comunque ammesso che il cliente agisca in nome e per conto del tito-
lare del certificato, circostanza che deve essere dimostrata in sede di richiesta (vedere la sezione 3.2.2).
1.3.4 Relying parties
Le “Relying Parties” sono tutti i soggetti che fanno affidamento sulle informazioni contenute nel certificato. Nel
caso dei certificati per SSL Server, si tratta degli utenti del sito web interessato. Nel caso dei certificati per Code
Signing, si tratta degli utilizzatori del software firmato.
1.3.5 Rivenditori
I certificati possono essere forniti anche attraverso rivenditori (business partner), i quali possono svolgere an-
che l’attività di Registration Authority, secondo gli accordi con la CA.
1.4 Uso dei certificati
I certificati SSL Server sono usati per abilitare il protocollo TLS/SSL su uno o più siti web.
I certificati di Code Signing sono usati per validare la firma digitale di codice eseguibile.
Ogni altro uso dei certificati emessi da Actalis sulla base di questo CPS è proibito e può comportare, qualora Ac-
talis ne venga a conoscenza, la revoca del certificato.
Non è prevista l’emissione di certificati SSL Server per server attestati sul dominio .onion.
Un elenco delle piattaforme e browser dove i certificati emessi secondo questo CPS sono riconosciuti (trusted)
è pubblicato sul sito web di Actalis all’indirizzo https://www.actalis.it/prodotti/certificati-ssl.aspx. Si assume
che i clienti del servizio consultino tale elenco prima di richiedere i certificati.
Si assume inoltre che il cliente possegga le competenze e gli strumenti necessari per l’uso del certificato. Diver-
samente, Actalis è disponibile a fornire assistenza e consulenza a tal fine.
La seguente tabella indica le classi e policy dei certificati emessi in conformità al presente CPS, e i requisiti del
CAB Forum applicabili a ciascuna tipologia. Ogni policy è identificata da un distinto OID (Object IDentifier) sotto
l’arco di Actalis (1.3.159):
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 12 di 55 28 Agosto 2017
Classe Policy di certificato OID Requisiti CABF
EV SSL Server EV (Extended Validation) 1.3.159.1.17.1 [BR], [EVGL]
EV Code Signing EV (Extended Validation) 1.3.159.1.18.1 [BR], [EVGL]
OV SSL Server WildCard OV (Organization Validated) 1.3.159.1.19.1 [BR]
OV SSL Server OV (Organization Validated) 1.3.159.1.20.1 [BR]
OV Code Signing OV (Organization Validated) 1.3.159.1.21.1 [BR]
DV SSL Server DV (Domain Validated) 1.3.159.1.22.1 [BR]
DV SSL Server WildCard DV (Domain Validated) 1.3.159.1.23.1 [BR]
Lo OID che identifica la policy del certificato è contenuto nell’estensione CertificatePolicies del certificato, come
dettagliato nella sezione 7. L’estensione contiene anche i policy OID definiti dallo stesso CAB Forum, secondo la
classe del certificato.
1.5 Amministrazione del CPS
Questo CPS è redatto, pubblicato ed aggiornato da Actalis S.p.A.
Richieste di informazioni o chiarimenti sul presente CPS possono essere inoltrate tramite posta elettronica
all’indirizzo [email protected].
Actalis attua una revisione periodica dei processi di certificazione che include e responsabilità per la manu-
tenzione del CPS. Questo CPS e le certificate policy (CP) qui definite sono approvate dalla Direzione di Actalis,
su raccomandazione del Responsabile del CPS, previo consulto con le funzioni aziendali interessate, tenendo
conto di quanto indicato nella norma [POLREQ].
1.6 Definizioni e acronimi
AgID Agenzia per l’Italia Digitale (ex DigitPA)
ARL Authority Revocation List
CA Certification Authority
CCIAA Camera di Commercio, Industria, Agricoltura e Artigianato
CNAME Canonical Name
CPS Certification Practice Statement
CRL Certificate Revocation List
CSR Certificate Signing Request
DN Distinguished Name
DV Domain (Control) Validated
EV Extended Validation
FIPS Federal Information Processing Standard
FQDN Fully Qualified Domain Name
HSM Hardware Security Module
HTTP Hyper-Text Transfer Protocol
I&A Identificazione e Autenticazione
IDN Internationalized Domain Name
ISO International Standards Organization
LDAP Lightweight Directory Access Protocol
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 13 di 55 28 Agosto 2017
OCSP On-line Certificate Status Protocol
OID Object Identifier
OV Organization Validated
PDF Portable Document Format
PKI Public Key Infrastructure
RA Registration Authority
SAN SubjectAlternativeNames
SSL Secure Sockets Layer
TLS Transport layer Security
TVCC TV a Circuito Chiuso
UPS Uninterruptable Power Supply
VMD Video Motion Detection
1.7 Riferimenti
[DLGS196] Decreto Legislativo 30 giugno 2003, n. 196, “Codice in materia di protezione dei dati personali”,
pubblicato nel Supplemento Ordinario n.123 della Gazzetta Ufficiale n. 174, 29 luglio 2003.
[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)",
RFC 2251, December 1997. (http://www.ietf.org/rfc/rfc2251.txt)
[RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1.5", RFC 2314, March 1998.
(http://www.ietf.org/rfc/rfc2314.txt)
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet
Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, June 2013.
(http://www.ietf.org/rfc/rfc6960.txt)
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee,
"Hypertext Transfer Protocol, HTTP/1.1", RFC 2616, June 1999.
(http://www.ietf.org/rfc/rfc2616.txt)
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. (http://www.ietf.org/rfc/rfc2818.txt)
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key
Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November
2003. (http://www.ietf.org/rfc/rfc3647.txt)
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public
Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May
2008. (http://www.ietf.org/rfc/rfc5280.txt)
[CT] Laurie, B., Kasper, E., “Certificate Transparency”, RFC 6962, June 2013.
(http://www.ietf.org/rfc/rfc6962.txt)
[X.509] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, Information technology - Open
Systems Interconnection - The Directory: Public-key and attribute certificate frameworks.
(http://www.iso.ch)
[POLREQ] ETSI EN 319 411-1: Electronic Signatures and Infrastructures (ESI); Policy and security requi-
rements for Trust Service Providers issuing certificates; Part 1: General Requirements, v1.1.1
(2016-02)
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 14 di 55 28 Agosto 2017
[BR] CA/Browser Forum, “Baseline Requirements Certificate Policy for the Issuance and Manage-
ment of Publicly-Trusted Certificates”.
(https://cabforum.org/baseline-requirements-documents/)
[EVGL] CA/Browser Forum, “Guidelines For The Issuance And Management Of Extended Validation
Certificates”. (https://cabforum.org/extended-validation/)
2 Pubblicazioni e repository
Con “repository” si intende un insieme di archivi o registri on-line contenenti informazioni di interesse pubblico
relative ai certificati e al servizio di emissione e gestione degli stessi descritto in questo CPS.
2.1 Gestione del repository
Il repository di Actalis è costituito da:
sito web della CA (www.actalis.it ed altri siti di Actalis in esso indicati)
directory server della CA (ldap://ldap03.actalis.it)
Nota: per ragioni di bilanciamento di carico, il servizio di directory è distribuito su più server con indirizzi diffe-
renti, per cui l’hostname inserito nei certificati può essere diverso da ldap03; si tratta comunque di un CNAME.
La CA gestisce in proprio il repository e ne è direttamente responsabile.
2.2 Informazioni pubblicate
La CA pubblica almeno la seguente documentazione sul proprio sito web:
Certification Practice Statement (CPS)
certificati di CA (Root CA e Sub CA)
Condizioni Generali di contratto
tariffe massime del servizio
modulistica
La CA, inoltre, pubblica le CRL sul proprio directory server (per ulteriori informazioni al riguardo si rimanda alla
sezione 4.10).
2.3 Tempi e frequenza delle pubblicazioni
Questo CPS e la documentazione annessa vengono pubblicati sul sito web della CA in occasione di ogni aggior-
namento, in formato PDF.
Questo CPS viene riesaminato e se necessario aggiornato con frequenza almeno annuale.
Per ulteriori informazioni sulle CRL si rimanda alla sezione 4.10.
2.4 Controllo degli accessi
L’accesso al repository in sola lettura (“read-only”) è completamente libero per chiunque.
L’accesso al repository per la pubblicazione di informazioni nuove o aggiornate è possibile solo da postazioni di
lavoro attestate sulla medesima rete del repository, previa autenticazione.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 15 di 55 28 Agosto 2017
3 Identificazione ed autenticazione (I&A)
Le procedure di I&A seguite da Actalis sono conformi ai requisiti del CAB Forum. In particolare, per tutti i tipi di
certificato emessi sotto questo CPS, la CA svolge perlomeno le verifiche obbligatorie previste nei Baseline Re-
quirements for the Issuance and Management of Publicly-Trusted Certificates [BR]. Inoltre, per i certificati di
classe EV, la CA svolge anche le ulteriori verifiche previste dalle Guidelines For The Issuance And Management
Of Extended Validation Certificates [EVGL].
3.1 Regole di naming
Il campo Subject del certificato, se presente (secondo la classe del certificato), deve contenere informazioni fa-
cilmente comprensibili che consentano l’identificazione dell’organizzazione titolare. Non sono consentiti pseu-
donimi o nomi diversi dall’effettiva denominazione ufficiale per esteso (“full legal name”) del Titolare.
Non sono ammessi, nei certificati emessi per un determinato Titolare, nomi che violino diritti di proprietà intel-
lettuale di altri soggetti. Actalis rimarrà estranea a qualsivoglia controversia riguardante la proprietà dei nomi
di dominio, né si adopererà per risolvere eventuali controversie riguardanti la proprietà di nomi di dominio,
nomi commerciali, marchi commerciali o di servizi. Actalis si riserva la facoltà di respingere una richiesta di cer-
tificazione e di revocare un certificato a fronte di una tale controversia.
3.1.1 Per tutte le classi di certificato
Per tutti i tipi di certificato si applicano le seguenti regole di naming:
La componente commonName (OID 2.5.4.3) del campo Subject:
– nel caso di certificato SSL Server, deve contenere un singolo indirizzo IP oppure un Fully Qualified
Domain Name (FQDN) tra quelli contenuti nell’estensione SAN;
– nel caso di certificato per Code Signing, può contenere una frase proposta dal richiedente, purché
tale frase non sia tale da indurre in errore circa l’identità del titolare e le finalità del software
firmato. In ogni caso, non può trattarsi di un nome di dominio (qualificato o non).
Un esempio valido è “ACME Code Signing”.
La componente organizationName (OID 2.5.4.10) del campo Subject, se presente (secondo la classe di
certificato), deve contenere il nome ufficiale per esteso dell’organizzazione titolare del certificato (non
può trattarsi di una persona fisica). Il nome dev’essere univoco, ossia non deve prestarsi ad ambiguità.
Nel caso di certificato per SSL Server, deve trattarsi dell’organizzazione che ha il controllo dei server
indicati nel certificato; si tratta quindi, generalmente, dell’organizzazione titolare dei domini indicati
nel certificato, oppure dell’organizzazione parente (holding), oppure un’altra organizzazione che ha il
diritto esclusivo di usare tali domini su delega del loro titolare.
L’estensione SubjectAlternativeNames (SAN), sempre presente nel caso di certificato SSL Server, deve
contenere almeno una voce. Ognuna delle voci presenti dev’essere l’indirizzo IP oppure il FQDN di un
server sotto il controllo dell’organizzazione richiedente. Nomi e indirizzi interni non sono ammessi.
La componente organizationalUnitName (OID 2.5.4.11) del campo Subject, opzionale, può contenere
una stringa qualsiasi a discrezione del richiedente, purché non sia tale da indurre in errore le Relying
Party circa l’identità del titolare. Più in generale, nel certificato non saranno inserite informazioni
potenzialmente fuorvianti;
La componente localityName (OID 2.5.4.7) del campo Subject, se presente (secondo la classe di certi-
ficato), deve contenere il nome della località (città) dove ha sede principale l’organizzazione titolare;
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 16 di 55 28 Agosto 2017
La componente stateOrProvinceName (OID 2.5.4.8) del campo Subject, se presente (secondo la classe
di certificato), deve contenere il nome della Provincia (per i titolari con sede in Italia) o della regione o
stato (per i titolari con sede all’estero) dove l’organizzazione titolare ha la sede principale;
La componente countryName (OID 2.5.4.6) del campo Subject, se presente (secondo la classe di certi-
ficato), deve contenere il codice ISO 3166 a due lettere (es. “IT”) che identifica il paese dove ha sede
principale l’organizzazione titolare del certificato.
3.1.2 Per i certificati di classe EV
In aggiunta alle regole descritte sopra, per i certificati di classe EV si applicano anche le seguenti:
la componente businessCategory (OID 2.5.4.15) del campo Subject deve contenere il tipo di organizza-
zione (es. “Private Organization” oppure “Government Entity”);
la componente serialNumber (OID 2.5.4.5) del campo Subject deve contenere la Partita IVA (o analogo
codice identificativo nel caso di organizzazioni estere) dell’organizzazione titolare;
la componente jurisdictionOfIncorporationCountryName (OID 1.3.6.1.4.1.311.60.2.1.3) del campo
Subject deve contenere il codice a due lettere del paese dove l’organizzazione titolare è stata
legalmente costituita;
La componente streetAddress (OID 2.5.4.9) del campo Subject deve contenere l’indirizzo della sede
legale dell’organizzazione titolare (via/piazza e numero civico).
3.1.3 Per i certificati di classe DV
Nei certificati di classe DV, il campo Subject contiene esclusivamente:
la componente commonName, alla quale si applica quanto descritto nel paragrafo 3.1.1;
la componente organizationalUnitName con valore fisso “Domain Control Validated by Actalis S.p.A.”.
3.1.4 Internationalized Domain Names (IDN)
Alla data di revisione del presente CPS, gli Internationalized Domain Names (IDN) non sono supportati.
3.2 Validazione iniziale dell’identità
3.2.1 Dimostrazione del possesso della chiave privata
La dimostrazione del possesso, da parte del richiedente, della chiave privata corrispondente al certificato ri-
chiesto si basa sulla verifica crittografica della CSR (Certificate Signing Request) inviata alla CA. Il richiedente,
infatti, deve inviare la propria chiave pubblica alla CA sotto forma di CSR in formato PKCS#10 [RFC2314]. La CA
verifica che la firma digitale contenuta nella CSR sia valida.
L’invio della CSR alla CA avviene di norma via web o via posta elettronica.
3.2.2 Autenticazione dell’organizzazione richiedente
La verifica dell’identità dell’organizzazione richiedente, che non si applica ai certificati di classe DV, include in
ogni caso la consultazione del database della CCIAA (Camera di Commercio, Industria e Artigianato) o di un al-
tro database parimenti autorevole, per le organizzazioni private, o di un database governativo per gli enti pub-
blici. Il nome organizzazione specificato dal richiedente deve corrispondere alla denominazione ufficiale che
risulta da tale consultazione, a meno di differenze non significative (es. maiuscole/minuscole, accentazioni,
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 17 di 55 28 Agosto 2017
punteggiatura). Nel caso di mancata corrispondenza, la richiesta di certificato è respinta. Le informazioni che la
CA raccoglie e verifica sulle organizzazioni richiedenti includono perlomeno (elenco non esaustivo):
effettiva esistenza ed attività dell’organizzazione
nome ufficiale per esteso dell’organizzazione
P.IVA (o altro identificativo univoco ufficiale)
indirizzi della sede legale e delle sedi operative
Qualora la CA non riesca a recuperare autonomamente tali informazioni, essere dovranno essere fornite alla CA
dal richiedente in forma attendibile (es. visura camerale recente).
3.2.3 Autenticazione delle identità individuali
La verifica delle identità individuali, quando richiesta (secondo la classe di certificato), avviene con uno dei se-
guenti metodi secondo i casi e secondo le preferenze espresse dal Richiedente:
telefonicamente: un operatore della CA contatta la persona che figura come contatto amministrativo
(ovvero riferimento organizzativo) nel modulo di richiesta certificato attraverso il centralino dell’orga-
nizzazione di appartenenza;
de visu: esibizione di un documento ufficiale d’identità del contatto amministrativo ad un operatore
della CA, ove applicabile;
de visu: autenticazione del contatto amministrativo da parte di un notaio o altro pubblico ufficiale
oppure di un dottore commercialista;
mediante firma digitale: la richiesta di certificato viene sottoscritta con firma elettronica qualificata
(ai sensi della norme EU), quindi l’identità del firmatario viene desunta dal certificato qualificato di
firma, che dev’essere valido al momento della verifica da parte della CA.
La CA si riserva di compiere ulteriori verifiche con modalità non prestabilite.
3.2.4 Informazioni del titolare non verificate
La CA non verifica le seguenti informazioni sul titolare:
i nomi delle unità organizzative (OU) da inserire nei certificati;
informazioni specifiche dell’organizzazione titolare non usate a fini identificativi.
3.2.5 Verifica dell’autorizzazione
La CA utilizza un metodo di comunicazione affidabile per accertare che la richiesta di certificato sia autentica,
tra cui i seguenti metodi:
telefonicamente: un operatore della CA contatta il rappresentante dell’organizzazione richiedente
(contatto amministrativo), attraverso il centralino (il cui numero viene previamente ottenuto da una
fonte attendibile), e chiede a quella persona di confermare che la richiesta di certificato è autentica;
de visu: un operatore della CA assiste di persona alla firma dell’accordo di servizio da parte del
contatto amministrativo (vedere il §3.2.3);
de visu: autenticazione della firma del contatto amministrativo sull’accordo di servizio da parte di un
notaio o altro pubblico ufficiale oppure di un dottore commercialista;
Posta Elettronica Certificata: il Richiedente (contatto amministrativo) conferma l’autenticità della
richiesta inviando alla CA un messaggio di PEC (o analogo servizio di “registered email”) dalla casella di
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 18 di 55 28 Agosto 2017
posta elettronica ufficiale dell’organizzazione richiedente (verificato dalla CA attraverso una fonte
attendibile);
mediante firma digitale: la richiesta di certificato viene sottoscritta con firma elettronica qualificata
(ai sensi della norme EU), quindi l’identità del firmatario viene desunta dal certificato qualificato di
firma, che dev’essere valido al momento della verifica da parte della CA.
3.2.6 Criteri di interoperabilità
La CA divulga tutti i cross-certificati nei quali essa compare come Subject, purché abbia definito o accettato le
condizioni della cross-certificazione.
3.3 Ulteriori verifiche svolte dalla CA
Nel caso di esito negativo o dubbio delle verifiche descritte di seguito, qualora il richiedente non sia in grado di
fornire alla CA le necessarie evidenze, la richiesta di certificato è respinta. La CA si riserva la facoltà di effettua-
re ulteriori verifiche, in aggiunta a quelle descritte di seguito, con modalità non prestabilite.
3.3.1 Per tutte le classi di certificato SSL Server
3.3.1.1 Verifica di controllo del dominio
Per i certificati SSL Server, la CA verifica che tutti i domini e gli indirizzi IP da includere nel certificato siano sotto
il controllo dell’organizzazione richiedente o di una sua affiliata (controllante o controllata). Tale verifica viene
svolta in uno dei modi seguenti, secondo i casi e la classe di certificato richiesto:
mediante interrogazioni WHOIS (o “Reverse DNS Lookup” per gli indirizzi IP);
interpellando i Registrar DNS del caso, o le autorità governative di registrazione domini;
comunicando con l'amministratore del dominio a un indirizzo di posta elettronica creato anteponendo
“admin”, ”administrator”, “webmaster”, “hostmaster”, o “postmaster” alla parte locale, seguito dal
simbolo at (@), seguito dal nome di dominio (quest’ultimo può essere ottenuto eliminando zero o più
componenti dal FQDN richiesto), oppure ad un indirizzo di posta ricavato dal record WHOIS del
dominio (non è ammesso l’utilizzo di altri indirizzi di email);
mediante inserimento, da parte del richiedente, di uno speciale record TXT o CNAME nello zone file del
dominio, e successiva verifica di tale record da parte della CA (questo dimostra che il richiedente ha
accesso in scrittura alle impostazioni DNS del dominio);
mediante pubblicazione, da parte del richiedente, di un particolare file sul sito web da certificare, e
successiva verifica di tale file da parte della CA (questo dimostra che il richiedente è in grado di pubbli-
care informazioni sul sito web da certificare).
L’unico caso in cui questa verifica può essere omessa è quando il certificato SSL Server viene richiesto alla CA
attraverso un intermediario che assicura a priori il controllo del dominio da parte del futuro titolare del certifi-
cato, in quanto tale intermediario coincide con (oppure è controllato da) il Registrar del dominio. In tal caso,
l’intermediario deve aver previamente sottoscritto con la CA un contratto che lo impegna a richiedere certifica-
ti solo per domini da esso registrati, e solo a favore dei legittimi titolari (Registrant) di tali domini.
Qualora uno o più di tali domini e/o indirizzi IP siano gestiti da un soggetto diverso dal richiedente, è necessario
che il richiedente fornisca alla CA l’evidenza di essere stato formalmente delegato dal legittimo titolare a gesti-
re quei domini e/o indirizzi IP.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 19 di 55 28 Agosto 2017
3.3.2 Per i certificati di classe EV
Per le organizzazioni private, la CA raccoglie ed esamina anche (almeno) le seguenti informazioni:
indirizzo della sede legale e delle sedi operative principali
data di inizio dell’attività
composizione del CdA
elenco dei soci
passaggi di proprietà
poteri di firma e rappresentanza
eventuali protesti e pregiudizievoli
Per le gli enti pubblici, la CA raccoglie ed esamina anche le seguenti informazioni:
indirizzo della sede legale
nomi e ruoli dei dirigenti
In entrambi i casi, si verifica che la richiesta di certificato sia stata autorizzata da un dirigente dell’organizza-
zione dotato di opportuni poteri di rappresentanza.
La CA verifica inoltre che tutti gli elementi dell’indirizzo (country, stateOrProvince, locality, streetAddress) da
inserire nel certificato corrispondano all’indirizzo dove l’organizzazione richiedente ha effettivamente la pro-
pria sede principale.
Tutte le verifiche sopra indicate sono svolte consultando il database della rilevante camera di commercio (nel
caso di organizzazione privata) o altro analogo database autorevole, oppure un appropriato database governa-
tivo (nel caso di ente pubblico).
Qualora l’organizzazione richiedente sia in attività da meno di 3 anni, la CA verifica l’esistenza di un conto cor-
rente bancario intestato al richiedente. A tal fine, l’organizzazione richiedente deve fornire alla CA una lettera
formale di referenze bancarie, datata e firmata dalla Banca, su carta intestata della banca stessa, in originale.
Nel caso la CA rilevi situazioni pregiudizievoli a carico dell’organizzazione richiedente o della persona che ha
sottoscritto la richiesta di certificato (per es. procedure fallimentari, protesti, insolvenza, ecc.), la procedura
viene sospesa e il caso viene portato all’attenzione del Responsabile Amministrativo e del Responsabile Sicu-
rezza della CA per essere valutato.
3.4 Informazioni non verificate dalla CA
La CA non verifica gli indirizzi di posta elettronica indicati nel modulo di richiesta.
In generale, la CA non verifica la correttezza delle informazioni ricevute dal richiedente che non sono destinate
ad essere incluse in campi critici del certificato (ai fini della sicurezza) e che non sono necessarie per l’emissione
e successiva gestione (sospensione, riattivazione, revoca) del certificato.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 20 di 55 28 Agosto 2017
3.5 I&A per le richieste di rinnovo
Il processo di rinnovo è simile al processo di prima emissione: consiste nella generazione di una nuova coppia di
chiavi, da parte del titolare, sostitutiva di quella in scadenza e nella richiesta alla CA di un corrispondente nuovo
certificato. Per il rinnovo sono seguiti gli stessi processi di identificazione ed autenticazione (I&A) che si appli-
cano alla prima emissione.
3.6 I&A per le richieste di sospensione o revoca
La modalità di identificazione ed autenticazione delle richieste di sospensione o revoca dipende dal canale usa-
to per la richiesta:
per poter inoltrare richieste di sospensione o revoca attraverso il portale dei servizi di CA, è necessario
il “login” al portale mediante userid e password (fornite al cliente mediante posta elettronica);
nel caso delle richieste di revoca inviate in forma cartacea alla CA, si procede come descritto nel
paragrafo 3.2.3.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 21 di 55 28 Agosto 2017
4 Requisiti operativi di gestione dei certificati
4.1 Richiesta del certificato
Secondo la classe di certificato (DV, OV, EV), la richiesta di certificato avviene mediante compilazione ed invio
alla CA (per es. via email) dell’apposito modulo di richiesta scaricabile dal sito web della CA, oppure compilando
un modulo on-line (web form). La richiesta può essere avviata direttamente dal futuro titolare oppure da un
rivenditore (business partner) o da una Registration Authority di Actalis, per conto del futuro titolare.
Le Enterprise RA richiedono i certificati in modalità on-line attraverso una specifica applicazione web-based.
La richiesta include sempre le seguenti informazioni:
tipo, classe e durata del certificato desiderato
indirizzo/i del/i server da inserire nel certificato (per i certificati SSL Server)
valore proposto per il campo commonName (per i certificati Code Signing)
Solo per le classi OV ed EV, inoltre, sono richieste le seguenti informazioni:
dati identificativi dell’organizzazione richiedente (denominazione, partita IVA, indirizzo, ecc.)
dati identificativi e di contatto (nome e cognome, email) di un riferimento amministrativo
dati identificativi e di contatto (nome e cognome, email) di uno o più referenti tecnici
La richiesta di certificato include, come passo indispensabile, l’accettazione esplicita delle Condizioni Generali
della CA, le quali incorporano per riferimento il presente CPS. Secondo la modalità di richiesta e la classe di cer-
tificato, l’accettazione delle condizioni generali della CA può avvenire:
1) con le modalità ammesse dalla normativa Italiana sui contratti a distanza (es. “point & click”),
2) mediante firma autografa da parte del richiedente,
3) mediante firma digitale da parte del richiedente.
Nei casi in cui è richiesta la firma, essa deve essere apposta da una persona che riveste un ruolo o carica appro-
priata all’interno dell’organizzazione richiedente.
Nel caso in cui siano richiesti certificati di classe EV è necessaria la sottoscrizione, da parte del Richiedente, di
uno specifico Accordo di Servizio (Subscriber Agreement); la sottoscrizione deve avvenire in uno dei seguenti
modi (non sono ammesse altre possibilità):
firma autografa del rappresentante dell’organizzazione richiedente di fronte ad un rappresentante
della CA (il quale contro-firma) in veste di testimone;
firma autografa del rappresentante dell’organizzazione richiedente autenticata da un notaio o altro
pubblico ufficiale, o da un dottore commercialista (*);
firma digitale (firma elettronica qualificata) del rappresentante dell’organizzazione richiedente,
conforme alle norme vigenti.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 22 di 55 28 Agosto 2017
(*) In questo caso, la copia autenticata dell’accordo di servizio firmato dal richiedente dev’essere trasmessa alla
CA in originale. La richiesta di certificato non verrà presa in carico fino a quando la CA fintanto che non ha rice-
vuto e verificato tale originale.
Prima di accettare le condizioni generali della CA, il richiedente ha la possibilità e il dovere di valutare ogni
aspetto del servizio consultando la documentazione pubblicata sul sito web della CA.
Il modulo / web form di richiesta certificato è disponibile nelle lingue Italiano e Inglese, così come le condizioni
generali di contratto. La CA non promette di accettare richieste di certificato redatte in altre lingue.
La richiesta di certificato dev’essere accompagnata o seguita dalla CSR (Certificate Signing Request). Nel caso di
richiesta in modalità cartacea, la CSR può essere inviata alla CA successivamente, per posta elettronica, all’indi-
rizzo indicato dal responsabile della registrazione.
La CSR è normalmente generata dall’organizzazione richiedente con mezzi propri.
È anche possibile richiedere un certificato SSL Server di tipo “wildcard” (ossia valido per tutti i siti web attestati
su uno specifico dominio) oppure di tipo “multi-SAN” (nel quale sono indicati molteplici siti web e/o domini per
i quali lo stesso certificato è valido). In questi casi si applicano le medesime procedure di I&A: la CA verifica
sempre che il richiedente effettivamente sia il legittimo proprietario dei domini e/o indirizzi IP da includere nel
certificato e che si tratti di un’azienda esistente, in base ai dati della camera di commercio.
Ai certificati di tipo wildcard e multi-SAN si applicano tariffe diverse da quelle dei certificati SSL Server semplici
(per singoli siti web). Per ulteriori informazioni contattare la direzione commerciale di Actalis.
Il massimo numero consentito di valori SAN in un certificato SSL Server è 100.
4.2 Elaborazione delle richieste
La procedura per l’emissione del certificato soddisfa il requisito del “dual control”, in quanto richiede sempre
l’intervento di due differenti operatori:
operatore di RA (RAO);
operatore di CA (CAO).
Alla ricezione di una richiesta di certificazione, l’operatore di RA svolge le seguenti attività:
svolge le verifiche descritte nella sezione 3.1.4;
svolge le ulteriori verifiche descritte nella sezione 3.3;
provvede al censimento del richiedente nel database di registrazione della CA;
invia all’utente, mediante posta elettronica, le credenziali necessarie per accedere all’area riservata del
portale dei servizi della CA, per l’eventuale sospensione/riattivazione o revoca del certificato.
La registrazione del richiedente consiste nella memorizzazione, nel database della CA, dei dati identificativi e di
contatto (telefono, email) dell’organizzazione richiedente e della persona che richiede il certificato (normal-
mente un rappresentante legale, per es. un dirigente con opportuni poteri di firma), nonché i domini Internet
controllati dall’organizzazione richiedente e altre informazioni accessorie.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 23 di 55 28 Agosto 2017
4.3 Emissione del certificato
Se le verifiche di cui alla sezione precedente sono superate, l’operatore di CA:
verifica che la CSR sia correttamente codificata e non contenga informazioni impreviste;
verifica che le informazioni nella CSR siano coerenti con quelle presenti nel database della CA;
verifica il possesso, da parte del richiedente, della chiave privata corrispondente alla CSR, come
descritto nella sezione 3.2.1;
verifica che la chiave presente nella CSR non sia una “chiave debole” (secondo CVE-2008-0166);
(a partire da non oltre l’8 settembre 2017) verifica i record CAA (se presenti) dei domini da includere
nel certificato, per controllare che Actalis sia autorizzata ad emettere certificati per quei domini, nel
rispetto della specifica RFC 6844. Nell’ambito di questa verifica, si assume che la CA di Actalis sia
indicata dal dominio “actalis.it”.
Tali verifiche sono svolte in modo automatico dal software di CA, sotto controllo del CAO.
Se le precedenti verifiche sono superate, la CA genera il certificato, lo memorizza nel proprio database e infine
invia al cliente mediante posta elettronica:
il certificato del titolare
il certificato della CA emittente
eventuali informazioni accessorie
A questo punto, nel caso in cui il certificato non sia già stato pagato, viene inviata la fattura al cliente.
4.4 Accettazione del certificato
Il certificato si intende senz’altro accettato dal cliente trascorsi 30 giorni dalla data di consegna, come attestata
dalla data del messaggio di posta elettronica tramite il quale esso viene inviato al cliente, in assenza di comuni-
cazioni in senso contrario da parte del cliente stesso.
L’uso pubblico del certificato (per es. installazione su un sito web ad accesso pubblico, firma di codice eseguibi-
le scaricabile da siti web ad accesso pubblico), anche se temporaneo, implica in ogni caso l’accettazione del cer-
tificato da parte del titolare.
Qualora il certificato contenga informazioni errate a causa della errata compilazione del modulo di richiesta da
parte del cliente, esso dovrà in ogni caso essere pagato.
4.5 Uso della coppia di chiavi e del certificato
Il titolare usa la chiave privata per:
(certificati per Code Signing) firmare digitalmente codice eseguibile (per es. applet Java, librerie
dinamiche, ecc.) di propria produzione e/o del quale si assume la responsabilità;
(certificati per SSL Server) attivare il protocollo TLS/SSL sul proprio sito web, consentendo la server
authentication e la cifratura delle transazioni coi browser.
Le relying parties usano il certificato per:
(certificati per Code Signing) verificare l’integrità e l’origine di codice eseguibile;
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 24 di 55 28 Agosto 2017
(certificati per SSL Server) verificare l’identità di un sito web e dell’organizzazione che lo gestisce,
nonché scambiare in modo sicuro la “chiave di sessione” col web server.
Vedere anche il paragrafo 1.4.
4.6 Rinnovo del certificato
Il certificato ha una data di scadenza, oltre la quale esso perde ogni validità. La ragione per cui il certificato ha
una durata limitata nel tempo è che la sicurezza di una coppia di chiavi crittografiche può, nel tempo, diminuire
o essere addirittura compromessa, per effetto degli avanzamenti delle tecniche di criptoanalisi e degli attacchi
perpetrati dai malintenzionati. Per queste ragioni, Actalis normalmente non rinnova un certificato se l’utente
non genera una nuova coppia di chiavi. A parte questo, il processo di rinnovo è uguale al processo di prima
emissione.
4.7 Rigenerazione della chiave
Nel caso in cui l’utente finale (titolare) decida di utilizzare una nuova chiave, egli deve necessariamente fare
richiesta di un corrispondente nuovo certificato.
4.8 Modifica del certificato
Un certificato, essendo firmato dalla CA emittente, non può essere “modificato”. Per rimediare ad eventuali
errori nella generazione del certificato, dunque, è necessario emetterne uno nuovo (e revocare quello errato,
per evidenti ragioni di sicurezza).
Nel caso in cui il certificato emesso contenga informazioni errate a causa di errori commessi dalla CA o dalla RA
(nel caso si tratti di struttura distinta), il certificato errato sarà revocato e ne verrà emesso uno corretto senza
oneri aggiuntivi per il cliente e senza richiedere ulteriori informazioni al cliente.
Nel caso in cui il certificato emesso contenga informazioni errate a causa di errori commessi dal richiedente (es.
errata compilazione di uno o più campi del modulo di richiesta), il certificato errato sarà revocato.
4.9 Sospensione e revoca del certificato
La sospensione determina un blocco temporaneo della validità di un certificato, a partire da un dato momento
(data/ora). Dopo essere stato sospeso, un certificato può essere riattivato.
La revoca determina la cessazione anticipata della validità di un certificato, a partire da un dato momento (da-
ta/ora). La revoca di un certificato è irreversibile e non retroattiva.
L’attuazione della sospensione o revoca consiste nella generazione e pubblicazione di una nuova CRL (Certifica-
te Revocation List) che include il numero di serie del certificato sospeso o revocato. La CRL è liberamente ac-
cessibile a chiunque abbia necessità di verificare lo stato del certificato (cfr. la sezione 4.10).
La riattivazione consiste nella generazione e pubblicazione di una nuova CRL nella quale non compare più il
numero di serie del certificato precedentemente sospeso.
4.9.1 Circostanze per la sospensione
Le condizioni che possono portare ad una richiesta di sospensione sono:
sospetta compromissione della chiave privata;
interruzione temporanea del’uso del certificato da parte del cliente;
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 25 di 55 28 Agosto 2017
inadempienze contrattuali da parte del cliente (es. mancato pagamento).
4.9.2 Chi può richiedere la sospensione
La sospensione può essere richiesta dal cliente e/o titolare del certificato o dalla CA.
In determinate circostanze il titolare ha l’obbligo di richiedere la sospensione del certificato (vedere il paragrafo
9.5.3).
La revoca può essere effettuata direttamente dalla CA quando essa viene a conoscenza di condizioni che po-
trebbero compromettere l’attendibilità del certificato o costituiscono inadempienza contrattuale da parte del
cliente.
4.9.3 Procedura per la sospensione
La sospensione può essere richiesta dal titolare in modalità on-line (vedere il paragrafo 4.9.6).
Trascorsi 15 giorni dalla sospensione, il certificato viene automaticamente riattivato.
Il certificato può essere riattivato dall’utente stesso, in qualsiasi momento, attraverso il portale web dei servizi
della CA, previa autenticazione.
4.9.4 Circostanze per la revoca
Le condizioni che possono determinare una revoca sono:
provvedimento dell’autorità giudiziaria;
compromissione della chiave privata del titolare;
sospetta o acclarata compromissione della chiave privata della CA emittente (SubCA);
il certificato è divenuto tecnicamente insicuro, per es. a seguito della compromissione di un algoritmo
crittografico e/o di una determinata lunghezza della chiave pubblica inclusa nel certificato;
la CA scopre che l’organizzazione titolare del certificato ha cessato la propria attività;
cessazione dell’attività della CA oppure perdita del suo diritto di emettere certificati conformi ai
Requisiti [BR] (in mancanza di una CA sostitutiva che si faccia carico del servizio di revoca e pubbli-
cazione delle informazioni sullo stato dei certificati);
la CA scopre che il certificato contiene informazioni errate e/o fuorvianti;
la CA scopre che il titolare ha violato una o più delle disposizioni del presente CPS e/o delle Condizioni
Generali;
la CA scopre che una o più delle informazioni contenute nel certificato ha subito variazioni
(per es. è cambiata la denominazione sociale dell’azienda titolare);
richiesta da parte del titolare (es. motivata da cessazione dell’uso del certificato);
il titolare informa la CA che la richiesta del certificato non era stata autorizzata, e non intende
autorizzarla retroattivamente;
la CA scopre che l’uso di un FQDN o di un indirizzo IP contenuto nel certificato non è più consentito
(per es. quando il titolare del dominio e/o della rete non ha rinnovato la registrazione, a seguito di un
provvedimento dell’autorità giudiziaria, ecc);
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 26 di 55 28 Agosto 2017
la CA scopre che la chiave del titolare è compromessa e/o che il certificato viene usato in modo
improprio e/o illecito;
la CA scopre che un certificato di tipo wildcard viene usato per autenticare un FQDN subordinato in
modo fraudolento;
errato profilo del certificato, a causa di un errore della CA (es. valori errati nelle estensioni);
la CA scopre che il certificato non rispetta il presente CPS sotto qualche aspetto;
la CA scopre che il certificato non è conforme ai Requisiti [BR] e alle Linee Guida [EVGL] (secondo il
tipo di certificato) sotto qualche aspetto;
inadempienze contrattuali da parte del cliente (es. mancato pagamento del certificato).
In tutti questi casi, la CA revoca il certificato entro 24 ore.
Qualora la CA scopra che il certificato viene usato dal titolare per attività criminali (es. “Phishing”, attacchi di
tipo “man-in-the-middle”, distribuzione di malware, ecc.) la CA effettuerà una revoca immediata e senza preav-
viso del certificato. Analogamente nel caso in cui la CA scopra che il certificato è stato erroneamente emesso
con CA=TRUE nella estensione KeyUsage.
4.9.5 Chi può richiedere la revoca
La revoca può essere richiesta (secondo i casi):
dal titolare del certificato;
dall’autorità giudiziaria;
dalla CA emittente.
Inoltre, chiunque può segnalare alla CA fatti o circostanze che possono, secondo i casi, indurre la CA a reputare
necessaria la revoca del certificato.
In determinate circostanze il titolare ha l’obbligo di richiedere prontamente la revoca del certificato (vedere il
paragrafo 9.5.3).
4.9.6 Procedura per la sospensione o revoca
La sospensione e la revoca possono essere richieste direttamente alla CA attraverso il portale web di Actalis,
all’indirizzo indicato sul sito www.actalis.it. Nel caso in cui il certificato sia fornito al titolare attraverso un riven-
ditore oppure attraverso una RA, la sospensione e la revoca del certificato possono essere richieste attraverso il
portale web del rivenditore o della RA. In tutti i casi, prima di poter richiedere la sospensione o revoca del certi-
ficato, è necessario che il titolare si autentichi con le credenziali che gli sono state fornite dalla CA (diretta-
mente oppure attraverso un rivenditore o una RA) a tale scopo.
In alternativa, per la sola revoca è possibile utilizzare un modulo di richiesta (scaricabile dal sito web di Actalis)
sottoscritto dal titolare. Il modulo firmato può essere consegnato oppure inviato alla CA mediante posta ordi-
naria o meglio posta elettronica. Le richieste di revoca inviate alla CA in questo modo evase mediamente entro
24 ore nel 90% dei casi, nei soli giorni lavorativi. Tuttavia, a meno che il modulo di richiesta non sia inviato alla
CA in formato elettronico, sottoscritto con firma digitale valida, la richiesta verrà effettivamente presa in carico
solo dopo aver verificato telefonicamente l’autenticità della firma.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 27 di 55 28 Agosto 2017
Indipendentemente da chi richiede la sospensione o revoca, la CA invia segnala al cliente l’avvenuta sospensio-
ne o revoca mediante posta elettronica, inviando una notifica all’indirizzo di e-mail del “responsabile tecnico”
indicato nel modulo di richiesta.
I certificati sono sospesi/revocati entro 24 ore dalla richiesta di sospensione/revoca effettuata on-line.
4.9.7 Frequenza di emissione della CRL
Vedere il paragrafo 4.10.1.
4.10 Servizi informativi sullo stato del certificato
In generale, lo stato dei certificati (attivo, sospeso, revocato) è reso disponibile a tutti gli interessati mediante
pubblicazione della Certificate Revocation List (CRL) col formato definito nella specifica [RFC5280].
Per quanto riguarda i certificati degli utenti finali, è disponibile anche un servizio di verifica on-line basato sul
protocollo OCSP (On-line Certificate Status Protocol) e conforme alla specifica [RFC6960].
4.10.1 Caratteristiche operative
La CRL è accessibile con due diverse modalità:
con protocollo LDAP [RFC2251] sul server ldapNN.actalis.it
con protocollo HTTP [RFC2616] sul server crlNN.actalis.it
In entrambi i casi, NN è un numero decimale (per es. “04”). Infatti, per ragioni di distribuzione del di carico, la
CRL può essere pubblicata su server con indirizzi differenti secondo la classe e il tipo del certificato considerato.
Gli indirizzi completi LDAP ed HTTP della CRL, riportati di seguito, sono anche inseriti nell’estensione CRLDistri-
butionPoints del certificato:
ldap://ldapNN.actalis.it/cn=Actalis Authentication CA G3,o=Actalis
S.p.A./03358520967,c=IT?certificateRevocationList;binary
http://crlNN.actalis.it/Repository/AUTH-G3/getLastCRL
La CRL viene rigenerata e ripubblicata:
almeno ogni 6 ore, anche in assenza di nuove sospensioni o revoche;
a seguito di ogni nuova sospensione o revoca.
L’indirizzo del server OCSP, riportato qui di seguito, è inserito nell’estensione AuthorityInformationAccess del
certificato:
http://ocspNN.actalis.it/VA/AUTH-G3 (
NN è un numero decimale, per es. “04”. Infatti, per ragioni di distribuzione del carico, il servizio OCSP è erogato
da diversi server con indirizzi differenti, secondo la classe e il tipo del certificato considerato.
La CRL e l’eventuale servizio OCSP sono liberamente consultabili da chiunque.
La ARL, ovvero la lista dei certificati di Sub CA revocati dalla Root CA, viene aggiornata e pubblicata:
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 28 di 55 28 Agosto 2017
almeno ogni 3 mesi, anche in assenza di nuove sospensioni o revoche;
a seguito di ogni nuova sospensione o revoca.
4.10.2 Disponibilità del servizio
L’accesso alla CRL e all’eventuale servizio OCSP è disponibile in modo continuo (24 x 7), tranne in caso di fermi
per manutenzione programmata e in caso di guasti. Vedere anche il paragrafo 9.16.
4.11 Cessazione del contratto
Il contratto di servizio stipulato tra CA e cliente si intende terminato:
alla data di scadenza naturale del certificato, oppure…
alla data di attuazione della revoca del certificato (vedere la sezione 4.9).
4.12 Key escrow e key recovery
Con “key escrow” si intende l’affidamento di una copia della chiave di CA ad un soggetto esterno affidabile (es.
un notaio). Nell’ambito del servizio erogato da Actalis in base a questo CPS, il key escrow della chiave di CA non
è previsto.
Il ripristino della chiave (key recovery) di certificazione è previsto, in caso di cancellazione involontaria o guasto
dello HSM. Al fine di consentire il key recovery, la CA mantiene una copia di backup della chiave di CA (vedere il
paragrafo 6.8).
4.13 Segnalazione di problemi
Actalis mette a disposizione di tutte le parti interessate (Titolari, Relying Party, fornitori di software applicativo
quale ad es. i web browser, l’autorità giudiziaria e le forze dell’ordine, ecc.) due diversi canali di comunicazione
che consentono di segnalare alla CA, in qualsiasi momento, eventuali problemi relativi ai certificati:
la casella di posta elettronica [email protected], della quale si garantisce la lettura tempestiva
solamente in orario lavorativo (dalle 9 alle 17 dei giorni lavorativi italiani);
il numero di telefono (+39) 0575-050.376, del quale si garantisce il presidio 24 x 7 x 365.
Indipendentemente dal canale di comunicazione utilizzato, il segnalatore deve fornire almeno le seguenti infor-
mazioni, o la segnalazione non sarà presa in considerazione:
nome e cognome;
numero di telefono personale;
descrizione del presunto problema;
informazioni sufficienti per identificare il certificato oggetto della segnalazione, per esempio:
– per un certificato SSL Server: indirizzo del sito web sul quale è installato tale certificato,
oppure hostname, data di inizio validità e numero di serie;
– per un certificato Code Signing: commonName (CN), data di inizio validità e numero di serie.
Le segnalazioni possono essere fatte in Italiano oppure in Inglese.
La CA si impegna a prendere in carico entro 24 ore le segnalazioni correttamente formulate, avviare le indagini
sul problema segnalato e prendere i necessari provvedimenti, secondo la severità del problema. La priorità as-
segnata alla segnalazione dipenderà da:
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 29 di 55 28 Agosto 2017
la natura del presunto problema;
l’identità del segnalatore (per es. le segnalazioni ricevute dall’autorità giudiziaria saranno trattate con
maggiore priorità rispetto ad altre segnalazioni);
la normativa applicabile al problema (es. le segnalazioni relative ad atti illeciti saranno considerate con
maggiore priorità rispetto ad altre segnalazioni).
Qualora il problema sussista, la CA deciderà caso per caso le misure da adottare (per es. la revoca del certifica-
to) e ne darà comunicazione al segnalatore mediante e-mail.
Nota: coloro che inviano messaggi indesiderati (“spam”) saranno perseguiti secondo le norme vigenti.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 30 di 55 28 Agosto 2017
5 Misure di sicurezza fisica ed operativa
L’infrastruttura tecnologica, le procedure operative, le misure di sicurezza fisica e logica ed il personale prepo-
sto all’erogazione del servizio descritto in questo CPS sono gli stessi utilizzati nell’ambito del servizio Actalis di
emissione e gestione dei certificati qualificati per firma digitale a norma di legge.
5.1 Sicurezza fisica
Tutti i sistemi di elaborazione usati per l’erogazione del servizio di certificazione qui descritto, ad accezione del
server contenente le evidenze di registrazione (vedere più avanti), si trovano presso il data center di Actalis sito
in Via Gobetti 96, Arezzo.
Per la gestione della propria infrastruttura tecnologica di CA, Actalis si avvale dei servizi di gestione data center
erogati dalla capo-gruppo Aruba S.p.A., la quale è responsabile dell’housing e della connettività ad Internet dei
sistemi, nonché della sicurezza fisica. Il fornitore del servizio, in particolare, è impegnato contrattualmente a
garantire ad Actalis quanto segue:
un sistema di controllo accessi fisici, in modo che l’accesso all’edificio sia possibile solo a coloro che ne
hanno effettiva necessità, previa registrazione alla reception, e che l’accesso alle sale tecniche sia
consentito solo agli addetti autorizzati, previa identificazione mediante badge e relativo PIN;
sistemi antintrusione passivi quali grate, vetrate antiproiettile, porte blindate, cancelli motorizzati e
sistemi antintrusione attivi quali TVCC e VMD;
un sistema antincendio realizzato nel rispetto delle norme di legge e degli standard tecnici di riferi-
mento; sensori per la rilevazione incendio sono inoltre presenti in tutti i piani dell’edificio;
un sistema di alimentazione elettrica ridondato a tutti i livelli (gruppi di trasformazione, power center,
UPS, gruppi elettrogeni, quadri di distribuzione, ecc.) a garanzia della continuità di alimentazione
elettrica in ogni prevedibile condizione;
un sistema di ventilazione e di condizionamento (HVAC) atto a garantire condizioni climatiche ottimali
per il regolare funzionamento dei server ospitati nel data center;
un Network Operation Center (NOC), presidiato H24 per 365 giorni/anno da personale sistemistico
qualificato, che assicura il costante monitoraggio dell’infrastruttura e dei servizi ed il tempestivo
intervento in caso di necessità;
connettività ad Internet ridondata, con capacità almeno doppia rispetto al minimo necessario;
certificazione ISO 27001 del servizio erogato.
Presso gli uffici Actalis di Ponte San Pietro (BG), Via San Clemente 53, è presente un server sul quale sono con-
servate in forma elettronica le evidenze della identificazione e registrazione dei clienti del servizio qui descritto.
5.2 Sicurezza delle procedure
Actalis definisce e mantiene un Piano della Sicurezza che analizza gli asset, i rischi a cui sono esposti e descrive
le misure tecniche ed organizzative atte a garantire un adeguato livello di sicurezza delle operazioni. L’analisi di
rischi viene rivista periodicamente (almeno annualmente).
Tutte le procedure operative standard sono documentate e comprese nel Sistema di gestione della Qualità di
Actalis, certificato secondo la norma ISO 9001.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 31 di 55 28 Agosto 2017
5.3 Sicurezza del personale
Il personale addetto al servizio ha una pluriennale esperienza nel campo della definizione, sviluppo e gestione
di servizi di PKI ed ha ricevuto una adeguata formazione sulle procedure e gli strumenti da utilizzare nelle varie
fasi operative.
5.4 Registrazione degli eventi
I principali eventi relativi alla gestione del ciclo di vita dei certificati, incluse le richieste di emissione, revoca,
ecc., sono registrati e conservati in modo sicuro. Sono registrati anche altri eventi quali: gli accessi logici al si-
stema di gestione dei certificato, gli accessi fisici ai locali tecnici della CA, ecc.
Di ogni evento viene registrata la tipologia, la data e l’ora di occorrenza e, se disponibili, altre informazioni utili
ad individuare gli attori coinvolti nell’evento e l’esito delle operazioni.
L’insieme delle registrazioni costituisce il “giornale di controllo” (audit log). I file che lo compongono vengono
trasferiti periodicamente su supporto permanente e conservati per 20 anni, protetti dalle alterazioni.
5.5 Archiviazione dei dati
La CA conserva le seguenti informazioni relative ai processi di emissione e gestione dei certificati:
le richieste di emissione
la documentazione fornita dai richiedenti
le CSR (Certificate Signing Request) fornite dai richiedenti
dati anagrafici dei richiedenti e dei titolari (ove siano soggetti diversi)
risultati delle verifiche svolte dalla CA (visura camerale, record WHOIS) e relative evidenze
le richieste di sospensione o revoca
tutti i certificati emessi
I dati sopra elencati sono conservati almeno per 7 anni oltre la data di scadenza dei certificati.
5.6 Rinnovo della chiave della CA
5.6.1 Root CA
Nessuna stipula.
5.6.2 SubCA
Almeno 3 anni prima della fine del periodo di validità della corrente chiave di certificazione (chiave di SubCA),
Actalis genera una nuova coppia di chiavi di SubCA e la distribuisce agli utenti con le modalità di cui alla sezione
6.2.2. Da quel momento, i nuovi certificati e le nuove CRL vengono firmati con la nuova chiave.
5.7 Copie di sicurezza (backup)
Una copia di sicurezza (backup) dei dati, delle applicazioni, del giornale di controllo e di ogni altro file necessa-
rio al completo ripristino del servizio viene effettuata quotidianamente.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 32 di 55 28 Agosto 2017
5.8 Compromissione e disaster recovery
Nel caso di compromissione2 di uno degli algoritmi crittografici (o dei loro parametri) usati per l’emissione e per
l’uso dei certificati, la CA:
informerà tutti i titolari di certificati emessi secondo il presente CPS e tutte le relying parties con le
quali la CA ha stipulato degli accordi al riguardo;
pubblicherà prontamente sul proprio sito web un avviso ben evidente;
revocherà tutti i certificati divenuti inaffidabili a seguito dell’evento;
interromperà l’erogazione del servizio (il servizio sarà riattivato dopo aver posto rimedio alla
compromissione, se possibile, modificando gli algoritmi usati e/o i loro parametri ed eventualmente
generando una nuova chiave di SubCA e/o RootCA).
Si procederà in modo analogo nel caso di compromissione della CA, ossia nel caso di perdita di confidenzialità
(rilevazione a terzi non autorizzati) di una delle chiavi di certificazione usate per l’erogazione del servizio ogget-
to del presente CPS. Nel caso in cui ciò sia conseguenza di un incidente di sicurezza, si attiverà inoltre la relativa
procedura di gestione e informerà tutte le parti interessate.
Per “disastro” s’intende un evento dannoso le cui conseguenze determinano l’indisponibilità del servizio in
condizioni ordinarie, come per esempio nel caso di guasti e/o indisponibilità di una o più delle attrezzature
(elaboratori, HSM, cablaggi, sale tecniche, alimentazione elettrica, ecc.) necessarie per erogare i servizi di certi-
ficazione. In questi casi sono previste apposite procedure finalizzate al ripristino (recovery) dei servizi di certifi-
cazione. Tali procedure sono descritte nel Piano della Sicurezza (documento riservato, consultabile presso la
sede di Actalis su richiesta del cliente).
5.9 Cessazione della CA
Nel caso in cui intenda cessare l’erogazione del servizio oggetto del presente CPS, la CA farà quanto necessario
per minimizzare i disagi ai titolari di certificato e alle relying party; in particolare la CA:
almeno 30 giorni prima della cessazione, informerà delle proprie intenzioni tutti i titolari di certificato e
tutte le entità con cui la CA abbia in essere accordi al riguardo;
con lo stesso preavviso, pubblicherà un avviso evidente sul proprio sito web;
terminerà tutti i contratti in essere con gli eventuali subcontractor;
entro la data di effettiva cessazione, trasferirà ad altro soggetto l’obbligo di conservare le informazioni
di registrazione, le informazioni sullo stato dei certificati e gli archivi dei log per il tempo previsto;
alla data di cessazione, distruggerà le chiavi private di certificazione oppure farà in modo che
materialmente non sia più possibile utilizzarle.
2 Con compromissione qui si intende il caso in cui un algoritmo sia divenuto improvvisamente del tutto insicuro, per esem-pio qualora si abbia notizia che l’algoritmo RSA è stato “crackato” tout court. Il relativo indebolimento di un algoritmo con-seguente al progresso delle tecniche di crittoanalisi non è considerato compromissione, ma sarà ovviamente oggetto di at-tenzione e potrà comportare una revisione del presente CPS per tenerne conto.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 33 di 55 28 Agosto 2017
6 Misure di sicurezza tecnica
L’infrastruttura tecnologica, le procedure operative, le misure di sicurezza fisica e logica ed il personale prepo-
sto all’erogazione del servizio descritto in questo CPS sono gli stessi utilizzati nell’ambito del servizio Actalis di
emissione e gestione dei certificati qualificati per firma digitale a norma di legge.
6.1 Generazione delle chiavi
6.1.1 Root CA
La generazione della coppia di chiavi di Root CA avviene in un ambiente fisicamente sicuro, secondo una proce-
dura che richiede l’intervento congiunto di almeno due persone diverse (“dual control”). L’esecuzione della
procedura (“key ceremony”) è tracciata in un report conservato dal Responsabile della Sicurezza.
La coppia di chiavi usata dalla Root CA è generata all’interno di un HSM (Hardware Security Module) di alta
qualità, dotato di certificazione FIPS PUB 140-2 a livello 3 e di certificazione Common Criteria (ISO 15408) a li-
vello EAL 4 o superiore.
6.1.2 Sub CA
La generazione della coppia di chiavi di Root CA avviene in un ambiente fisicamente sicuro, secondo una proce-
dura che richiede l’intervento congiunto di almeno due persone diverse (“dual control”). L’esecuzione della
procedura (“key ceremony”) è tracciata in un report conservato dal Responsabile della Sicurezza.
La coppia di chiavi usata dalla Sub CA è generata all’interno di un HSM (Hardware Security Module) di alta qua-
lità, dotato di certificazione FIPS PUB 140-2 a livello 3 e di certificazione Common Criteria (ISO 15408) a livello
EAL 4 o superiore.
6.1.3 Titolari
Il richiedente provvede normalmente a generare la propria coppia di chiavi con mezzi propri.
6.2 Distribuzione della chiave pubblica
6.2.1 Root CA
La chiave pubblica della Root CA viene distribuita almeno nei modi seguenti:
mediante pubblicazione sul sito web della CA (www.actalis.it);
mediante inclusione negli elenchi delle Root CA affidabili (“root stores”) gestiti dai principali produttori
di sistemi operativi e browser (secondo gli accordi in essere tra Actalis e tali soggetti).
6.2.2 Sub CA
La chiave pubblica della Sub CA viene fornita al cliente, sotto forma di certificato X.509 firmato dalla Root CA,
insieme al certificato dell’utente finale.
Actalis può distribuire la chiave pubblica della Sub CA anche con altre modalità, secondo necessità.
6.2.3 Titolari
La chiave pubblica del soggetto che richiede il certificato viene fornita alla Sub CA sotto forma di Certificate Si-
gning Request (CSR) conforme allo standard PKCS#10 [RFC2314].
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 34 di 55 28 Agosto 2017
6.3 Lunghezza delle chiavi
Per quanto riguarda gli algoritmi crittografici, la lunghezza minima delle chiavi, i parametri delle chiavi e le fun-
zioni di hashing, Actalis si conforma alla norma ETSI TS 102 176-1 e all’Appendice A delle [EVGL], con prevalen-
za di quest’ultima in caso di conflitto.
6.3.1 Root CA
La Sub CA usa chiavi con un modulo di 4096 bit.
6.3.2 Sub CA
La Sub CA usa chiavi con un modulo di almeno 2048 bit.
6.3.3 Titolari
Le chiavi dei titolari hanno una lunghezza di 2048 bit.
6.4 Parametri di generazione e qualità delle chiavi
6.4.1 Root CA
La Root CA usa una coppia di chiavi crittografiche generate con algoritmo RSA, con esponente pubblico pari a
65537 (esadecimale 0x10001).
6.4.2 Sub CA
La Sub CA usa una coppia di chiavi crittografiche generate con algoritmo RSA, con esponente pubblico pari a
65537 (esadecimale 0x10001).
6.4.3 Titolari
Di norma, il titolare del certificato usa una coppia di chiavi crittografiche generate con algoritmo RSA. Sono
ammessi gli esponenti pubblici 3 (0x3) e 65537 (esadecimale 0x10001).
La CA non si impegna a certificare chiavi utente generate con algoritmi diversi (per es. ECDSA).
6.5 Key usage (estensione X.509v3)
6.5.1 Root CA
Il certificato della Root CA include l’estensione KeyUsage con i seguenti bit attestati:
keyCertSign (firma di certificati)
cRLSign (firma di CRL)
Per ulteriori dettagli si veda il capitolo 7.
6.5.2 Sub CA
Il certificato della Sub CA include l’estensione KeyUsage con i seguenti bit attestati:
keyCertSign (firma di certificati)
cRLSign (firma di CRL)
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 35 di 55 28 Agosto 2017
Per ulteriori dettagli si veda il capitolo 7.
6.5.3 Titolari
Si rimanda al capitolo 7.
6.6 Protezione della chiave privata
6.6.1 Root CA
La chiave privata usata dalla Root CA è mantenuta all’interno di un HSM (Hardware Security Module) di alta
qualità, dotato di certificazione Common Criteria (ISO 15408) a livello EAL 4 o superiore.
6.6.2 Sub CA
La chiave privata usata dalla Sub CA è mantenuta all’interno di un HSM (Hardware Security Module) di alta qua-
lità, dotato di certificazione FIPS PUB 140-2 a livello 3 oppure di certificazione Common Criteria (ISO 15408) a
livello EAL 4 o superiore.
6.6.3 Titolari
La CA raccomanda, ma non impone, l’uso di un dispositivo hardware (es. HSM) per la protezione della chiave
privata del titolare, purché il sistema adottato sia in grado di proteggerne la confidenzialità in misura adeguata.
La CA può rifiutare l’emissione del certificato qualora valuti come poco sicuro il sistema adottato dal richieden-
te per la protezione della propria chiave privata.
6.7 Standard di sicurezza dei moduli crittografici
Gli HSM (Hardware Security Module) usati dalla Root CA e dalla Sub CA sono dotati di certificazione di sicurezza
secondo la norma FIPS PUB 140-2 a livello 3 e/o di certificazione Common Criteria (ISO 15408) a livello EAL 4 o
superiore come precisato nei paragrafi precedenti.
6.8 Multi-Person Control (N di M) della chiave privata
6.8.1 Root CA
La chiave privata della Root CA è soggetta a multi-person control di tipo “N di M”, come meglio descritto nel
paragrafo 6.10.1.
6.8.2 Sub CA
Nessuna stipula.
6.8.3 Titolari
Nessuna stipula.
6.9 Backup e ripristino della chiave privata
6.9.1 Root CA
Allo scopo di garantire la continuità del servizio, la Root CA mantiene una copia di backup delle proprie chiavi
su un supporto rimovibile, in forma cifrata. La copia di backup viene conservata in luogo sicuro e distinto da
quello in cui si trova la copia operativa (all’interno dello HSM). Le operazioni di backup e ripristino delle chiavi
di CA richiedono l’intervento congiunto di almeno due persone diverse (“dual control”).
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 36 di 55 28 Agosto 2017
6.9.2 Sub CA
Allo scopo di garantire la continuità del servizio, la Sub CA mantiene una copia di backup delle proprie chiavi su
un supporto rimovibile, in forma cifrata. La copia di backup viene conservata in luogo sicuro e distinto da quello
in cui si trova la copia operativa (all’interno dello HSM). Le operazioni di backup e ripristino delle chiavi di CA
richiedono l’intervento congiunto di almeno due persone diverse (“dual control”).
6.9.3 Titolari
Se tecnicamente possibile, al titolare è consentito conservare una copia di backup della propria chiave privata a
scopo di ripristino. La confidenzialità della copia è assicurata con un sistema perlomeno equivalente, dal punto
di vista della sicurezza, a quello usato per la protezione della copia operativa.
6.10 Dati di attivazione della chiave
6.10.1 Root CA
La chiave della Root CA è normalmente mantenuta in stato non operativo, tranne quando è necessario sospen-
dere o revocare certificati di Sub CA, mediante disattivazione della partizione HSM che la contiene.
L’attivazione della partizione HSM richiede l’uso di uno speciale dispositivo di inserimento PIN (“PED”), collega-
to direttamente allo HSM, e di un insieme di token USB di autenticazione a due fattori, ciascuno protetto da
PIN. In particolare, l’attivazione della partizione HSM contenente la chiave di Root CA richiede l’inserimento nel
PED del token di Security Officer più altri 3 token dei 5 distribuiti (“green token”), sulla base di uno schema di
secret sharing. Questi 5 green token sono affidati, per iscritto, ad altrettante persone che si impegnano a cu-
stodirli in modo sicuro. Pertanto, l’attivazione della chiave di Root CA richiede la presenza concorrente di alme-
no 3 persone su 5, più il Security Officer.
Il Responsabile della Sicurezza della Root CA mantiene una lista delle persone cui sono stati affidati i 5 green
token. La lista è visionabile dagli ispettori in occasione delle visite di audit.
6.10.2 Sub CA
Il PIN di attivazione dell’HSM della Sub CA è conosciuto esclusivamente dal personale addetto alla gestione
operativa del servizio sulla base del “need to know”, sotto la responsabilità del Responsabile della gestione
operativa della CA (o altro ruolo opportuno).
6.10.3 Titolari
È obbligo del titolare assicurare che il PIN o password di attivazione della propria chiave sia noto esclusiva-
mente al titolare stesso o ad un suo delegato.
6.11 Requisiti di sicurezza degli elaboratori
I sistemi operativi usati dalla Root CA e dalla Sub CA per la gestione dei certificati sono dotati di certificazione di
sicurezza secondo i criteri ITSEC a livello E2 HIGH o secondo criteri equivalenti. I sistemi operativi sono configu-
rati in modo tale da richiedere sempre l’identificazione dell’utente mediante username e password oppure, nel
caso dei sistemi più critici, mediante smartcard e relativo PIN. Gli eventi di accesso ai sistemi sono registrati
come descritto nel §5.4. I sistemi operativi sono inoltre sottoposti ad un periodico “hardening” per disabilitare
le funzionalità e servizi non necessari.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 37 di 55 28 Agosto 2017
L’emissione e la gestione dei certificati si appoggiano ad un software CMS (Certificate Management System).
Sono implementate delle interfacce web (“WebRA/WebCA”), protette da canale sicuro TLS, per lo svolgimento
delle operazioni di ordinaria gestione dei certificati da parte del personale opportunamente autorizzato. Per
l’accesso al CMS e alle interfacce gestionali con profili che consentono l’emissione dei certficati è necessaria
un’autenticazione forte individuale.
6.12 Sicurezza di rete
L’accesso agli host on-line della Root CA (normalmente off-line) e della Sub CA è protetto da firewall di alta
qualità che garantiscono un adeguato filtraggio delle connessioni. Prima dei firewall, una batteria di router che
implementano opportune ACL (Access Control List) costituisce un’ulteriore barriera di protezione. Sui server del
servizio di certificazione, tutte le porte di comunicazione non necessarie sono disattivate. Sono attivi esclusi-
vamente quegli agenti che supportano i protocolli e le funzioni necessarie per il funzionamento del servizio.
Per irrobustire il filtraggio delle comunicazioni tutto il sistema di certificazione è suddiviso in un’area esterna,
una interna ed una DMZ.
Actalis svolge almeno annualmente un assessment di sicurezza per verificare l’eventuale presenza di vul-
nerabilità di rete, avvalendosi di specialisti indipendenti.
6.13 Riferimento temporale
Tutti i sistemi di elaborazione usati dalla CA sono allineati con un time-server sincronizzato con un apparato di
alta qualità, a sua volta sincronizzato con la rete satellitare GPS e su altri riferimenti temporali affidabili.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 38 di 55 28 Agosto 2017
7 Profilo dei certificati, delle CRL e OCSP
7.1 Profilo del certificato
I certificati sono conformi allo standard internazionale ISO/IEC 9594-8:2005 [X.509] e alla specifica pubblica
[RFC 5280].
Per quanto riguarda gli algoritmi crittografici, la lunghezza minima delle chiavi, i parametri delle chiavi e le fun-
zioni di hashing, Actalis si conforma alla norma ETSI TS 102 176-1 e all’Appendice A delle [EVGL], con prevalen-
za di quest’ultima in caso di conflitto.
7.1.1 Root CA
Il certificato della CA root ha il seguente profilo:
Campo Valore
Version V3 (2)
SerialNumber 1
Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)
Issuer
CN = Actalis Authentication Root CA
O = Actalis S.p.A./03358520967
L = Milano
C = IT
Validity dal 22 settembre 2011 al 22 settembre 2030
Subject
CN = Actalis Authentication Root CA
O = Actalis S.p.A./03358520967
L = Milano
C = IT
SubjectPublicKeyInfo <chiave pubblica RSA da 4096 bit>
SignatureValue <firma della CA>
Estensione Valore
Basic Constraints critico: CA=true
AuthorityKeyIdentifier (AKI) <assente>
SubjectKeyIdentifier (SKI) 52:D8:88:3A:C8:9F:78:66:ED:89:F3:7B:38:70:94:C9:02:02:36:D0
KeyUsage critico: keyCertSign, cRLSign
ExtendedKeyUsage (EKU) <assente>
CertificatePolicies <assente>
SubjectAlternativeName (SAN) <assente>
AuthorityInformationAccess (AIA) <assente>
CRLDistributionPoints (CDP) <assente>
7.1.2 Sub CA per certificati di classe DV
Il certificato corrente della Sub CA ha il seguente profilo:
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 39 di 55 28 Agosto 2017
Campo Valore
Version V3 (2)
SerialNumber < include almeno 8 byte pseudo-random>
Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)
Issuer
CN = Actalis Authentication Root CA
O = Actalis S.p.A./03358520967
L = Milano
C = IT
Validity <max 15 anni>
Subject
CN = Actalis Domain Validation Server CA GN
O = Actalis S.p.A./03358520967
L = Ponte San Pietro
S = Bergamo
C = IT
SubjectPublicKeyInfo <chiave pubblica RSA da 2048 bit>
SignatureValue <firma della CA>
Estensione Valore
Basic Constraints critico: CA=true
AuthorityKeyIdentifier (AKI) <valore dell’estensione della Root CA>
SubjectKeyIdentifier (SKI) <digest SHA1 della chiave pubblica>
KeyUsage critico: keyCertSign, cRLSign
ExtendedKeyUsage (EKU) <assente>
CertificatePolicies PolicyOID = 2.5.29.32.0 (anyPolicy)
CPS-URI = <indirizzo HTTP di questo CPS>
SubjectAlternativeName (SAN) <assente>
AuthorityInformationAccess (AIA) <indirizzo HTTP del servizio OCSP >
CRLDistributionPoints (CDP) <indirizzo HTTP della ARL> <indirizzo LDAP della ARL>
7.1.3 Sub CA per certificati di classe OV
Il certificato corrente della Sub CA ha il seguente profilo:
Campo Valore
Version V3 (2)
SerialNumber < include almeno 8 byte pseudo-random>
Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)
Issuer
CN = Actalis Authentication Root CA
O = Actalis S.p.A./03358520967
L = Milano
C = IT
Validity <max 15 anni>
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 40 di 55 28 Agosto 2017
Subject
CN = Actalis Authentication CA GN
O = Actalis S.p.A./03358520967
L = Milano
C = IT
SubjectPublicKeyInfo <chiave pubblica RSA da 2048 bit>
SignatureValue <firma della CA>
Estensione Valore
Basic Constraints critico: CA=true
AuthorityKeyIdentifier (AKI) <valore dell’estensione della Root CA>
SubjectKeyIdentifier (SKI) <digest SHA1 della chiave pubblica>
KeyUsage critico: keyCertSign, cRLSign
ExtendedKeyUsage (EKU) <assente>
CertificatePolicies PolicyOID = 2.5.29.32.0 (anyPolicy)
CPS-URI = <indirizzo HTTP di questo CPS>
SubjectAlternativeName (SAN) <assente>
AuthorityInformationAccess (AIA) <indirizzo HTTP del servizio OCSP >
CRLDistributionPoints (CDP) <indirizzo HTTP della ARL> <indirizzo LDAP della ARL>
7.1.4 Sub CA per certificati di classe EV
Il certificato corrente della Sub CA ha il seguente profilo:
Campo Valore
Version V3 (2)
SerialNumber < include almeno 8 byte pseudo-random>
Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)
Issuer
CN = Actalis Authentication Root CA
O = Actalis S.p.A./03358520967
L = Milano
C = IT
Validity <max 15 anni>
Subject
CN = Actalis Extended Validation Server CA GN
O = Actalis S.p.A./03358520967
L = Milano
C = IT
SubjectPublicKeyInfo <chiave pubblica RSA da 2048 bit>
SignatureValue <firma della CA>
Estensione Valore
Basic Constraints critico: CA=true
AuthorityKeyIdentifier (AKI) <valore dell’estensione della Root CA>
SubjectKeyIdentifier (SKI) <digest SHA1 della chiave pubblica>
KeyUsage critico: keyCertSign, cRLSign
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 41 di 55 28 Agosto 2017
ExtendedKeyUsage (EKU) <assente>
CertificatePolicies PolicyOID = 2.5.29.32.0 (anyPolicy)
CPS-URI = <indirizzo HTTP di questo CPS>
SubjectAlternativeName (SAN) <assente>
AuthorityInformationAccess (AIA) <indirizzo HTTP del servizio OCSP >
CRLDistributionPoints (CDP) <indirizzo HTTP della ARL> <indirizzo LDAP della ARL>
7.1.5 SSL Server EV (Extended Validation)
Il certificato per SSL Server EV viene emesso col seguente profilo:
Campo Valore
Version V3 (2)
SerialNumber <8 random bytes>
Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)
Issuer <DN della CA che ha emesso il certificato>
Validity <12 oppure 24 mesi>
Subject
C = <codice ISO 3166 a due lettere del paese dove ha sede l’organizzazione titolare del certificato> ST = <provincia o stato dove ha sede l’organizzazione> L = <località dove ha sede l’organizzazione> O = <nome ufficiale dell’organizzazione> OU = <opzionale> CN = <uno dei FQDN contenuti nella estensione SAN > serialNumber = <numero di registrazione dell’organizzazione presso la camera di commercio o equivalente3> businessCategory = <tipo di organizzazione>
SubjectPublicKeyInfo <chiave pubblica RSA da 2048 bit>
SignatureValue <firma della CA>
Estensione Valore
Basic Constraints <assente>
AuthorityKeyIdentifier (AKI) <valore dell’estensione SKI della CA emittente>
SubjectKeyIdentifier (SKI) <digest SHA1 della chiave pubblica>
KeyUsage critico: digitalSignature, keyEncipherment
ExtendedKeyUsage (EKU) serverAuth (1.3.6.1.5.5.7.3.1), clientAuth (1.3.6.1.5.5.7.3.2)
CertificatePolicies PolicyOID = 1.3.159.1.17.1 PolicyOID = 2.23.140.1.1 CPS-URI = <indirizzo HTTP di questo CPS>
SubjectAlternativeName (SAN) <contiene uno o più FQDN, in conformità a [EVGL]>
AuthorityInformationAccess (AIA) <indirizzo HTTP del servizio OCSP> <indirizzo HTTP del certificato della CA emittente>
CRLDistributionPoints (CDP) <indirizzo HTTP per accedere alla CRL> <indirizzo LDAP per accedere alla CRL>
3 Nel caso delle organizzazioni registrate in Italia, si tratta in generale della Partita IVA.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 42 di 55 28 Agosto 2017
EmbeddedSCTList (1.3.6.1.4.1.11129.2.4.2)
Informazioni di Certificate Transparency secondo RFC 6962
La CA si riserva di inserire nel certificato ulteriori informazioni e/o ulteriori estensioni purché nel rispetto della
specifica [RFC5280] e delle linee guida [EVGL], salvaguardando la funzionalità del certificato per l’uso previsto.
7.1.6 Code Signing EV (Extended Validation)
Il certificato per Code Signing EV viene emesso col seguente profilo:
Campo Valore
Version V3 (2)
SerialNumber <8 random bytes>
Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)
Issuer <DN della CA che ha emesso il certificato>
Validity <12, 24 o 36 mesi >
Subject
C = <codice ISO 3166 a due lettere del paese dove ha sede l’organizzazione titolare del certificato> ST = <provincia o stato dove ha sede l’organizzazione> L = <località dove ha sede l’organizzazione> O = <nome ufficiale dell’organizzazione> OU = <opzionale> CN = <valore proposto dal titolare > serialNumber = <numero di registrazione dell’organizzazione presso la camera di commercio o equivalente4> businessCategory = <tipo di organizzazione>
SubjectPublicKeyInfo <chiave pubblica RSA da 2048 bit>
SignatureValue <firma della CA>
Estensione Valore
Basic Constraints <assente>
AuthorityKeyIdentifier (AKI) <valore della estensione SKI della CA emittente>
SubjectKeyIdentifier (SKI) <digest SHA1 della chiave pubblica>
KeyUsage digitalSignature
ExtendedKeyUsage (EKU) codeSigning (1.3.6.1.5.5.7.3.3)
CertificatePolicies PolicyOID = 1.3.159.1.18.1 CPS-URI = <indirizzo HTTP di questo CPS>
SubjectAlternativeName (SAN) <indirizzo di e-mail del titolare>
AuthorityInformationAccess (AIA) <indirizzo HTTP del servizio OCSP> <indirizzo HTTP del certificato della CA emittente>
CRLDistributionPoints (CDP) <indirizzo HTTP per accedere alla CRL> <indirizzo LDAP per accedere alla CRL>
La CA si riserva di inserire nel certificato ulteriori informazioni e/o ulteriori estensioni purché nel rispetto della
specifica [RFC5280] e delle linee guida [EVGL], salvaguardando la funzionalità del certificato per l’uso previsto.
7.1.7 SSL Server OV (Organization Validated)
Il certificato per SSL Server OV viene emesso col seguente profilo:
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 43 di 55 28 Agosto 2017
Campo Valore
Version V3 (2)
SerialNumber <8 random bytes>
Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)
Issuer <DN della CA che ha emesso il certificato>
Validity <12 oppure 24 oppure 36 mesi>
Subject
C = <codice ISO 3166 a due lettere del paese dove ha sede l’organizzazione titolare del certificato> ST = <provincia o stato dove ha sede l’organizzazione> L = <località dove ha sede l’organizzazione> O = <nome ufficiale dell’organizzazione> OU = <opzionale> CN = <uno dei FQDN contenuti nella estensione SAN>
SubjectPublicKeyInfo <chiave pubblica RSA da 2048 bit>
SignatureValue <firma della CA>
Estensione Valore
Basic Constraints <assente>
AuthorityKeyIdentifier (AKI) <valore dell’estensione SKI della CA emittente>
SubjectKeyIdentifier (SKI) <digest SHA1 della chiave pubblica>
KeyUsage critico: digitalSignature, keyEncipherment
ExtendedKeyUsage (EKU) serverAuth (1.3.6.1.5.5.7.3.1), clientAuth (1.3.6.1.5.5.7.3.2)
CertificatePolicies PolicyOID = 1.3.159.1.20.1 PolicyOID = 2.23.140.1.2.2 CPS-URI = <indirizzo HTTP di questo CPS>
SubjectAlternativeName (SAN) <contiene uno o più FQDN, in conformità a [BR]>
AuthorityInformationAccess (AIA) <indirizzo HTTP del servizio OCSP> <indirizzo HTTP del certificato della CA emittente>
CRLDistributionPoints (CDP) <indirizzo HTTP per accedere alla CRL> <indirizzo LDAP per accedere alla CRL>
La CA si riserva di inserire nel certificato ulteriori informazioni e/o ulteriori estensioni purché nel rispetto della
specifica [RFC5280] e delle linee guida [EVGL], salvaguardando la funzionalità del certificato per l’uso previsto.
7.1.8 SSL Server Wildcard OV (Organization Validated)
Il certificato per SSL Server Wildcard viene emesso col seguente profilo:
Campo Valore
Version V3 (2)
SerialNumber <8 random bytes>
Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)
Issuer <DN della CA che ha emesso il certificato>
Validity <12, 24 o 36 mesi >
4 Nel caso delle organizzazioni registrate in Italia, si tratta in generale della Partita IVA.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 44 di 55 28 Agosto 2017
Subject
C = <codice ISO 3166 a due lettere del paese dove ha sede l’organizzazione titolare del certificato> ST = <provincia o stato dove ha sede l’organizzazione> L = <località dove ha sede l’organizzazione> O = <nome ufficiale dell’organizzazione> OU = <opzionale> CN = <FQDN wildcard, contenuto anche nella estensione SAN>
SubjectPublicKeyInfo <chiave pubblica RSA da 2048 bit>
SignatureValue <firma della CA>
Estensione Valore
Basic Constraints <assente>
AuthorityKeyIdentifier (AKI) <valore dell’estensione SKI della CA emittente>
SubjectKeyIdentifier (SKI) <digest SHA1 della chiave pubblica>
KeyUsage critico: digitalSignature, keyEncipherment
ExtendedKeyUsage (EKU) serverAuth (1.3.6.1.5.5.7.3.1), clientAuth (1.3.6.1.5.5.7.3.2)
CertificatePolicies PolicyOID = 1.3.159.1.19.1 PolicyOID = 2.23.140.1.2.2 CPS-URI = <indirizzo HTTP di questo CPS>
SubjectAlternativeName (SAN) <Stesso FQDN wildcard contenuto nel campo Subject.CN >
AuthorityInformationAccess (AIA) <indirizzo HTTP del servizio OCSP> <indirizzo HTTP del certificato della CA emittente>
CRLDistributionPoints (CDP) <indirizzo HTTP per accedere alla CRL> <indirizzo LDAP per accedere alla CRL>
La CA si riserva di inserire nel certificato ulteriori informazioni e/o ulteriori estensioni purché nel rispetto della
specifica [RFC5280] e delle linee guida [EVGL], salvaguardando la funzionalità del certificato per l’uso previsto.
7.1.9 Code Signing OV (Organization Validated)
Il certificato per Code Signing OV viene emesso col seguente profilo:
Campo Valore
Version V3 (2)
SerialNumber <8 random bytes>
Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)
Issuer <DN della CA che ha emesso il certificato>
Validity <12 oppure 24 oppure 36 mesi >
Subject
C = <codice ISO 3166 a due lettere del paese dove ha sede l’organizzazione titolare del certificato> ST = <provincia o stato dove ha sede l’organizzazione> L = <località dove ha sede l’organizzazione> O = <nome ufficiale dell’organizzazione> OU = <opzionale> CN = <valore proposto dal titolare >
SubjectPublicKeyInfo <chiave pubblica RSA da 2048 bit>
SignatureValue <firma della CA>
Estensione Valore
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 45 di 55 28 Agosto 2017
Basic Constraints <assente>
AuthorityKeyIdentifier (AKI) <valore della estensione SKI della CA emittente>
SubjectKeyIdentifier (SKI) <digest SHA1 della chiave pubblica>
KeyUsage digitalSignature
ExtendedKeyUsage (EKU) codeSigning (1.3.6.1.5.5.7.3.3)
CertificatePolicies PolicyOID = 1.3.159.1.21.1 CPS-URI = <indirizzo HTTP di questo CPS>
SubjectAlternativeName (SAN) <indirizzo di e-mail del titolare>
AuthorityInformationAccess (AIA) <indirizzo HTTP del servizio OCSP> <indirizzo HTTP del certificato della CA emittente>
CRLDistributionPoints (CDP) <indirizzo HTTP per accedere alla CRL> <indirizzo LDAP per accedere alla CRL>
La CA si riserva di inserire nel certificato ulteriori informazioni e/o ulteriori estensioni purché nel rispetto della
specifica [RFC5280] e delle linee guida [EVGL], salvaguardando la funzionalità del certificato per l’uso previsto.
7.1.10 SSL Server DV (Domain Validated)
Il certificato per SSL Server DV viene emesso col seguente profilo:
Campo Valore
Version V3 (2)
SerialNumber <8 random bytes>
Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)
Issuer <DN della CA che ha emesso il certificato>
Validity <12 oppure 24 oppure 36 mesi>
Subject OU = “Domain Control Validated by Actalis S.p.A.” CN = <uno dei FQDN contenuti nella estensione SAN>
SubjectPublicKeyInfo <chiave pubblica RSA da 2048 bit>
SignatureValue <firma della CA>
Estensione Valore
Basic Constraints <assente>
AuthorityKeyIdentifier (AKI) <valore dell’estensione SKI della CA emittente>
SubjectKeyIdentifier (SKI) <digest SHA1 della chiave pubblica>
KeyUsage critico: digitalSignature, keyEncipherment
ExtendedKeyUsage (EKU) serverAuth (1.3.6.1.5.5.7.3.1), clientAuth (1.3.6.1.5.5.7.3.2)
CertificatePolicies PolicyOID = 1.3.159.1.22.1 PolicyOID = 2.23.140.1.2.1 CPS-URI = <indirizzo HTTP di questo CPS>
SubjectAlternativeName (SAN) <contiene uno o più FQDN, in conformità a [BR]>
AuthorityInformationAccess (AIA) <indirizzo HTTP del servizio OCSP> <indirizzo HTTP del certificato della CA emittente>
CRLDistributionPoints (CDP) <indirizzo HTTP per accedere alla CRL> <indirizzo LDAP per accedere alla CRL>
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 46 di 55 28 Agosto 2017
La CA si riserva di inserire nel certificato ulteriori informazioni e/o ulteriori estensioni purché nel rispetto della
specifica [RFC5280] e delle linee guida [EVGL], salvaguardando la funzionalità del certificato per l’uso previsto.
7.1.11 SSL Server Wildcard DV (Domain Validated)
Il certificato per SSL Server Wildcard DV viene emesso col seguente profilo:
Campo Valore
Version V3 (2)
SerialNumber <8 random bytes>
Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)
Issuer <DN della CA che ha emesso il certificato>
Validity <12 oppure 24 oppure 36 mesi>
Subject OU = “Domain Control Validated by Actalis S.p.A.” CN = < FQDN wildcard, contenuto anche nella estensione SAN >
SubjectPublicKeyInfo <chiave pubblica RSA da 2048 bit>
SignatureValue <firma della CA>
Estensione Valore
Basic Constraints <assente>
AuthorityKeyIdentifier (AKI) <valore dell’estensione SKI della CA emittente>
SubjectKeyIdentifier (SKI) <digest SHA1 della chiave pubblica>
KeyUsage critico: digitalSignature, keyEncipherment
ExtendedKeyUsage (EKU) serverAuth (1.3.6.1.5.5.7.3.1), clientAuth (1.3.6.1.5.5.7.3.2)
CertificatePolicies PolicyOID = 1.3.159.1.23.1 PolicyOID = 2.23.140.1.2.1 CPS-URI = <indirizzo HTTP di questo CPS>
SubjectAlternativeName (SAN) <Stesso FQDN wildcard contenuto nel campo Subject.CN >
AuthorityInformationAccess (AIA) <indirizzo HTTP del servizio OCSP> <indirizzo HTTP del certificato della CA emittente>
CRLDistributionPoints (CDP) <indirizzo HTTP per accedere alla CRL> <indirizzo LDAP per accedere alla CRL>
La CA si riserva di inserire nel certificato ulteriori informazioni e/o ulteriori estensioni purché nel rispetto della
specifica [RFC5280] e delle linee guida [EVGL], salvaguardando la funzionalità del certificato per l’uso previsto.
7.2 Profilo della CRL
Le CRL sono conformi allo standard internazionale ISO/IEC 9594-8:2005 [X.509] e alla specifica pubblica [RFC
5280].
Oltre ai dati obbligatori, le CRL contengono:
il campo nextUpdate (data prevista per la prossima emissione della CRL)
l’estensione cRLNumber (numero progressivo della CRL)
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 47 di 55 28 Agosto 2017
La CRL è firmata con algoritmo sha256WithRSAEncryption (1.2.840.113549.1.1.11).
Inoltre, in corrispondenza di ogni voce della CRL è presente l’estensione reasonCode a indicare la motivazione
della sospensione o revoca.
7.3 Profilo OCSP
Il servizio OCSP erogato da Actalis è conforme alla specifica pubblica [RFC6960].
Le risposte OCSP non sono firmate direttamente con la chiave privata della CA che emette i certificati, bensì
con la chiave specifica del risponditore OCSP. Il certificato del risponditore OCSP pertanto contiene il key pur-
pose ocspSigning (OID 1.3.6.1.5.5.7.3.9) nell’estensione ExtendedKeyUsage. Inoltre, il certificato del rispondi-
tore OCSP contiene l’estensione id-pkix-ocsp-nocheck (OID 1.3.6.1.5.5.7.48.1.5).
La risposta OCSP è conforme al profilo “pkix-ocsp-basic” (OID 1.3.6.1.5.5.7.48.1.1).
La versione della risposta OCSP è v1 (0).
La risposta OCSP contiene l’estensione Nonce (OID 1.3.6.1.5.5.7.48.1.2).
8 Verifiche di conformità
L’infrastruttura tecnologica, le procedure operative, le misure di sicurezza fisica e logica e il personale preposto
all’erogazione del servizio descritto in questo CPS sono gli stessi utilizzati nell’ambito del servizio Actalis di
emissione e gestione dei certificati qualificati per firma digitale a norma di legge.
Actalis è un certificatore accreditato per la firma elettronica qualificata ai sensi della normativa europea; per-
tanto, Actalis è soggetta a un periodico accertamento di conformità (“vigilanza”) da parte dell’AgID5 ed è inoltre
tenuta a svolgere periodiche ispezioni interne.
8.1 Frequenza e circostanze dalle verifiche
Indipendentemente dalle ispezioni da parte dell’AgID, Actalis si impegna a fare in modo che una verifica di con-
formità sia svolta almeno ogni 12 mesi, ingaggiando se necessario un auditor esterno e indipendente.
Le ispezioni interne sono svolte nel rispetto di un piano che prevede frequenze diverse (da trimestrale ad an-
nuale) per i diversi aspetti tecnico-operativi del servizio di CA.
8.1.1 Root CA
Una verifica di conformità (audit) della Root CA al presente CPS viene svolta con frequenza annuale da un sog-
getto esterno indipendente e qualificato, sulla base dei criteri [POLREQ].
8.1.2 Sub CA
Una verifica di conformità (audit) della Root CA al presente CPS viene svolta con frequenza annuale da un sog-
getto esterno indipendente e qualificato, sulla base dei criteri [POLREQ].
8.1.3 Registration Authorities
Le ispezioni sulle RA sono svolte almeno una volta l’anno a cura della Sub CA.
5 www.agid.gov.it
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 48 di 55 28 Agosto 2017
8.2 Identità e qualificazione degli ispettori
Le verifiche interne sono svolte dal responsabile auditing di Actalis, adeguatamente qualificato.
Le verifiche esterne sono svolte da soggetti indipendenti da Actalis e adeguatamente qualificati.
8.3 Relazioni tra la CA e gli ispettori
Non esiste alcuna relazione tra la CA e l’auditor esterno che possa in alcun modo influenzare l’esito delle verifi-
che svolte.
Il responsabile Auditing di Actalis è un dipendente che riporta direttamente alla Direzione ed è pertanto indi-
pendente dalla struttura organizzativa preposta all’erogazione del servizio di CA.
8.4 Argomenti coperti dalle verifiche
L’ispezione svolta dagli auditor esterni (indipendenti dall’AgID) è finalizzata a verificare la conformità del servi-
zio CA di Actalis al presente CPS sulla base dei criteri [POLREQ].
L’ispezione interna è principalmente rivolta a verificare il rispetto delle procedure operative della CA e la loro
conformità al presente CPS e conseguentemente la loro conformità ai [BR] e alle [EVGL].
8.5 Azioni conseguenti alle non-conformità
Nel caso di non-conformità, l’AgID richiede alla CA di adottare le necessarie misure correttive entro un certo
arco di tempo, pena la sospensione o revoca dell’accreditamento.
Le eventuali non-conformità rilevate da altri auditor sono portate all’attenzione della Direzione aziendale che
stabilisce caso per caso come gestirle, tenendo conto delle indicazioni dell’auditor.
8.6 Comunicazione dei risultati delle verifiche
Il risultato dell’ispezione svolta dall’AgID viene condiviso con la CA interessata attraverso un apposito verbale.
Il risultato dell’ispezione esterna svolta da altri soggetti viene comunicato alla Direzione aziendale e ai respon-
sabili della struttura organizzativa preposta all’erogazione del servizio di CA attraverso un rapporto di ispe-
zione.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 49 di 55 28 Agosto 2017
9 Condizioni generali del servizio
Le “Condizioni Generali” del servizio sono fornite all’utente come documento separato, da accettare in fase di
richiesta, disponibile sul sito web della CA (vedere il paragrafo 2.2).
9.1 Tariffe del servizio
Le tariffe massime del servizio sono pubblicate sul sito web della CA: www.actalis.it.
Condizioni diverse possono essere negoziate caso per caso, in base ai volumi richiesti.
Le tariffe del servizio sono soggette a modifiche senza preavviso.
9.2 Responsabilità finanziaria
Actalis ha stipulato un’apposita assicurazione a copertura dei rischi derivanti dall'erogazione del servizio di cer-
tificazione. La compagnia assicurativa ha un rating almeno “A” nella Best’s Insurance Guide.
In particolare, Actalis ha un’assicurazione di tipo commerciale generale, con un massimale di almeno due milio-
ni (2.000.000) di USD, e un’assicurazione specifica per affidabilità professionale, errori ed omissioni con un
massimale di almeno cinque milioni (5.000.000) di USD che include:
i. copertura per danni dovuti a azioni, errori o omissioni, violazione non intenzionale di contratti o negli-
genza nell’emissione o mantenimento di certificati (EV e non-EV);
ii. danni dovuti a violazione di diritti di proprietà di terze parti (escluse le violazioni di copyright e trade-
mark), violazioni di privacy e perdita di immagine.
9.3 Tutela della riservatezza e trattamento dei dati personali
Actalis è titolare dei dati personali raccolti in fase di identificazione e registrazione dei soggetti che richiedono i
certificati e si obbliga quindi a trattare tali dati con la massima riservatezza e nel rispetto di quanto previsto dal
Decreto Legislativo n.196 del 2003 [DLGS196].
9.3.1 Informativa ai sensi del D.Lgs. 196/03
Actalis, titolare del trattamento dei dati forniti dal titolare, informa il titolare stesso, ai sensi e per gli effetti di
cui al [DLGS196], che tali dati personali saranno trattati mediante archivi cartacei e strumenti informatici e te-
lematici idonei a garantirne la sicurezza e la riservatezza nel rispetto delle modalità indicate nel succitato De-
creto.
I dati forniti dal richiedente si distinguono in obbligatori e facoltativi. I dati obbligatori sono necessari allo svol-
gimento del servizio; il loro mancato conferimento da parte del titolare comporta l’impossibilità di concludere il
contratto. I dati facoltativi agevolano semplicemente il servizio; il loro mancato conferimento non ostacola la
conclusione del contratto.
I dati forniti dal richiedente sono trattati esclusivamente per le finalità di rilascio o rinnovo dei certificati, e po-
tranno essere comunicati alle società che forniscono consulenza ed assistenza tecnica ad Actalis. In relazione a
tali trattamenti di dati, il titolare potrà esercitare i diritti di cui al [DLGS196].
9.3.2 Archivi contenenti dati personali
Gli archivi contenenti dati personali sono:
il database di registrazione
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 50 di 55 28 Agosto 2017
l’archivio della documentazione cartacea
Gli archivi sopra elencati sono gestiti dal responsabile della registrazione, e sono adeguatamente protetti dagli
accessi non autorizzati.
9.3.3 Misure di tutela della riservatezza
Actalis, in qualità di certificatore, tratta i dati personali nel rispetto del [DLGS196] e successive modificazioni,
ponendo in opera misure di sicurezza rispondenti almeno ai requisiti del Capo II (“Misure minime di sicurezza”)
dello stesso decreto. In particolare, Actalis:
mantiene un aggiornato “Documento Programmatico della Sicurezza” (DPS)
adotta un opportuno sistema di controllo degli accessi agli archivi
adotta opportune procedure di gestione delle credenziali di autenticazione
mantiene un registro permanente (audit log) degli accessi agli archivi
effettua periodicamente copie di sicurezza dei dati, al fine di garantirne il ripristino
Limitatamente al servizio erogato sulla base di questo CPS, il certificatore non raccoglie e non tratta “dati sen-
sibili” né “dati giudiziari” ai sensi dell’articolo 4 del [DLGS196].
9.4 Diritti di proprietà intellettuale
Il presente CPS è di proprietà di Actalis che si riserva tutti i diritti ad esso relativi.
Il titolare del certificato mantiene tutti gli eventuali diritti sui propri marchi commerciali (brand name), e sul
proprio nome di dominio.
Relativamente alla proprietà di altri dati ed informazioni si applicano le leggi vigenti.
9.5 Obblighi e garanzie
9.5.1 Certification Authority
La CA si impegna a:
operare in conformità a questo CPS;
identificare i richiedenti come descritto in questo CPS;
emettere e gestire i certificati come descritto nel presente CPS;
fornire un efficiente servizio di sospensione o revoca dei certificati;
garantire che il titolare possedeva, al momento dell’emissione del certificato, la corrispondente chiave
privata;
segnalare tempestivamente l’eventuale compromissione della propria chiave privata;
fornire informazioni chiare e complete sulle procedure e requisiti del servizio;
rendere disponibile una copia di questo CPS a chiunque ne faccia richiesta;
garantire un trattamento dei dati personali conforme alle norme vigenti;
fornire un servizio informativo efficiente ed affidabile sullo stato dei certificati.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 51 di 55 28 Agosto 2017
9.5.2 Registration Authority
Questo paragrafo si applica solo al caso di Registration Authority esterna, ossia delegata al Cliente in qualità di
Enterprise RA (vedere il paragrafo 1.3.2). In tal caso, la RA ha l’obbligo di:
utilizzare gli strumenti e procedure messi a disposizione dalla CA solo nel modo previsto;
accedere all’interfaccia amministrativa web-based, messa a disposizione dalla CA, solo da stazioni di
lavoro dotate di un anti-virus di buona qualità e mantenuto costantemente aggiornato;
assicurare la confidenzialità delle credenziali, fornite dalla CA, per l’accesso all’interfaccia amministra-
tiva web-based.
9.5.3 Titolari di certificati
Il titolare del certificato ha l’obbligo di:
leggere, comprendere ed accettare integralmente questo CPS;
richiedere il certificato con le modalità previste da questo CPS;
fornire alla CA informazioni esatte e veritiere in fase di registrazione;
assicurare la confidenzialità dei codici riservati ricevuti dalla CA;
adottare misure tecniche ed organizzative idonee atte ad evitare la compromissione della propria
chiave privata;
installare e utilizzare il certificato solo dopo aver controllato che esso contiene informazioni corrette;
utilizzare il certificato unicamente con le modalità e per le finalità previste da questo CPS;
non usare mai, per nessuna ragione, la propria chiave privata per emettere a sua volta certificati;
richiedere immediatamente la sospensione del certificato nel caso di sospetta compromissione della
propria chiave privata;
nel caso di accertata compromissione della propria chiave privata, richiedere immediatamente la
revoca del certificato e cessare immediatamente l’utilizzo della chiave privata stessa;
nel caso di compromissione della CA, cessare immediatamente l’utilizzo del certificato;
richiedere immediatamente la revoca del certificato nel caso in cui una o più delle informazioni
contenute nel certificato (es. ragione sociale, indirizzo del sito web, ecc) perdano di validità;
successivamente all’emissione e fino alla scadenza o revoca del certificato, avvisare prontamente la CA
di ogni variazione alle informazioni fornite in fase di richiesta;
rispondere entro 48 ore alle richieste della CA relative al possibile uso improprio del certificato o
compromissione della chiave;
al momento della eventuale revoca del certificato, cessare immediatamente l’uso del certificato e
inoltre…
– nel caso di certificato per Code Signing: rimuovere prontamente il software firmato dai siti web sui quali esso è pubblicato,
– nel caso di certificato SSL Server: rimuovere prontamente il certificato dal sito web sul quale esso è installato;
cessare ogni utilizzo del certificato dopo la data di scadenza dello stesso.
Inoltre, i titolari dei certificati si impegnano a:
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 52 di 55 28 Agosto 2017
nel caso dei certificati per Code Signing: non firmare software maligno (es. spyware) e non descrivere il
software firmato in modo fuorviante rispetto alle sue reali funzionalità e finalità;
nel caso dei certificati SSL Server: installare il certificato esclusivamente sui siti web e domini previsti
(come indicati nel certificato stesso) e utilizzarlo nel rispetto del presente CPS e delle norme vigenti.
Il titolare riconosce e accetta che la CA, qualora e non appena scopra che il certificato viene usato dal Titolare
per attività illecite (es. “Phishing”, attacchi di tipo “man-in-the-middle”, distribuzione di malware, ecc.) e/o per
l’emissione di altri certificati, effettuerà una revoca immediata e senza preavviso del certificato.
9.5.4 Relying party
Si definisce “Relying Party” chiunque faccia affidamento su un certificato per prendere decisioni (come ad
esempio: rendere disponibili informazioni o risorse al titolare del certificato, utilizzare le informazioni o risorse
ottenute dal titolare del certificato, ecc.).
Le relying party che si affidano ai certificati emessi secondo questo CPS hanno l’obbligo di:
compiere uno sforzo ragionevole per acquisire sufficienti informazioni sul funzionamento dei certificati
e delle PKI;
verificare lo stato dei certificati emessi da Actalis sulla base di questo CPS, accedendo ai servizi
informativi descritti nella sezione 4.10;
fare affidamento su un certificato solo se esso non è scaduto, sospeso o revocato.
9.6 Esclusione di garanzie
La CA non ha ulteriori obblighi e non garantisce nulla più di quanto espressamente indicato in questo CPS (ve-
dere la sezione 9.5.1) o previsto dalle norme vigenti.
9.7 Limitazioni di responsabilità
La CA declina ogni responsabilità per gli eventuali danni sofferti da chicchessia a causa del mancato rispetto, da
parte del cliente o soggetti terzi, di una o più parti di questo CPS.
La CA declina ogni responsabilità per gli eventuali danni sofferti dal cliente a causa della mancata ricezione del-
le comunicazioni della CA in conseguenza di un errato indirizzo di e-mail fornito in fase di richiesta.
Fatti salvi i limiti inderogabili di legge, la responsabilità di Actalis, a qualsiasi titolo derivante dal presente CPS,
sussisterà solo nei casi di dolo o colpa grave.
9.8 Risarcimenti
I clienti sono obbligati al risarcimento dei danni eventualmente sofferti da Actalis nei seguenti casi:
falsa dichiarazione nella richiesta di certificazione;
omessa informazione su atti o fatti essenziali per negligenza o con l’obiettivo di raggirare Actalis;
utilizzo di nomi (per es. nomi di dominio, marchi commerciali) in violazione dei diritti di proprietà
intellettuale.
9.9 Durata e terminazione
Questo CPS entra in vigore al momento della sua pubblicazione nel repository (vedere il capitolo 2) e resta in
vigore fino al momento della sua eventuale sostituzione con una nuova versione.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 53 di 55 28 Agosto 2017
9.10 Comunicazioni e assistenza
Le comunicazioni relative a questo CPS (es. dubbi di interpretazione) possono essere inviate ad Actalis con le
modalità indicate nel par. 1.5. Actalis si impegna a rispondere entro una settimana lavorativa.
Le richieste di assistenza relative al servizio qui descritto (per es. dubbi di carattere operativo, mancata ricezio-
ne del certificato, difficoltà di installazione, ecc.) possono essere fatte ad Actalis nel caso in cui il certificato sia
stato acquistato direttamente da Actalis. In questo caso, si può richiedere assistenza mediante e-mail all’indi-
rizzo [email protected] avendo cura di riportare nella mail, oltre alla descrizione del presunto problema,
perlomeno il nome, cognome, numero di telefono e organizzazione di appartenenza del mittente. Se invece il
certificato è stato acquistato da un rivenditore di Actalis, l’assistenza deve essere richiesta a quel rivenditore.
Le segnalazioni di problemi sui certificati già emessi ed installati, invece, devono essere fatte con le modalità
descritte nel paragrafo 4.13.
9.11 Emendamenti
Actalis si riserva facoltà di modificare questo CPS in qualsiasi momento, senza preavviso.
9.12 Risoluzione delle dispute
Qualsiasi controversia derivante dal presente CPS tra Actalis ed i clienti del servizio è deferita al giudizio di un
collegio arbitrale. La sede dell’arbitrato sarà Bergamo.
9.13 Legge applicabile
Questo CPS è soggetto alla legge italiana e come tale sarà interpretato ed eseguito. Per quanto non espressa-
mente previsto nel presente CPS, valgono le norme vigenti.
Altri contratti in cui questo CPS è incorporato mediante riferimento, possono contenere clausole distinte ri-
spetto alla legge applicabile.
9.14 Conformità con le norme applicabili
Alla data di aggiornamento del presente CPS, Actalis non è a conoscenza di norme di legge relative al tipo di
servizio qui descritto. In ogni caso, questo CPS è soggetto alle norme applicabili.
9.15 Forza maggiore
Actalis non sarà responsabile della mancata esecuzione delle obbligazioni qui assunte qualora tale mancata
esecuzione sia dovuta a cause non imputabili ad Actalis, quali - a scopo esemplificativo e senza intento limitati-
vo - caso fortuito, disfunzioni di ordine tecnico assolutamente imprevedibili e poste al di fuori di ogni controllo,
interventi dell’autorità, cause di forza maggiore, calamità naturali, scioperi anche aziendali - ivi compresi quelli
presso soggetti di cui le parti si avvalgano nell’esecuzione delle attività connesse al servizio qui descritto - ed
altre cause imputabili a terzi.
9.16 Livelli di servizio
La CA si impegna a rispettare i seguenti livelli di servizio, salvo il meglio:
Metrica Obiettivo Base di misura
Disponibilità del directory server (24 x 7) 99.8 % annuale
Disponibilità del portale web (24 x 7) 99.8 % annuale
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Pagina 54 di 55 28 Agosto 2017
Tempo di emissione del certificato massimo 5 gg lavorativi nel 95% di casi
annuale
Tempo di sospensione o revoca del certificato (richiesta tramite il portale web della CA)
massimo 120 secondi nel 95% dei casi
annuale
Tempo di revoca del certificato (a fronte di corretta richiesta via fax, posta, email)
massimo 6 ore nel 95% dei casi
annuale