Certification Practice Statement - actalis.it · Certification Practice Statement Certificati SSL...

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



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



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



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




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



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

http://www.actalis.it/

http://www.cabforum.org/

http://www.cabforum.org/



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


https://portal.actalis.it/

mailto:[email protected]



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.



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

https://www.actalis.it/prodotti/certificati-ssl.aspx



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




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.


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


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


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

http://www.ietf.org/rfc/rfc2251.txt








http://www.iso.ch/



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

https://cabforum.org/baseline-requirements-documents/

https://cabforum.org/extended-validation/


ldap://ldap03.actalis.it/



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;



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,



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



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.



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.



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.



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.



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



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;



(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;



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



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.




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:



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:



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.



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.



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.



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.



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


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




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)



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



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.



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.



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


O = Actalis S.p.A./03358520967

L = Milano

C = IT

Validity dal 22 settembre 2011 al 22 settembre 2030

Subject


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:



Campo Valore

Version V3 (2)

SerialNumber < include almeno 8 byte pseudo-random>


Issuer


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



Estensione Valore


AuthorityKeyIdentifier (AKI) <valore dell’estensione della Root CA>

SubjectKeyIdentifier (SKI) <digest SHA1 della chiave pubblica>



CertificatePolicies PolicyOID = 2.5.29.32.0 (anyPolicy)

CPS-URI = <indirizzo HTTP di questo CPS>


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


Campo Valore

Version V3 (2)



Issuer


O = Actalis S.p.A./03358520967

L = Milano

C = IT




Subject

CN = Actalis Authentication CA GN

O = Actalis S.p.A./03358520967

L = Milano

C = IT



Estensione Valore











7.1.4 Sub CA per certificati di classe EV


Campo Valore

Version V3 (2)



Issuer


O = Actalis S.p.A./03358520967

L = Milano

C = IT


Subject

CN = Actalis Extended Validation Server CA GN

O = Actalis S.p.A./03358520967

L = Milano

C = IT



Estensione Valore













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>


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>



Estensione Valore

Basic Constraints <assente>

AuthorityKeyIdentifier (AKI) <valore dell’estensione SKI della CA emittente>


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.



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)




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>



Estensione Valore


AuthorityKeyIdentifier (AKI) <valore della estensione SKI della CA emittente>


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>





7.1.7 SSL Server OV (Organization Validated)

Il certificato per SSL Server OV viene emesso col seguente profilo:



Campo Valore

Version V3 (2)




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>



Estensione Valore






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





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)




Validity <12, 24 o 36 mesi >

4 Nel caso delle organizzazioni registrate in Italia, si tratta in generale della Partita IVA.



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>



Estensione Valore







SubjectAlternativeName (SAN) <Stesso FQDN wildcard contenuto nel campo Subject.CN >





7.1.9 Code Signing OV (Organization Validated)

Il certificato per Code Signing OV viene emesso col seguente profilo:

Campo Valore

Version V3 (2)




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 >



Estensione Valore




AuthorityKeyIdentifier (AKI) <valore della estensione SKI della CA emittente>


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>





7.1.10 SSL Server DV (Domain Validated)

Il certificato per SSL Server DV viene emesso col seguente profilo:

Campo Valore

Version V3 (2)





Subject OU = “Domain Control Validated by Actalis S.p.A.” CN = <uno dei FQDN contenuti nella estensione SAN>



Estensione Valore







SubjectAlternativeName (SAN) <contiene uno o più FQDN, in conformità a [BR]>







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)





Subject OU = “Domain Control Validated by Actalis S.p.A.” CN = < FQDN wildcard, contenuto anche nella estensione SAN >



Estensione Valore







SubjectAlternativeName (SAN) <Stesso FQDN wildcard contenuto nel campo Subject.CN >





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)



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


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

http://www.agid.gov.it/



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.



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


http://www.ambest.com/ratings/guide.asp



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.



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:



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.



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




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

Certification Practice Statement - actalis.it · Certification Practice Statement Certificati SSL...

Documents

Transcript of Certification Practice Statement - actalis.it · Certification Practice Statement Certificati SSL...