Upload
others
View
18
Download
0
Embed Size (px)
Citation preview
Certification Practice Statement
SSL Server and Code Signing certificates
Version: 2.3
Date: 09 December 2014
Certification Practice Statement
SSL Server and Code Signing certificates
Written by: Adriano Santoni
Resp. Security
Date Verified by: Fabio Omenigrandi
Resp. Technical Services
Date Verified by: Rosalia Valsecchi
Resp. Certification
Date Verified by: Roberto Ravazza
Resp. Operations
Date Verified by: Giorgio Marzorati
Internal Auditor
Date Approved by Giorgio Girelli
Director General
Date
Document Code:
CAACT-03-01-04
Distribution:
PUBLIC
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 2 of 49 09 December 2014
Change History
DATE VERS. PARAGRAPHS CHANGES AUTHOR
14 Dec. 2005 1 - Initial release FP
24 June 2009 2 all Complete review of document in accordance with RFC 3647
FP, AS
19 Nov. 09 2.0.1 1.3.1 Changed name of President AS
13 May 2010 2.0.2 3.4 Removed sentence referring to private IP addresses in certificates (that is not allowed)
AS
18 May 2010 2.0.3 4.2, 8.1, 8.2, 8.4, 8.5, 8.6,
9.5.2, 9.8
Clarifications and integrations related to RAs AS
18 May 2010 2.0.3 1.3.1 Updated Actalis’ address; corrected the given name of the President.
AS
14 June 2011 2.0.4 1.3.1, 3.1, 4.1 Updated Actalis’ legal representative. Clarified I&A and pre-issuance checks for
wildcard and multi-SAN certificates
AS
28 Sep 2011 2.1.0 all Transition to a 2-level CA hierarchy (Root CA, SubCA). Added details about management of CA keys. Clarified that two-factor authentic-
ation is required for all accounts allowing certificate issuance. Clarified that certificate
serial numbers include at least 8 random bytes. SHA-256 used for certificate and CRL issuance. Updated minimum key lengths.
AS
6 Nov 2013 2.2.3 all Alignment to Italian CPS v2.2.3 AS
13 Nov 2013 2.2.4 all Updated name of Actalis CEO in §1.3.1. New section 4.13 on certificate problem reporting.
Modified §1.3.2 to cover Enterprise RAs. Addedd OV profiles in §1.4 and in chapter 7. Modified §3.1 for more clarity. Clarifications
in §3.3 regarding checks. Clarifications on the use CNames in CRL and OCSP URLs.
AS
14 Feb 2014 2.2.5 all CAB Forum compliance made explicit at beginning of chapter 3. Clarification about
IDNs.
AS
03 Sep 2014 2.2.6 3.1.1, 4.13, 6.33
Clarified that hostnames are not allowed in Code Signing certificates. Added phone
number for certificate problem reporting. Keys of 1024-bits are not allowed anymore.
AS
20 Oct 2014 2.2.7 all Added support of DV (Domain Validated) certificates. Added digital signature as a means to validate individual identities.
Correction of typos and some clarifications.
AS
9 Dec 2014 2.3 all Correction of typos. AS
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 3 of 49 09 December 2014
Table of Contents
1. INTRODUCTION ........................................................................................................................................ 6
1.1 OVERVIEW .................................................................................................................................................. 6 1.2 DOCUMENT IDENTIFICATION ........................................................................................................................... 6 1.3 PARTICIPANTS TO PUBLIC KEY INFRASTRUCTURE (PKI) ......................................................................................... 6
1.3.1 Certification Authority ..................................................................................................................... 6 1.3.1.1 Root Certification Authority ......................................................................................................................... 7 1.3.1.2 Subordinate Certification Authority ............................................................................................................. 7
1.3.2 Registration Authorities ................................................................................................................... 7 1.3.3 Subscribers ....................................................................................................................................... 8 1.3.4 Relying parties ................................................................................................................................. 8
1.4 USE OF CERTIFICATES ..................................................................................................................................... 8 1.5 ADMINISTRATION OF CPS .............................................................................................................................. 9 1.6 DEFINITIONS AND ACRONYMS ......................................................................................................................... 9 1.7 LIST OF REFERENCES .................................................................................................................................... 10
2 PUBLICATIONS AND REPOSITORY ............................................................................................................11
2.1 REPOSITORY MANAGEMENT .......................................................................................................................... 11 2.2 PUBLISHED INFORMATION ............................................................................................................................ 11 2.3 TIME AND FREQUENCY OF PUBLICATIONS ......................................................................................................... 11 2.4 ACCESS CONTROL ....................................................................................................................................... 11
3 IDENTIFICATION AND AUTHENTICATION (I&A) .......................................................................................12
3.1 NAMING RULES .......................................................................................................................................... 12 3.1.1 For all certificate classes ................................................................................................................ 12 3.1.2 For EV-class certificates ................................................................................................................. 13 3.1.3 For DV-class certificates ................................................................................................................. 13
3.2 INITIAL IDENTITY VALIDATION ........................................................................................................................ 13 3.2.1 Proving possession of private key .................................................................................................. 13 3.2.2 Authentication of organization identity......................................................................................... 13 3.2.3 Authentication of individual identity ............................................................................................. 14
3.3 FURTHER VERIFICATIONS BY THE CA ............................................................................................................... 14 3.3.1 For all classes of SSL Server certificates ......................................................................................... 14
3.3.1.1 Internationalized Domain Names (IDN) ..................................................................................................... 15 3.3.2 For EV-class certificates ................................................................................................................. 15
3.4 INFORMATION NOT VERIFIED BY THE CA .......................................................................................................... 15 3.5 I&A FOR RENEWAL APPLICATIONS .................................................................................................................. 16 3.6 I&A FOR REQUESTS TO SUSPEND OR REVOKE .................................................................................................... 16
4 CERTIFICATE MANAGEMENT OPERATIONAL REQUIREMENTS .................................................................16
4.1 CERTIFICATE APPLICATION ............................................................................................................................ 16 4.2 APPLICATION PROCESSING ............................................................................................................................ 17 4.3 ISSUE OF CERTIFICATES ................................................................................................................................. 17 4.4 CERTIFICATE ACCEPTANCE ............................................................................................................................ 18 4.5 USE OF KEY PAIR AND CERTIFICATE ................................................................................................................. 18 4.6 CERTIFICATE RENEWAL ................................................................................................................................. 18 4.7 KEY RE-GENERATION ................................................................................................................................... 18 4.8 CERTIFICATE MODIFICATION .......................................................................................................................... 19 4.9 CERTIFICATE SUSPENSION AND REVOCATION .................................................................................................... 19
4.9.1 Reasons for suspension .................................................................................................................. 19 4.9.2 Request for suspension .................................................................................................................. 19 4.9.3 Suspension procedure .................................................................................................................... 19 4.9.4 Certificate revocation .................................................................................................................... 20 4.9.5 Revocation request ........................................................................................................................ 21
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 4 of 49 09 December 2014
4.9.6 Procedure for suspension or revocation ........................................................................................ 21 4.9.7 Frequency of issue of CRL............................................................................................................... 21
4.10 CERTIFICATE STATUS INFORMATION ................................................................................................................ 21 4.10.1 Operational characteristics ............................................................................................................ 21 4.10.2 Service availability ......................................................................................................................... 22
4.11 CONTRACT TERMINATION ............................................................................................................................. 22 4.12 KEY ESCROW AND RECOVERY ......................................................................................................................... 22 4.13 CERTIFICATE PROBLEM REPORTING ................................................................................................................. 23
5 PHYSICAL AND OPERATIONAL SECURITY CONTROLS ...............................................................................23
5.1 PHYSICAL SECURITY ..................................................................................................................................... 24 5.2 PROCEDURAL CONTROLS .............................................................................................................................. 24 5.3 PERSONNEL CONTROLS ................................................................................................................................ 24 5.4 EVENT LOGGING ......................................................................................................................................... 24 5.5 DATA RETENTION AND ARCHIVAL ................................................................................................................... 25 5.6 RENEWAL OF CA KEY ................................................................................................................................... 25
5.6.1 Root CA .......................................................................................................................................... 25 5.6.2 Sub CA ............................................................................................................................................ 25
5.7 BACKUP COPY ............................................................................................................................................ 25 5.8 COMPROMISE AND DISASTER RECOVERY .......................................................................................................... 25 5.9 CESSATION OF THE CA ................................................................................................................................. 26
6 TECHNICAL SECURITY CONTROLS ............................................................................................................26
6.1 KEY GENERATION ........................................................................................................................................ 26 6.1.1 Root CA .......................................................................................................................................... 26 6.1.2 Sub CA ............................................................................................................................................ 27 6.1.3 Subscribers ..................................................................................................................................... 27
6.2 DISTRIBUTION OF PUBLIC KEY ........................................................................................................................ 27 6.2.1 Root CA .......................................................................................................................................... 27 6.2.2 Sub CA ............................................................................................................................................ 27 6.2.3 Subscribers ..................................................................................................................................... 27
6.3 KEY SIZE .................................................................................................................................................... 27 6.3.1 Root CA .......................................................................................................................................... 27 6.3.2 Sub CA ............................................................................................................................................ 27 6.3.3 Subscribers ..................................................................................................................................... 27
6.4 PARAMETERS GENERATION AND KEY QUALITY ................................................................................................... 28 6.4.1 Root CA .......................................................................................................................................... 28 6.4.2 Sub CA ............................................................................................................................................ 28 6.4.3 Subscribers ..................................................................................................................................... 28
6.5 KEY USAGE (X.509V3 EXTENSION) ................................................................................................................. 28 6.5.1 Root CA .......................................................................................................................................... 28 6.5.2 Sub CA ............................................................................................................................................ 28 6.5.3 Subscribers ..................................................................................................................................... 28
6.6 PROTECTION OF PRIVATE KEY ........................................................................................................................ 28 6.6.1 Root CA .......................................................................................................................................... 28 6.6.2 Sub CA ............................................................................................................................................ 29 6.6.3 Subscribers ..................................................................................................................................... 29
6.7 SECURITY STANDARD FOR CRYPTOGRAPH MODULES ........................................................................................... 29 6.8 PRIVATE KEY (N OUT OF M) MULTI-PERSON CONTROL ....................................................................................... 29
6.8.1 Root CA .......................................................................................................................................... 29 6.8.2 Sub CA ............................................................................................................................................ 29 6.8.3 Subscribers ..................................................................................................................................... 29
6.9 BACKUP AND RECOVERY OF PRIVATE KEY .......................................................................................................... 29 6.9.1 Root CA .......................................................................................................................................... 29 6.9.2 Sub CA ............................................................................................................................................ 29 6.9.3 Subscribers ..................................................................................................................................... 29
6.10 KEY ACTIVATION DATA ................................................................................................................................. 30
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 5 of 49 09 December 2014
6.10.1 Root CA .......................................................................................................................................... 30 6.10.2 Sub CA ............................................................................................................................................ 30 6.10.3 Subscribers ..................................................................................................................................... 30
6.11 COMPUTER SECURITY REQUIREMENTS AND CONTROLS........................................................................................ 30 6.12 NETWORK SECURITY REQUIREMENTS AND CONTROLS ......................................................................................... 30 6.13 CLOCK SYNCHRONISATION ............................................................................................................................ 31
7 CERTIFICATE AND CRL PROFILES ..............................................................................................................32
7.1 CERTIFICATE PROFILE ................................................................................................................................... 32 7.1.1 Root CA .......................................................................................................................................... 32 7.1.2 Sub CA ............................................................................................................................................ 33 7.1.3 SSL Server EV (Extended Validation) .............................................................................................. 34 7.1.4 Code Signing EV (Extended Validation).......................................................................................... 35 7.1.5 SSL Server OV (Organization Validated) ........................................................................................ 36 7.1.6 SSL Server Wildcard OV (Organization Validated) ......................................................................... 37 7.1.7 Code Signing OV (Organization Validated) .................................................................................... 38 7.1.8 SSL Server DV (Domain Validated) ................................................................................................. 39 7.1.9 SSL Server Wildcard DV (Domain Validated) ................................................................................. 40
7.2 CRL PROFILE .............................................................................................................................................. 41
8 COMPLIANCE AUDITS AND OTHER ASSESSMENTS ...................................................................................41
8.1 FREQUENCY OR CIRCUMSTANCES OF ASSESSMENT ............................................................................................. 41 8.1.1 Root CA .......................................................................................................................................... 41 8.1.2 Sub CA ............................................................................................................................................ 41 8.1.3 Registration Authorities ................................................................................................................. 41
8.2 IDENTITY AND QUALIFICATION OF ASSESSOR ..................................................................................................... 42 8.3 ASSESSOR’S RELATIONSHIP TO ASSESSED ENTITY ................................................................................................ 42 8.4 TOPICS COVERED BY ASSESSMENT .................................................................................................................. 42 8.5 ACTIONS TAKEN AS A RESULT OF DEFICIENCY ..................................................................................................... 42 8.6 COMMUNICATION OF RESULTS ...................................................................................................................... 42
9 OTHER BUSINESS AND LEGAL MATTERS ..................................................................................................43
9.1 SERVICE FEES ............................................................................................................................................. 43 9.2 FINANCIAL RESPONSIBILITY ........................................................................................................................... 43 9.3 PRIVACY OF PERSONAL INFORMATION ............................................................................................................. 43
9.3.1 Information pursuant to Legislative Decree n.196/2003 ............................................................... 43 9.3.2 Archives containing personal information ..................................................................................... 44 9.3.3 Privacy protection measures.......................................................................................................... 44
9.4 INTELLECTUAL PROPERTY RIGHTS .................................................................................................................... 44 9.5 OBLIGATIONS AND GUARANTEES .................................................................................................................... 44
9.5.1 Certification Authority ................................................................................................................... 44 9.5.2 Registration Authority ................................................................................................................... 45 9.5.3 Subscribers ..................................................................................................................................... 45 9.5.4 Relying parties ............................................................................................................................... 46
9.6 DISCLAIMERS OF WARRANTIES ....................................................................................................................... 46 9.7 LIMITATIONS OF LIABILITY ............................................................................................................................. 46 9.8 INDEMNITIES ............................................................................................................................................. 46 9.9 TERM AND TERMINATION ............................................................................................................................. 47 9.10 CORRESPONDENCE ...................................................................................................................................... 47 9.11 AMENDMENTS ........................................................................................................................................... 47 9.12 RESOLUTION OF DISPUTES ............................................................................................................................ 47 9.13 APPLICABLE LAW ........................................................................................................................................ 47 9.14 COMPLIANCE WITH APPLICABLE LAW .............................................................................................................. 47 9.15 FORCE MAJEURE ......................................................................................................................................... 47 9.16 SERVICE LEVELS .......................................................................................................................................... 48
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 6 of 49 09 December 2014
1. Introduction
1.1 Overview
Actalis S.p.A. has been a leading provider since 2002 of certification services, accredited by AgID under the EU
Electronic Signatures Directive, and offers several types of certificates and related management services, as
well as other services and solutions (www.actalis.it).
A certificate binds a public key to a set of information that identifies an entity (individual or organization). This
entity, the subscriber or owner of the certificate, possesses and utilizes the corresponding public key. The cer-
tificate is generated and supplied to the owner by a trusted third party known as Certification Authority (CA).
The certificate is digitally signed by the CA.
The reliability of a certificate, in other words the dependable association of a given public key with the identi-
fied subject, also depends on the CA’s operating procedures, the obligations and responsibilities between the
certification authority and subscriber, and the CA’s physical and logical security controls. All those aspects are
described in a public document called Certification Practice Statement (CPS).
This document is Actalis’ CPS relevant to the issuance and management of two types of certificates:
SSL Server certificates
Code Signing certificates
The structure of this CPS conforms to the public specification [RFC 3647].
Within the Certification Authority services herein described, Actalis conforms to version 1.1 of the Baseline Re-
quirements for the Issuance and Management of Publicly-Trusted Certificates published at
http://www.cabforum.org. In the event of any inconsistency between this document and those Requirements,
those Requirements take precedence over this document.
Furthermore, with regard to certificate types denoted by “EV” (see section 1.2), Actalis conforms to version 1.3
of the CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates pub-
lished at http://www.cabforum.org. In the event of any inconsistency between this document and those Guide-
lines, those Guidelines take precedence over this document.
1.2 Document Identification
This document is the Certification Practice Statement (CPS) applying to SSL Server and Code Signing certifi-
cates issued by Actalis S.p.A. Version and time of last revision are indicated on the first page. This document is
published on Actalis’ web site in two languages: Italian and English. In the event of any inconsistency between
the two versions, the Italian version takes precedence.
1.3 Participants to Public Key Infrastructure (PKI)
1.3.1 Certification Authority
The Certification Authority (CA) is the trusted third party who issues the certificates and signs them with its
own private key (CA key). Furthermore, the CA manages the status of the certificates.
The Actalis PKI (Public Key Infrastructure) that the SSL Server and Code Signing certificate issuance and man-
agement service is based upon is a two-level hierarchy, as shown in the following diagram:
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 7 of 49 09 December 2014
Root CA
Sub CA 1 Sub CA 2 Sub CA ...
The Root CA is used for issuing Sub CA certificates and related CRLs only, and is kept off-line when not in use,
whereas end-entity certificates are issued by Sub CAs.
Within the framework of the service described in this document, both CA roles (Root CA and Sub CA) are played
by Actalis S.p.A. (hereinafter referred to as “Actalis”), and identified as follows:
Company name: Actalis S.p.A.
Registered Office: Via dell’Aprica, 18 – 20158 Milan, Italy
Legal representative: Simone Braccagni (Chief Executive Officer)
VAT Reg. No. and Tax Code: 03358520967
Telephone (switchboard): +39 02 68825.1
DUNS number: 440-489-735
ISO Object Identifier (OID): 1.3.159
Company web site: http://www.actalis.it
Company e-mail address: [email protected]
1.3.1.1 Root Certification Authority
The Root CA is run by Actalis S.p.A. (see section 1.3.1).
1.3.1.2 Subordinate Certification Authority
There currently exists only one Sub CA, run by Actalis S.p.A. (see section 1.3.1).
The feasibility and opportunity of activating additional Sub CAs, run by other organizations, will be evaluated
later on, taking into account the requirements and constraints imposed by the applicable laws, business prac-
tices, and security policies (including those enforced by browser vendors).
1.3.2 Registration Authorities
The Registration Authority (RA) is a person, structure or organization that is responsible for:
collection and validation of certification requests and certificate management requests;
registration of the applicant and organization to which the same belongs;
authorization of issuance, by the CA, of the certificate requested;
For certificates of class EV (Extended Validation), the RA activities are performed by Actalis only.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 8 of 49 09 December 2014
For certificates of class OV (Organization Validated) and DV (Domain Validated), RA activities can be carried out
by the Customer as an “Enterprise RA”, if the conditions are met, limited to Internet domains controlled by the
Subscriber.
1.3.3 Subscribers
Certificate Owners or Subscribers are organizations or agencies requesting an SSL Server certificate or Code
Signing certificate and holding the corresponding private key. In particular, with reference to §7.2 of [EVCG],
Actalis issues certificates to following types of organizations:
Private Organization
Government Entity
In this CPS, the term “Owner” refers to the entity named “Subject” or “Subscriber” in [BR] and [EVCG].
In all cases the certificate Owner shall be an organization, not a natural person.
The contract with the CA is normally stipulated by the subscriber as the customer. Nonetheless the customer
(the party which pays the certificate and its subsequent management by CA) may be acting on behalf of the
Subject, a circumstance which must be demonstrated upon application (see §3.2.2).
1.3.4 Relying parties
Relying Parties are recipients of a certificate who act on reliance on the information contained in the certifi-
cate. In the case of an SSL Server certificate, these are the users of the relevant web site. For Code Signing cer-
tificates, these are users of the signed software.
1.4 Use of certificates
The SSL Server certificate is used to activate the TLS/SSL protocol on one or more web sites.
The Code Signing certificate is used for the digital signature of software (executable code).
Any other use of the certificates issued by Actalis in accordance with this CPS is strictly prohibited and may re-
sult, as soon as Actalis gets aware of it, the revocation of the certificate.
It is assumed that the subscriber possesses the competence and tools required to request, install and use the
certificate. At any rate, Actalis can provide all the necessary assistance as consultancy.
The following table shows the classes and policies of certificates issued under this CPS, and the applicable CAB
Forum requirements. Each policy is identified by a specific OID (Object Identifier) under the 1.3.159 arc:
Class Certificate policy OID CABF reqs.
EV SSL Server EV (Extended Validation) 1.3.159.1.17.1 [BR], [EVCG]
EV Code Signing EV (Extended Validation) 1.3.159.1.18.1 [BR], [EVCG]
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]
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 9 of 49 09 December 2014
The OID that identifies the certificate policy is contained in the CertificatePolicies certificate extension, as de-
tailed un chapter 7.
1.5 Administration of CPS
This CPS is developed, reviewed, published and updated by Actalis S.p.A.
For further information or explanations about this CPS, please write e-mail to the following address: cps-
This CPS and the certificate policies (CP) herein described are approved by Actalis’ top management, on rec-
ommendation by the CPS maintainer, after checking with all the company departments involved in the CA ser-
vice. Actalis periodically reviews its certification processes including the responsibility for maintaining this CPS,
also taking into account §8.1 of the ETSI TS 101 042 specification [POLREQ].
1.6 Definitions and acronyms
AgID Agenzia per l’Italia Digitale (Agency for a Digital Italy)
ARL Authority Revocation List
CA Certification Authority
CCIAA Chamber of Commerce, Industry, Crafts and Agriculture
CNAME Canonical Name
CNIPA Italian Authority for Informatics in Public Administration, former name of DigitPA
CPS Certification Practice Statement
CRL Certificate Revocation List
CSR Certificate Signing Request
DigitPA New name of CNIPA after Decree n.177 of December 1st
, 2009.
DN Distinguished Name
DPC (CED) Data Processing Centre
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 Identification and Authentication
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
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 10 of 49 09 December 2014
PKI Public Key Infrastructure
RA Registration Authority
SAN SubjectAlternativeNames (certificate extension)
SSL Secure Sockets Layer
TLS Transport Layer Security
UPS Uninterruptible Power Supply
VMD Video Motion Detection
1.7 List of references
[DLGS196] Legislative Decree n.196 of 30 June 2003 “Personal data protection code”, published in the Supplemento Ordinario n.123 of the Gazzetta Ufficiale n.174 of 29 July 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)
[RFC2560] Myers, M., R. Ankney, A. Malpani, S. Galperin and C. Adams, "Online Certificate Status Protocal - OCSP", June 1999. (http://www.ietf.org/rfc/rfc2560.txt)
[RFC2616] [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol, HTTP/1.1", RFC 2616, June 1999. (http://www.ietf.org/rfc/rfc2616.txt)
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. (http://www.ietf.org/rfc/rfc2818.txt)
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003. (http://www.ietf.org/rfc/rfc3647.txt)
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. (http://www.ietf.org/rfc/rfc5280.txt)
[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 TS 101 042: Electronic Signatures and Infrastructures (ESI); Policy requirements for certification authorities issuing public key certificates, v2.2.1 (2011-12).
[BR] CA/Browser Forum, “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates”, Version 1.1.
[EVCG] CA/Browser Forum, “Guidelines For The Issuance And Management Of Extended Validation Certificates”, Version 1.3.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 11 of 49 09 December 2014
2 Publications and repository
The term “repository” refers to a combination of on-line archives or registers containing information of public
interest regarding the issuance and management of certificates described in this CPS.
2.1 Repository management
The Actalis repository consists of:
CA web sites (http://www.actalis.it and other Actalis websites therein referred to)
CA directory server (ldap://ldap03.actalis.it)
Note: for load balancing reasons, the directory service is distributed on several servers with different address-
es, thus the hostname included in a particular certificates maybe different from ldap03; it will, however, be a
CNAME of this latter.
The CA manages the repository and is directly responsible for the same.
2.2 Published information
As a minimum, the CA publishes the following documentation on its own web site:
Certification Practice Statement (CPS)
Root CA and SubCA certificates
Terms & Conditions of the service
maximum fees charged for the service
request forms
Furthermore, the CA publishes CRLs on its own directory server.
For further information about the CRL refer to section 4.10.
2.3 Time and frequency of publications
The CPS and associated documentation are published in PDF format on the CA web site each time they are up-
dated.
This CPS is reviewed and, if necessary, updated at least every year.
For further information about the CRL refer to section 4.10.
2.4 Access control
Anyone can freely access the repository in read-only mode.
Access to the repository for the publication of new and updated information is only possible from work stations
directly connected to the repository local network, subject to authentication.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 12 of 49 09 December 2014
3 Identification and Authentication (I&A)
The I&A procedures followed by Actalis comply with CAB Forum requirements. In particular, for all classes of
certificates issued under this CPS, the CA peforms at least the mandatory checks provided in the Baseline Re-
quirements for the Issuance and Management of Publicly-Trusted Certificates [BR]. In addition, for certificates
of class EV, the CA also performs the additional checks required by the Guidelines For The Issuance And Man-
agement Of Extended Validation Certificates [EVCG].
3.1 Naming rules
The Subject field of the certificate, if present (according to certificate class), must contain easily understanda-
ble information allowing the identification of the certificate holder (organization). Aliases, or names other than
the certificate owner’s full legal name, are not allowed.
Names which violate the intellectual property rights of others are not allowed into certificates. Actalis shall not
be involved in any controversy whatsoever regarding the ownership of domain names, commercial names,
commercial trademarks or services. Actalis reserves the right to reject the certificate application (or revoke an
already issued certificate) in case of such a controversy.
3.1.1 For all certificate classes
For all certificate classes, the following rules apply:
The commonName (OID 2.5.4.3) component of the Subject field:
– for an SSL Server certificate, must contain one single IP address or Fully Qualified Domain Name
(FQDN) among those contained in the SAN extension;
– for a Code Signing certificate, may contain any string chosen by requestor, provided
that it is not misleading about the certificate owner’s identity or about the certificate purpose. In
any case, it must not be a hostname (qualified or not). A valid example is “ACME Code Signing”.
The organizationName (OID 2.5.4.10) component of the Subject field, if present (according to
certificate class), must contain the full legal name of the certificate owner (it must be an organization;
it cannot be a natural person); this name must be unique, that is, it must not lead to ambiguity. For an
SSL Server certificate, it must be the organization that controls the servers included in the certificate;
therefore, it will generally be the owner (registrant) of the Internet domains included in the certificate,
or its parent organization (i.e. holding), or another entity that has formally been charged of managing
those servers and/or domains on behalf of their owner.
The SubjectAlternativeNames (SAN) extension, always included in an SSL Server certificate, must
contain at least one item. Each of the items in this extension must be an IP address or an FQDN of a
server under control of the certificate owner.
Note: internal IP address and domains are deprecated by CAB Forum and will not be included in certificates having
an expiry date past November 1st
, 2015. At any rate, by October 1st
, 2016, the CA will revoke all certificates having
an internal IP address or domain within.
The optional organizationalUnitName (OID 2.5.4.11) component of the Subject field may contain any
string at the requestor’s discretion, provided that it does not mislead Relying Parties about the identity
of the certificate owner. More generally, potentially misleading information shall not be included in
the certificate.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 13 of 49 09 December 2014
The localityName (OID 2.5.4.7) component of the Subject field, if present (according to certificate
class), must contain the name of the locality (e.g. city) where the certificate owner’s registered office is
located.
The stateOrProvinceName (OID 2.5.4.8) component of the Subject field, if present (according to
certificate class), must contain the name of the Province (for Italian organizations) or Region/State (for
foreign organizations) where the certificate owner’s registered office is located.
The countryName (OID 2.5.4.6) component of the Subject field, if present (according to certificate
class), must contain the ISO 3166 two-letter code (e.g. “IT”) of the country where the certificate
owner’s registered office is located.
3.1.2 For EV-class certificates
In addition to the above rules, for EV-class certificates the following rules also apply:
the businessCategory (OID 2.5.4.15) component of the Subject field must contain the organization
type (either “Private Organization” or “Government Entity”);
the serialNumber (OID 2.5.4.5) component of the Subject field must contain the VAT Number (“Partita
IVA” for Italian organizations), or other official registration number (for foreign organizations), of the
certificate owner;
the jurisdictionOfIncorporationCountryName (OID 1.3.6.1.4.1.311.60.2.1.3) component of the Subject
field must contain the two-letter ISO 3166 code of the country where the organization (i.e. certificate
owner) was registered or incorporated;
the streetAddress (OID 2.5.4.9) component of the Subject field must contain the address (e.g. street
name and building number) of the certificate owner’s registered office.
3.1.3 For DV-class certificates
In certificates of class DV, the Subject field only contains:
the commonName component, according to section 3.1.1;
the organizationalUnitName with a fixed value of “Domain Validated by Actalis S.p.A.”
3.2 Initial identity validation
3.2.1 Proving possession of private key
The proof-of-possession, by the applicant, of the private key corresponding to the requested certificate is
based on the cryptographic verification of the CSR (Certificate Signing Request) sent to the CA. In fact the appli-
cant must send its own public key to the CA in the form of a CSR in PKCS#10 format [RFC2314]. The CA shall
verify that the digital signature in the CSR is valid.
Transmission of the CSR to the CA is normally done over the web or via electronic mail.
3.2.2 Authentication of organization identity
Authentication of the identity of the applicant organization, not applicable to DV-class certificates, includes in
any case a lookup in the relevant CCIAA (Chamber of Commerce, Industry, Crafts and Agriculture) database, for
private organizations, or in the relevant official index of public administrations, for government entities. The
name of the organization declared by the applicant must correspond with the name resulting from such
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 14 of 49 09 December 2014
lookup. In case of mismatch, unless the applicant can provide a convincing explanation, the certificate applica-
tion shall be rejected. The information gathered by the CA include at least (where applicable):
actual existence and status of the organization
full legal name of the organization
VAT code (and # of registration at a chamber of commerce, for private organizations) or an equivalent
government-issued identification code
address of head office and operation sites
Should the CA not be able to collect such information by itself, the applicant will be required to provide it to
the CA in a reliable form (such as e.g. the official report issued by a chamber of commerce).
3.2.3 Authentication of individual identity
Verification of individual identities, when required (according to certificate class), is done by one of the follow-
ing methods:
face-to-face; examination, by a CA operator, of an government-issued personal identity document,
when applicable;
by telephone: a CA operator contacts the Applicant (person) over the telephone, through the
Subscriber organization’s switchboard;
by digital signature: the certificate application form is digitally signed by a qualified electronic signature
(according to EU norms), so the signer’s identity can be extracted from his/her qualified certificate
(which must be valid at the time of verification by the CA).
The CA reserves the right to perform further verifications in order to validate individual identities.
3.3 Further verifications by the CA
In case of negative or uncertain results of the verification steps described below, if the applicant is not able or
willing to provide the necessary evidence to the CA, the certificate application is rejected. The CA reserves the
right to carry out further investigations and checks, in addition to those described below, in ways not prede-
termined.
3.3.1 For all classes of SSL Server certificates
For SSL Server certificates, the CA verifies that all FQDNs and IP address to be included in the certificate are
under the control of the Applicant organization, or his parent organization. These checks are carried out by dif-
ferent methods, depending on the case and the certificate class:
by means of WHOIS queries (+ reverse DNS lookups for IP addresses) to reliable DNS information
sources.
by querying the relevant DNS Registrars or governmental domain registration agencies, as appropriate;
by communicating with the domain administrator via e-mail, using an e-mail address obtainned by pre-
pending a “admin”, “administrator”, “webmaster”, “hostmaster”, or “postmaster” to the domain name
(this latter is obtained by pruning zero or more components from the requested FQDN).
Should one or more of those FQDNs and/or IP addresses be managed by an entity other than the Applicant or
their parent organization, the Applicant is required to provide evidence to the CA that they have been formally
delegated by the domains’ owner to manage those domains and/or IP addresses.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 15 of 49 09 December 2014
3.3.1.1 Internationalized Domain Names (IDN)
As of the date of revision of this CPS, Internationalized Domain Names (IDN) are not allowed: all FQDNs to be
inserted in the certificate must therefore be comprised of ASCII characters only.
3.3.2 For EV-class certificates
For private organizations, the CA also collects and evaluates the following information:
address of registered office
starting date of organization’s activity
business purpose (objects)
board members
proprietor(s) or shareholders
transfers of property or shares
powers and representatives
protests, insolvency or other negative facts
For government entities, the CA also collects and evaluates the following information:
address of main office
names and roles of top managers
In both cases, the CA verifies that the certificate application was authorized by a manager of the applicant with
adequate powers of attorney.
The CA also verifies that all the address components (country, stateOrProvince, locality, streetAddress) to be
included in the certificate match the address where the registered office of the applicant organization is actual-
ly located.
All the above checks are carried out by querying the relevant chamber of commerce database (for private or-
ganizations) or the appropriate governmental database (for governmental entities).
If the applicant organizations is found to have been in existence for less than 3 years, the CA checks that the
applicant organization possesses a bank account. To that purpose, the applicant organization must provide to
the CA a letter of bank reference, dated and signed by the bank, on headed paper.
If the CA finds problematic situations (e.g. bankruptcy proceedings, disputes, insolvency, etc.) regarding the
applicant organization or the person who authorized the certificate application, the procedure is suspended
and the case is brought to the attention of the Financial Officer and of the Head of Security of the CA, for fur-
ther evaluation.
3.4 Information not verified by the CA
The CA does not verify the electronic mail address indicated in the application form.
In general, the CA does not verify the correctness of any information received from the applicant which is not
intended to be used in security-sensitive fields of the certificate and is not necessary for the issuance and sub-
sequent management (suspension, re-activation, revocation) of the certificate.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 16 of 49 09 December 2014
3.5 I&A for renewal applications
The renewal process is similar to the first issuance process. It consists in the generation of a new pair of keys,
by the subscriber, to replace the expired pair and a request to the CA for a new certificate. The same identifica-
tion and authentication processes (I&A) as used for first issuance are also followed for the renewal.
3.6 I&A for requests to suspend or revoke
The methods for identification and authentication of the requests to suspend or revoke a certificate depend on
the channel which is used for the request:
in order to submit suspension or revocation requests through the CA portal, it is necessary to login to
the portal by means of a user-id and password (these credentials are sent to the subscriber via e-mail);
in the case of revocation requests sent to the CA on paper, the procedures described at §3.2.3 shall be
followed.
4 Certificate management operational requirements
4.1 Certificate application
The certificate application is done by filling out, signing and sending to the CA (e.g. via e-mail) a suitable appli-
cation form, to be found on the CA portal, together with the necessary annexes. An on-line equivalent of such
form is made available to Enterprise RAs.
The form must be signed by a legal representative (or other person with sufficient authority) of the requesting
organization.
The certificate application shall at least include the following information:
details of requesting organization
personal and contact details (e-mail, telephone) of applicant
personal and contact details (e-mail, telephone) of technical reference(s)
hostnames to be included in the certificate (for SSL Server certificates)
certificate Subject details proposed by applicant
The certificate application form incorporates by reference the Terms & Conditions of the CA service offered by
Actalis; therefore, by undersigning the certificate application form, the requestor also confirms his/her accep-
tance of the Terms & Conditions. Prior to signing the form, the requestor can evaluate every aspects of Actalis’
CA service by reading the documentation published on the web site http://www.actalis.it, in the section devot-
ed to SSL Server and Code Signing certificates.
The certificate application form must be accompanied or followed by a suitable Certificate Signing Request
(CSR), to be sent to the CA via email to the address provided in the application form.
The CSR is normally generated by the applicant organization by their own means (see also section 6.1.3), unless
assistance by Actalis has previously been requested.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 17 of 49 09 December 2014
It is also possible to apply for a “wildcard” SSL Server certificate (i.e., valid for all web sites belonging to a spe-
cific domain) or a multi-SAN SSL Server certificate (wherein two or more SAN values are present specifying sev-
eral hostnames and/or domain names for which the same certificate will be used). In such cases, the same I&A
procedures apply: the CA always checks that the requestor actually owns or controls the domains and/or IP ad-
dresses to be included in the certificate and that the requestor is an existing organization based on latest
chamber of commerce records or other applicable reliable source of information.
Wildcard and multi-SAN SSL Server certificates are subject to different fees than those for plain certificates (i.e.
single web site). For further information please contact Actalis’ sales department.
The maximum number of SAN values allowed in an SSL Server certificate is 100.
4.2 Application processing
The procedure for certificate issuance enforces a “dual control” requirement, in that it always requires
two different operators to be completed:
RA operator (RAO)
CA operator (CAO)
Upon receipt of a certificate application form, the RAO:
carries out all the verifications described in §0;
performs the additional verifications described in §3.3;
registers the applicant and the request details into the CA database;
verify that the identification data contained in the CSR are coherent with that supplied in the
application form;
sends to the requestor, via email, the authentication credentials needed to login to the CA portal, for
the possible submission of suspension, re-activation or revocation requests.
Registration of the applicant entails storing, into the CA database, of the identification and contact data (tele-
phone, e-mail) of the applicant organization and the person requesting the certificate (e.g. the legal repre-
sentative or another executive with power of signature), plus the details of the certificate request.
For performing the operations listed above, the RAO logs on to Actalis’ CA system by means of a strong (i.e.
two-factor) authentication.
4.3 Issue of certificates
If the verifications above are successful, the CAO:
verifies that the CSR matches the request data stored into the CA database;
checks that the CSR is well-coded and does not contain unexpected data;
checks the possession, by the requestor, of the private key matching the CSR (see §3.2.1);
The above verifications are done automatically, by Actalis’ CA system, on command of the CAO.
If all the above checks are successful, the CAO generates the certificate, stores it into the CA database, and
eventually sends to the subscriber via e-mail:
the subscriber certificate as an attachment;
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 18 of 49 09 December 2014
the certificate of issuing CA (that is, the Subordinate CA: see §1.3.1.2), or a URL to download it from
the CA portal;
possible ancillary information.
At this point, if the certificate has not already been paid for, the CA issues the invoice and sends it this to the
customer.
4.4 Certificate acceptance
The certificate is intended as accepted after 30 days from the date of delivery, as attested by the date of the
electronic mail message sent to the subscriber by the CA, if the absence of any notice to the contrary from the
subscriber.
Public use of the certificate (i.e. its installation on a website with public access, publication on a public websites
of executable code signed by that certificate), even if temporary, shall in any case imply acceptance of the cer-
tificate by the subscriber.
In the event that the certificate is issued with incorrect information in it due to incorrect completion of the ap-
plication form by the requestor, the certificate must nonetheless be paid for.
4.5 Use of key pair and certificate
The subscriber shall use the private key:
(Code Signing certificates) to digitally sign proprietary executable code (e.g. Java applets, dynamic
libraries, etc.) and/or code for which the same is responsible;
(SSL Server certificates) to activate the TLS/SSL protocol on its own web site, thereby allowing server
authentication and encryption of the transactions with web browsers.
The relying parties shall use the certificate:
(Code Signing certificates) to verify the integrity and origin of the executable code;
(SSL Server certificates) to verify the identity of a web site and the organization which manages the
site, as well as to exchange the “session key” with the web server in a safe manner.
See also paragraph 1.4.
4.6 Certificate renewal
The certificate has an expiry date beyond which it is no longer valid. The reason for which the certificate has a
limited duration is that the security of a pair of encryption keys could decrease over time or even be compro-
mised, due to the effect of cryptanalytic techniques and attacks by criminals. For these reasons Actalis does not
renew a certificate, unless the subscriber generates a new key pair. Apart from this, the renewal process is the
same as the first issue process.
4.7 Key re-generation
In the case when the subscriber decides to use a new key, the same shall request a corresponding new certifi-
cate.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 19 of 49 09 December 2014
4.8 Certificate modification
Since the certificate is signed by the issuing CA, it cannot be “modified”. Thus, to solve a possible certificate
generation problem, it is necessary to issue a new one (and revoke the incorrect one for obvious security rea-
sons).
In the case when the issued certificate contains incorrect information due to mistakes by the CA, the incorrect
certificate shall be revoked and a correct one will be promptly issued without additional costs for the client and
without asking the client for additional information.
In the case when the issued certificate contains incorrect information due to mistakes by the applicant (i.e. in-
correct filling-out of one or more fields of the application form), the incorrect certificate shall be revoked.
4.9 Certificate suspension and revocation
The suspension of the certificate determines a temporary suspension of the validity of a certificate, starting
from a given moment in time (date/time). Once a certificate has been suspended, it can be re-activated at any
time.
Revocation determines the premature termination of the validity of a certificate, starting from a given moment
in time (date/time). Revocation of a certificate is irreversible and not retroactive.
Implementation of the suspension or revocation consists in the generation and publication of a new CRL (Cer-
tificate Revocation List) which includes the serial number of the suspended or revoked certificate. The CRL is
accessible to anyone needing to verify the certificate status (refer to section 4.10).
Re-activation consists in the generation and publication of a new CRL in which the serial number of the previ-
ously suspended certificate does not appear.
4.9.1 Reasons for suspension
The conditions which could cause a suspension are as follows:
suspected compromise of private key;
temporary interruption of the use of the certificate by the client;
breaches of contract by the client (e.g. failure to pay).
4.9.2 Request for suspension
Suspension can be requested by the client and/or subscriber of the certificate or by the CA.
Under certain circumstances the subscriber shall be obliged to request suspension of the certificate (refer to
paragraph 9.5.3).
Suspension can be performed directly by the CA when the same becomes aware of conditions which could
compromise the reliability of the certificate or which constitute contractual non-fulfilments by the client.
4.9.3 Suspension procedure
Suspension can be requested by the subscriber on-line (refer to paragraph 4.9.6).
Following a period of 15 days after suspension the certificate will be re-activated automatically.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 20 of 49 09 December 2014
The certificate may also be re-activated by the user, at any moment in time, via the CA services web portal,
subject to authentication.
4.9.4 Certificate revocation
The conditions which may lead to a revocation are:
a court order;
the subscriber requests in writing that the CA revoke the certificate;
the subscriber notifies the CA that the original certificate request was not authorized and does not
retroactively grant authorization;
the CA obtains evidence that the subscriber’s private key (corresponding to the public key in the
certificate) has suffered a key compromise, or that the certificate has otherwise been misused;
the CA is made aware that the subscriber has violated one or more of its material obligations under the
Terms & Conditions of the service and/or this CPS;
the CA is made aware that use of a FQDN or IP address in the certificate is no longer legally permitted
(e.g. a court or arbitrator has revoked a domain name registrant’s right to use the domain name, the
domain name registrant has failed to renew the domain name, etc.);
the CA is made aware that a wildcard certificate has been used to authenticate a fraudulently
misleading subordinate FQDN;
the CA is made aware of a material change in the information contained in the certificate;
the CA is made aware that the certificate was not issued in accordance with this CPS;
the CA determines that any of the information appearing in the certificate is inaccurate or misleading;
the CA ceases operations for any reason and has not made arrangements for another CA to provide
revocation support for the certificate;
the CA’s right to issue certificates under CAB Forum’s Baseline Requirements [BR] expires or
is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP
repository;
the CA is made aware of a possible compromise of the private key of the subordinate CA used for
issuing the certificate;
the technical content or format of the certificate presents an unacceptable risk to application software
suppliers or relying parties (e.g. the CA/Browser Forum might determine that a deprecated
cryptographic/signature algorithm or key size presents an unacceptable risk and that such certificates
should be revoked and replaced by CAs within a given period of time);
the CA is made aware that the subscriber organization ceased its activity;
the CA is made aware that the certificate has an incorrect profile (e.g. incorrect values in some of the
certificate’s extensions, according to [BR] and/or [EVCG] depending on certificate type);
breach of contract by the client (e.g. failure to pay).
In all the above circumstances, the CA shall revoke the certificate within 24 hours.
Furthermore, if the CA is made aware that the certificate is being used by the owner for any kind of criminal
activity (e.g. "phishing" attacks, "man-in-the-middle" attacks, malware distribution, etc.), the CA shall immedi-
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 21 of 49 09 December 2014
ately revoke the certificate, without notice. Similarly, in the case where the CA discovers that the certificate
was wrongly issued with CA = TRUE in its KeyUsage extension.
4.9.5 Revocation request
Revocation can be requested by (depending on circumstances);
the subscriber (certificate owner);
the issuing Certificate Authority;
the court of law.
Furthermore, anybody may inform the CA of facts that may lead the CA, depending on circumstances, to decide
for revocation of the certificate.
Under certain circumstances the subscriber must request revocation of the certificate (see also §9.5.3).
4.9.6 Procedure for suspension or revocation
Requests for suspension or revocation may be submitted to the CA through the Actalis CA services web portal
(whose address is found on www.actalis.it). To access those functions it is necessary for the subscriber to login
to the portal using the credentials provided to them by the CA upon certificate issuance.
As an alternative, for revocation it is possible to fill out a request form on paper, signed by the subscriber or-
ganization’s representative. The signed form may then be delivered to the RA by hand or sent directly to the CA
via fax, ordinary mail, or electronic mail.
Regardless of whom requested the certificate suspension or revocation, the CA shall inform the subscriber
about the suspension or revocation via an e-mail message sent to the address of the “technical contact” indi-
cated in the application form.
Revocation requests submitted to the CA in paper form or via fax/email are processed within 24 hours in 90%
of cases, on working days only.
4.9.7 Frequency of issue of CRL
See paragraph 4.10.1.
4.10 Certificate status information
In general, the status of the certificates (active, suspended, revoked) is made available to all interested parties
through the publication of the Certificate Revocation List (CRL) in the format defined in the specification
[RFC5280].
For end-user certificates, an on-line certificate status checking service is also available, based on OCSP (On-line
Certificate Status Protocol) in compliance with the specification [RFC2560].
4.10.1 Operational characteristics
The CRL can be accessed in two different ways:
via LDAP protocol [RFC2251] on server ldap03.actalis.it
via HTTP protocol [RFC2616] on server crl03.actalis.it
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 22 of 49 09 December 2014
The LDAP and HTTP complete addresses of the CRL, listed below, are inserted in the CRLDistributionPoints ex-
tension of the certificate:
ldap://ldap03.actalis.it/cn=Actalis Authentication CA GN,o=Actalis
S.p.A./03358520967,c=IT?certificateRevocationList;binary
http://crl03.actalis.it/Repository/AUTH-GN/getLastCRL
…where N in GN stands for the SubCA generation number.
Note: for load balancing reasons, the directory service is distributed on several servers with different address-
es, thus the hostname included in a particular certificates maybe different from ldap03 or crl03 (for LDAP and
HTTP, respectively); it will, however, be a CNAME of this latter.
The CRL is re-generated and re-published:
at least every 6 hours, even in the absence of new suspensions or revocations;
following each new suspension or revocation.
The OCSP server address, following, is inserted in the AuthorityInformationAccess certificate extension:
http://ocsp03.actalis.it/VA/AUTH-GN
Note: for load balancing reasons, the OSCP service is distributed on several servers with different addresses,
thus the hostname included in a particular certificates maybe different from ocsp03; it will, however, be a
CNAME of this latter.
The CRL and OCSP services can be freely accessed by anyone.
The ARL, namely the list of revoked SubCA certificates, is re-generated and re-published:
at least every 3 months, even in the absence of new suspensions or revocations;
following each new suspension or revocation.
4.10.2 Service availability
Access to the CRL and OCSP service is continuously available (24 x 7), except for scheduled maintenance of the
servers or in the case of faults. See also §9.16.
4.11 Contract termination
The service contract stipulated between the CA and client is intended as terminated:
at the natural expiry date of the certificate, or…
at the date when the certificate has been revoked (refer to section 4.9).
4.12 Key escrow and recovery
The term “key escrow” is intended as the consignation of the CA key pair to a trusted third party (e.g. notary
public). Within the framework of the service provided by Actalis in accordance with this CPS, the escrowing of
the CA key is not contemplated.
However, key recovery of the CA key is provided, in the case of unintentional cancellation or fault in the HSM.
In order to allow key recovery, the CA keeps a backup CA key pair (refer to paragraph 6.8).
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 23 of 49 09 December 2014
4.13 Certificate problem reporting
Actalis makes available to all interested parties (Owners, Relying Parties, vendors of software such as web
browsers, law enforcement, etc.) two communication channels through which certificate problems can be re-
ported to the CA at any time (24x7).
the mailbox [email protected], which the CA commits to timely read during working hours only
(9 AM to 5 PM on Italian working days);
the telephone number +39-02-68825.576, at which Actalis commits to answer at all times (24x7x365).
Regardless of the communication channel used, the problem reporter must provide at least the following in-
formation, or the communication will be ignored:
his/her full name;
his/her phone number;
description of the alleged problem;
enough information to identify the certificate in question, such as:
– for an SSL Server certificate: either the address of the web site where the certificate is installed,
or the certificate hostname, starting validity date, and serial number;
– for a Code Signing certificate: commonName (CN), starting validity date, and serial number.
Such communications may be made in Italian or English; other languages are not handled.
The CA is committed to take charge of proper communications within 24 hours, start investigating the reported
problem, and take the necessary measures, depending on the problem severity. The priority assigned to the
problem will depend on:
the nature of the alleged problem;
the identity of the reporter (reports received by a Court or law enforcement agents will be handled
with higher priority than other messages);
the law and/or regulations relevant for the alleged problem (e.g. reports of illegal acts will be handled
with higher priority than other messages).
If the reported problem does exist, the CA will decide on a case by case basis the measures to be taken (e.g.
revocation of the certificate) and will notify the reporter by e-mail.
Note: those who send unwanted messages (spam) will be prosecuted according to applicable laws.
5 Physical and operational security controls
The technological infrastructure, operating procedures, physical and logical security controls and personnel re-
sponsible for providing the service described in this CPS are the same as those used within the Actalis service
for issuing qualified certificates (according to EU directive on electronic signatures).
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 24 of 49 09 December 2014
5.1 Physical security
All computer systems used for the provision of the certification services herein described, with the exception of
the server containing the evidence of registration (see below), are housed in the Actalis data center Actalis lo-
cated in Arezzo, Via Gobetti 96.
For the management of its CA infrastructure, Actalis makes use of the data center services provided by its hold-
ing company, Aruba S.p.A., who takes responsibility for the housing, Internet connectivity, and physical security
of all Actalis’ systems. In particular, Aruba is committed to guarantee the following to Actalis:
a physical access control system, so that access to the building is only possible for those who need,
after checking in at the reception, and access to data rooms is only possible for authorized personnel
holding a suitable badge and the corresponding PIN;
passive and active intrusion detection systems, such as grids, bullet-proof windows, security doors,
motorized gates, TVCC and VMD;
a fire protection system, compliant with applicable laws and technical standards, including smoke and
fire detectors placed all over the building;
a power supply system fully redundant at all levels (transformers, power centers, generators, UPS’s,
distribution panels, etc.) so that electrical power supply is guaranteed under all foreseeable conditions;
a ventilation and air conditioning system (HVAC) which guarantees optimal climatic conditions for the
smooth operation of all servers housed in the data center;
a Network Operation Center (NOC), manned h24 for 365 days/year by qualified personnel, ensuring
constant monitoring of infrastructure and services and timely intervention in case of need;
redundant Internet connectivity, with a capacity of at least twice the minimum necessary;
ISO 27001 certification of the service provided.
At the Actalis offices of Milan, Via dell'Aprica 18, there is a server on which all the evidence related to the issu-
ance of certificate subscribers, as well as the certificates themselves and off-line revocation requests, are
stored in electronic form.
5.2 Procedural controls
Actalis maintains a Security Plan which analyses the assets, the threats they are exposed to, and describes the
technical and organizational controls in place, aimed at assuring an adequate level of security for the opera-
tions. The risk assessment is reviewed at least yearly.
Actalis’ operational procedures are documented under the company’s Quality Management System, certified in
accordance with the ISO 9001 standard.
5.3 Personnel controls
Personnel involved in the service have at least 5 years of working experience in the definition, development
and management of PKI services and have been adequately trained on the procedures and tools to be used
during the various operational phases.
5.4 Event logging
The main events relevant to the certificate lifecycle operations, including the requests for certification, suspen-
sion or revocation etc., are registered on paper or in electronic form. Furthermore, events like the following
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 25 of 49 09 December 2014
are also recorded: logical access to the certificate management system, operations carried out by Actalis per-
sonnel, presence of visitors at areas where certification activities are performed etc.
For each event, information is logged about the type, date and time of occurrence and, if available, other in-
formation useful to identify those involved in the event and the outcome of the operations.
All that information constitutes the audit log. The files that the audit log is comprised of are periodically trans-
ferred to permanent archive media.
The CA keeps the audit log for at least 7 years.
5.5 Data retention and archival
The CA keeps the following information related to the certificate issuing and management processes:
certificates issuing requests
documentation supplied by applicants
CSR (Certificate Signing Request) supplied by applicants
personal details of the applicants and subscribers (when the two are different)
results of verifications performed by the CA (e.g. chamber of commerce enquiries, WHOIS records,
etc.)
suspension and revocation requests
all certificates issued
All the above data are retained for at least 7 years past the certificates’ expiration dates.
5.6 Renewal of CA key
5.6.1 Root CA
No stipulation.
5.6.2 Sub CA
At least 3 years before the end of the validity of the current certification key (Sub CA key), a new Sub CA key
pair will be generated and distributed to end users with the methods described in section 6.2.1. From that
moment on, end user certificates and related CRLs shall be signed with the new Sub CA key.
5.7 Backup copy
A backup copy of data, applications, and any other file necessary for a complete recovery of the service is per-
formed on a daily basis.
5.8 Compromise and disaster recovery
The term “disaster” is referred to a damaging event, the consequences of which determine the unavailability of
the service under normal conditions, such as the failure or unavailability or the facilities (e.g. computer sys-
tems, HSMs, wiring, data rooms, power supply, etc.) that are necessary for providing the certification services.
Following a disaster, special procedures shall be applied for the recovery of the certification services. Those
procedures are documented in Actalis’ security plan, viewable at Actalis’ head office on subscriber request.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 26 of 49 09 December 2014
In the event that one of the algorithms (or their parameters) used for issuing and using certificates gets com-
promised, the CA shall:
inform all subscribers of certificates issued under this CPS, and all relying parties with which the CA has
made arrangements in this regard;
promptly publish on its web site a prominent warning notice;
revoke all certificates that became unreliable because of the event;
suspend the CA service (it will be resumed after having solved the problem, if possible, by changing the
compromised algorithms, or their parameters, and possibly generating a new SubCA and/or RootCA
key).
The CA shall proceed in a similar manner in the event of a CA key compromise, e.g. in case of loss of confidenti-
ality (undue disclosure to unauthorized third parties) of one of the CA private keys used for issuing certificates
under this CPS. If that is the consequence of a security incident, the relevant handling procedure will be started
and all interested parties will be informed.
5.9 Cessation of the CA
In the event that the CA intends to cease the provision of service under this CPS, the CA will do what is neces-
sary to minimize disruption to the certificate holders and relying parties; in particular the CA shall:
at least 30 days before such termination, inform of its intentions all certificate holders and all entities
with which the CA has agreements in this regard;
with the same notice, publish a prominent notice on its website;
terminate all contracts with any subcontractor;
before the effective date of termination, transfer to another organization the obligation to keep the
registration information, certificate status information and all the relevant logs for the due time;
at the date of termination, destroy its private CA keys or render them unusable.
6 Technical security controls
The technological infrastructure, operating procedures, physical and logical security controls and personnel re-
sponsible for providing the service described in this CPS are the same as those used for the Actalis service for
issuing qualified certificates (according to the EU directive on electronic signatures).
6.1 Key generation
6.1.1 Root CA
Generation of the Root CA key pair takes place in a physically secured environment, according to the Root CA
internal procedures that require the joint intervention of two different people (“dual control”). Execution of
the key generation procedure (or “key ceremony”) is recorded by Actalis’ internal auditor.
The key pair used by the Root CA is generated inside a high quality HSM (Hardware Security Module) with secu-
rity certification in accordance with FIPS PUB 140-2 Level 3 and Common Criteria (ISO 15408) at EAL 4 or high-
er.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 27 of 49 09 December 2014
6.1.2 Sub CA
Generation of the Sub CA key pair takes place in a physically secured environment, according to the Sub CA in-
ternal procedures that require the joint intervention of two different people (“dual control”). Execution of the
key generation procedure (or “key ceremony”) is recorded by Actalis’ internal auditor.
The key pair used by the CA to sign the certificates and CRLs is generated inside a high quality HSM (Hardware
Security Module), with a security certification in accordance with FIPS PUB 140-2 Level 3 and Common Criteria
(ISO 15408) at EAL 4 or higher.
6.1.3 Subscribers
The applicant normally generates its own key pairs by his/her own means.
6.2 Distribution of public key
6.2.1 Root CA
As a minimum, the Root CA public key is distributed in the following ways:
by means of publication on the CA directory server (ldap://ldap.actalis.it)
by means of publication on the CA web site (www.actalis.it)
Depending on the agreements between Actalis and certain browser and/or operating system makers, the Root
CA public key may also be distributed in bundle with, or as an update of, such software products.
6.2.2 Sub CA
The Sub CA public key is provided to customers and in the form of an X.509 certificate signed by the Root CA,
together with the end user certificate.
Actalis may also distribuite the Sub CA public key by other means, if convenient.
6.2.3 Subscribers
The public key of the certificate requestor is supplied to the CA in the form of a Certificate Signing Request
(CSR) in compliance with PKCS#10 [RFC2314].
6.3 Key size
As for cryptographic algorithms, minimum length of keys, key parameters and hashing functions, the CA con-
forms to ETSI TS 102 176-1 and to Appendix A of [EVCG], with precedence of the latter in case of conflict be-
tween the two sets of requirements.
6.3.1 Root CA
The Root CA shall use a key with a module size of 4096 bit.
6.3.2 Sub CA
The Sub CA shall use a key with a module size of at least 2048 bit.
6.3.3 Subscribers
The module of subscriber keys shall have a size of 2048 bit.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 28 of 49 09 December 2014
6.4 Parameters generation and key quality
6.4.1 Root CA
The Root CA uses a cryptographic key pair generated with the RSA algorithm, with a public exponent equal to
65537 (Hex 0x10001).
6.4.2 Sub CA
The Sub CA uses a cryptographic key pair generated with the RSA algorithm, with a public exponent equal to
65537 (Hex 0x10001).
6.4.3 Subscribers
Normally, the certificate subscriber uses a cryptographic key pair generated with the RSA algorithm.
The CA does not undertake to certify user keys generated with other algorithms (e.g. DSA, ECDSA).
6.5 Key usage (X.509v3 extension)
6.5.1 Root CA
The Sub CA certificate includes KeyUsage extension with the appropriate values which indicate the purpose of
the private key:
keyCertSign (sign certificates)
cRLSign (sign CRLs)
For further details see chapter 7.
6.5.2 Sub CA
The Sub CA certificate includes KeyUsage extension with the appropriate values which indicate the purpose of
the private key:
keyCertSign (sign certificates)
cRLSign (sign CRLs)
For further details see chapter 7.
6.5.3 Subscribers
See chapter 7.
6.6 Protection of private key
6.6.1 Root CA
The private key used by the Root CA is kept inside a high quality HSM (Hardware Security Module), with a secu-
rity certification in accordance with Common Criteria (ISO 15408) at EAL 4 or higher.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 29 of 49 09 December 2014
6.6.2 Sub CA
The private key used by the Sub CA is kept inside a high quality HSM (Hardware Security Module), with a securi-
ty certification in accordance with FIPS PUB 140-2 Level 3 or Common Criteria (ISO 15408) at EAL 4 or higher.
6.6.3 Subscribers
The CA does not mandate, but recommends, use of a hardware device (e.g. HSM) for protecting the subscrib-
er’s private key, provided that the solution adopted be reasonably effective in protecting its confidentiality. The
CA may refuse to issue the certificate if the system used by the requestor for protect its private is regarded as
inadequate by the CA.
6.7 Security Standard for cryptograph modules
The HSMs (Hardware Security Modules) used by the Root CA and the Sub CA shall possess a security certifica-
tion according to FIPS PUB 140-2 Level 3 and Common Criteria (ISO 15408) at EAL 4 or higher as detailed in pre-
vious sections.
6.8 Private Key (n out of m) Multi-Person Control
6.8.1 Root CA
The Root CA private key shall be under “N out of M” multi-person control. See also section 6.10.1.
6.8.2 Sub CA
No stipulation.
6.8.3 Subscribers
No stipulation.
6.9 Backup and recovery of private key
6.9.1 Root CA
For the purpose of guaranteeing continuity of service, the Root CA keeps an encrypted backup copy of its keys
on removable media. The backup copy is kept in a safe place which is different than the location of the opera-
tional copy (inside the HSM). Backup and restore procedures require the joint intervention of at least two peo-
ple (“dual control”).
6.9.2 Sub CA
For the purpose of guaranteeing continuity of service, the Sub CA keeps an encrypted backup copy of its keys
on removable media. The backup copy is kept in a safe place which is different than the location of the opera-
tional copy (inside the HSM). Backup and restore procedures require the joint intervention of at least two peo-
ple (“dual control”).
6.9.3 Subscribers
If technically feasible, the Subscriber is allowed to keep a backup copy of its private key for recovery purposes.
The confidentiality of the backup copy must be ensured by means not less effective than those used to protect
the operational copy.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 30 of 49 09 December 2014
6.10 Key activation data
6.10.1 Root CA
The Root CA key is normally kept in a non-operational state, except when needed for issuing or revoking Sub
CA certificates, by deactivating the HSM partition containing it.
Activation of the HSM partition requires the use of a dedicated PIN entry device (“PED”) connected directly to
the HSM and a set of USB-based two-factor authentication tokens each protected by a PIN. In particular, the
activation of the HSM partition containing the Root CA key requires inserting into the PED the Security Officer’s
token plus 3 other tokens out of 5 (“green tokens”), according to a secure secret sharing scheme. The 5 green
tokens are assigned to as many individuals within the company, in writing, who commit to keep them safely.
Therefore, the activation of the Root CA key requires the concurrent presence of at least 3 persons out of 5,
plus the Security Officer.
The Root CA Security Manager maintains a list of personnel that have been assigned the 5 green tokens. The
list will be made available for inspection during compliance audits.
6.10.2 Sub CA
The activation PIN (or other equivalent or better activation data) for the HSM used by the Sub CA is only known
by the personnel in charge of the CA operations on a “need to know” basis, under the responsibility of the CA
operations manager (or other suitable role).
6.10.3 Subscribers
The subscriber must ensure that the PIN or password needed to activate their private key is known to the cer-
tificate owner only, or to a delegated of them.
6.11 Computer security requirements and controls
The operating systems used by the CA for management of the certificates have been certified according to
Common Criteria at EAL2 or higher. The operating systems are configured so that the user is always required to
identify him/herself by means of a username and password or, in the case of more critical systems, via the use
of a smartcard and corresponding PIN. The access events are logged as described in section 5.4. The operating
systems are also subject to periodic hardening in order to disable non-necessary services and functionalities.
Certificate issuance and management is supported by a Certificate Management System (CMS) software. Web
interfaces (“WebRA/WebCA”), protected by TLS/SSL secure channel, are also implemented for performing rou-
tine certificate management operations by suitably authorized personnel. Multi-factor authentication is re-
quired for all CMS and WebRA/WebCA accounts capable of directly causing certificate issuance.
For performing most of the operations listed above the RA operator uses a specific type of account on the Cer-
tificate Management System. Such type of account requires strong two-factor authentication for logon. All se-
curity-relevant operations – e.g. authorization of certificate issuance – require the RA operator’s digital signa-
ture (smartcard-based) and are traced to the audit log.
6.12 Network security requirements and controls
Access to the CA on-line hosts is protected by high quality firewalls which guarantee an adequate filtering of
the incoming connections and also implement intrusion detection functionalities. Before the firewalls, a series
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 31 of 49 09 December 2014
of routers which implement suitable ACLs (Access Control List) constitute further protection. All the communi-
cation ports of the certification servers which are not used are disabled. Only those ports are active which sup-
port the protocols and functions required for the operation and functionality of the service.
In order to strengthen the filter against communications the entire certification system is split-up into an ex-
ternal zone, internal zone and a De-Militarized Zone (DMZ). Sensitive systems are deployed on the internal
zone and cannot be directly accessed from the external zone.
Actalis carries out an annual security assessment to verify the presence of any network vulnerabilities by in-
volving independent experts.
6.13 Clock synchronisation
All the computer systems used by the CA are synchronised with a time server which in turn is synchronized
from an external GPS satellite network.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 32 of 49 09 December 2014
7 Certificate and CRL profiles
7.1 Certificate profile
The certificates conforms to the ISO/IEC 9594-8:2005 [X.509] standard and to the [RFC 5280] public specifica-
tion.
As for cryptographic algorithms, minimum length of keys, key parameters and hashing functions, the CA con-
forms to ETSI TS 102 176-1 and to Appendix A of [EVCG], with precedence of the latter in case of conflict be-
tween the two sets of requirements.
7.1.1 Root CA
The profile of the Root CA certificate is as follows:
Field Value
Version V3 (2)
SerialNumber (hex) 57:0A:11:97:42:C4:E3:CC
Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)
Issuer
CN = Actalis Authentication Root CA
O = Actalis S.p.A./03358520967
L = Milano
C = IT
Validity from September 22, 2011 to September 22, 2030
Subject
CN = Actalis Authentication Root CA
O = Actalis S.p.A./03358520967
L = Milano
C = IT
SubjectPublicKeyInfo <RSA public key of 4096 bits>
SignatureValue <Root CA signature>
Extension Value
Basic Constraints critical: CA=true
AuthorityKeyIdentifier (AKI) <included, KeyID>
SubjectKeyIdentifier (SKI) 52:D8:88:3A:C8:9F:78:66:ED:89:F3:7B:38:70:94:C9:02:02:36:D0
KeyUsage critical: keyCertSign, cRLSign
ExtendedKeyUsage (EKU) <not included>
CertificatePolicies <not included>
SubjectAlternativeName (SAN) <not included>
AuthorityInformationAccess (AIA) <not included>
CRLDistributionPoints (CDP) <not included>
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 33 of 49 09 December 2014
7.1.2 Sub CA
The profile of the Sub CA certificate is as follows:
Field Value
Version V3 (2)
SerialNumber < includes at least 8 pseudo-random bytes>
Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)
Issuer
CN = Actalis Authentication Root CA
O = Actalis S.p.A./03358520967
L = Milano
C = IT
Validity <10 years>
Subject
CN = Actalis Authentication CA GN
O = Actalis S.p.A./03358520967
L = Milano
C = IT
SubjectPublicKeyInfo <RSA public key of 2048 bits>
SignatureValue <Root CA signature>
Extension Value
Basic Constraints critical: CA=true
AuthorityKeyIdentifier (AKI) <Same value as the Root CA SKI extension>
SubjectKeyIdentifier (SKI) <public key SHA1-digest>
KeyUsage critical: keyCertSign, cRLSign
ExtendedKeyUsage (EKU) <not included>
CertificatePolicies PolicyOID = 2.5.29.32.0 (anyPolicy) CPS-URI = <HTTP address of this CPS>
SubjectAlternativeName (SAN) <not included>
AuthorityInformationAccess (AIA) <HTTP address of OCSP responder>
CRLDistributionPoints (CDP) <HTTP address to access the ARL> <LDAP address to access the ARL>
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 34 of 49 09 December 2014
7.1.3 SSL Server EV (Extended Validation)
The SSL Server EV certificate is issued with the following profile:
Field Value
Version V3 (2)
SerialNumber <8 random bytes>
Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)
Issuer <DN of issuing CA>
Validity <12 or 24 months depending on request>
Subject
C = <ISO 3166 two-letter code of country where the subscriber organization is based>
ST = <state or province where organization is based> L = <organization’s head office locality> O = <full legal name of subscriber organization> OU = <optional> CN = <one of the IP addresses or FQDNs contained in the SAN extension>
serialNumber = <VAT number of subscriber organization or
equivalent> businessCategory = <organization type, according to [EVCG]>
SubjectPublicKeyInfo <RSA public of 2048 bits>
SignatureValue <Sub CA signature>
Extension Value
Basic Constraints <absent>
AuthorityKeyIdentifier (AKI) <Same value as the Sub CA SKI extension>
SubjectKeyIdentifier (SKI) <public key SHA1-digest>
KeyUsage critical: 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 CPS-URI = <HTTP address of this CPS>
SubjectAlternativeName (SAN) <one or more IP addresses and/or hostnames>
AuthorityInformationAccess (AIA) <HTTP address of OCSP responder>
CRLDistributionPoints (CDP) <HTTP address to access the CRL> <LDAP address to access the CRL>
The CA reserves the right to include in the certificate further information, in compliance with [RFC 5280], [BR]
and [EVCG], while ensuring the functionality of the certificate for its intended use.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 35 of 49 09 December 2014
7.1.4 Code Signing EV (Extended Validation)
The Code Signing EV certificate is issued with the following profile:
Field Value
Version V3 (2)
SerialNumber <8 random bytes>
Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)
Issuer <DN of issuing CA>
Validity <12, 24 or 36 months depending on request>
Subject
C = <ISO 3166 two-letter code of country where subscriber organization is based>
ST = <state or province where organization is based> L = <organization’s head office locality> O = <full legal name of subscriber organization> OU = <optional> CN = <value proposed by subscriber>
serialNumber = <VAT no. of subscriber organization or equivalent> businessCategory = <organization type, according to [EVCG]>
SubjectPublicKeyInfo < RSA public key of 2048 bits>
SignatureValue <Sub CA signature>
Extension Value
Basic Constraints <absent>
AuthorityKeyIdentifier (AKI) <Same value as the Sub CA SKI extension>
SubjectKeyIdentifier (SKI) <public key SHA1-digest>
KeyUsage critical: digitalSignature
ExtendedKeyUsage (EKU) critical: codeSigning (1.3.6.1.5.5.7.3.3)
CertificatePolicies PolicyOID = 1.3.159.1.18.1 CPS-URI = <HTTP address of this CPS>
SubjectAlternativeName (SAN) <optional>
AuthorityInformationAccess (AIA) <HTTP address of OCSP responder>
CRLDistributionPoints (CDP) <HTTP address to access the CRL> <LDAP address to access the CRL>
The CA reserves the right to include in the certificate further information, in compliance with [RFC 5280], [BR]
and [EVCG], while ensuring the functionality of the certificate for its intended use.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 36 of 49 09 December 2014
7.1.5 SSL Server OV (Organization Validated)
The SSL Server OV certificate is issued with the following profile:
Field Value
Version V3 (2)
SerialNumber <8 random bytes>
Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)
Issuer <DN of issuing CA>
Validity <12 or 24 or 36 months depending on request>
Subject
C = <ISO 3166 two-letter code of country where the subscriber organization is based>
ST = <state or province where organization is based> L = <organization’s head office locality> O = <full legal name of subscriber organization> OU = <optional> CN = <one of the IP addresses or FQDNs contained in the SAN extension>
SubjectPublicKeyInfo <RSA public of 2048 bits>
SignatureValue <Sub CA signature>
Extension Value
Basic Constraints <absent>
AuthorityKeyIdentifier (AKI) <Same value as the Sub CA SKI extension>
SubjectKeyIdentifier (SKI) <public key SHA1-digest>
KeyUsage critical: digitalSignature, keyEncipherment
ExtendedKeyUsage (EKU) serverAuth (1.3.6.1.5.5.7.3.1), clientAuth (1.3.6.1.5.5.7.3.2)
CertificatePolicies PolicyOID = 1.3.159.1.20.1 CPS-URI = <HTTP address of this CPS>
SubjectAlternativeName (SAN) <one or more IP addresses and/or hostnames>
AuthorityInformationAccess (AIA) <HTTP address of OCSP responder>
CRLDistributionPoints (CDP) <HTTP address to access the CRL> <LDAP address to access the CRL>
The CA reserves the right to include in the certificate further information, in compliance with [RFC 5280] and
[BR], while ensuring the functionality of the certificate for its intended use.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 37 of 49 09 December 2014
7.1.6 SSL Server Wildcard OV (Organization Validated)
The Wildcard SSL Server OV certificate is issued with the following profile:
Field Value
Version V3 (2)
SerialNumber <8 random bytes>
Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)
Issuer <DN of issuing CA>
Validity <12, 24 or 36 months depending on request>
Subject
CN = <ISO 3166 two-letter code of country where subscriber organization is based>
ST = <state or province where organization is based> L = <organization’s head office locality> O = <full legal name of subscriber organization> OU = <optional> CN = <Wildcard FQDN, also contained in the SAN extension>
SubjectPublicKeyInfo <RSA public key of 2048 bits>
SignatureValue <Sub CA signature>
Extension Value
Basic Constraints <if included, is critical and contains CA=FALSE>
AuthorityKeyIdentifier (AKI) <Same value as the Sub CA SKI extension>
SubjectKeyIdentifier (SKI) <public key SHA1-digest>
KeyUsage critical: digitalSignature, keyEncipherment
ExtendedKeyUsage (EKU) serverAuth (1.3.6.1.5.5.7.3.1), clientAuth (1.3.6.1.5.5.7.3.2)
CertificatePolicies PolicyOID = 1.3.159.1.19.1 CPS-URI = <HTTP address of this CPS>
SubjectAlternativeName (SAN) <Same wildcard FQDN as in the Subject.CN field>
AuthorityInformationAccess (AIA) <HTTP address of OCSP responder>
CRLDistributionPoints (CDP) <HTTP address to access the CRL> <LDAP address to access the CRL>
The CA reserves the right to include in the certificate further information, in compliance with [RFC 5280] and
[BR], while ensuring the functionality of the certificate for its intended use.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 38 of 49 09 December 2014
7.1.7 Code Signing OV (Organization Validated)
The Code Signing OV certificate is issued with the following profile:
Field Value
Version V3 (2)
SerialNumber <8 random bytes>
Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)
Issuer <DN of issuing CA>
Validity <12, 24 or 36 months depending on request>
Subject
C = <ISO 3166 two-letter code of country where subscriber organization is based>
ST = <state or province where organization is based> L = <organization’s head office locality> O = <full legal name of subscriber organization> OU = <optional> CN = <value proposed by subscriber>
SubjectPublicKeyInfo < RSA public key of 2048 bits>
SignatureValue <Sub CA signature>
Extension Value
Basic Constraints <absent>
AuthorityKeyIdentifier (AKI) <Same value as the Sub CA SKI extension>
SubjectKeyIdentifier (SKI) <public key SHA1-digest>
KeyUsage critical: digitalSignature
ExtendedKeyUsage (EKU) critical: codeSigning (1.3.6.1.5.5.7.3.3)
CertificatePolicies PolicyOID = 1.3.159.1.21.1 CPS-URI = <HTTP address of this CPS>
SubjectAlternativeName (SAN) <optional>
AuthorityInformationAccess (AIA) <HTTP address of OCSP responder>
CRLDistributionPoints (CDP) <HTTP address to access the CRL> <LDAP address to access the CRL>
The CA reserves the right to include in the certificate further information, in compliance with [RFC 5280] and
[BR], while ensuring the functionality of the certificate for its intended use.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 39 of 49 09 December 2014
7.1.8 SSL Server DV (Domain Validated)
The SSL Server DV certificate is issued with the following profile:
Field Value
Version V3 (2)
SerialNumber <8 random bytes>
Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)
Issuer <DN of issuing CA>
Validity <12 or 24 or 36 months depending on request>
Subject OU = “Domain Control Validated by Actalis S.p.A.” CN = <one of the IP addresses or FQDNs contained in the SAN extension>
SubjectPublicKeyInfo <RSA public of 2048 bits>
SignatureValue <Sub CA signature>
Extension Value
Basic Constraints <absent>
AuthorityKeyIdentifier (AKI) <Same value as the Sub CA SKI extension>
SubjectKeyIdentifier (SKI) <public key SHA1-digest>
KeyUsage critical: digitalSignature, keyEncipherment
ExtendedKeyUsage (EKU) serverAuth (1.3.6.1.5.5.7.3.1), clientAuth (1.3.6.1.5.5.7.3.2)
CertificatePolicies PolicyOID = 1.3.159.1.22.1 CPS-URI = <HTTP address of this CPS>
SubjectAlternativeName (SAN) <one or more IP addresses and/or hostnames>
AuthorityInformationAccess (AIA) <HTTP address of OCSP responder>
CRLDistributionPoints (CDP) <HTTP address to access the CRL> <LDAP address to access the CRL>
The CA reserves the right to include in the certificate further information, in compliance with [RFC 5280] and
[BR], while ensuring the functionality of the certificate for its intended use.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 40 of 49 09 December 2014
7.1.9 SSL Server Wildcard DV (Domain Validated)
The Wildcard SSL Server OV certificate is issued with the following profile:
Field Value
Version V3 (2)
SerialNumber <8 random bytes>
Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)
Issuer <DN of issuing CA>
Validity <12, 24 or 36 months depending on request>
Subject OU = “Domain Control Validated by Actalis S.p.A.” CN = <Wildcard FQDN, also contained in the SAN extension>
SubjectPublicKeyInfo <RSA public key of 2048 bits>
SignatureValue <Sub CA signature>
Extension Value
Basic Constraints <if included, is critical and contains CA=FALSE>
AuthorityKeyIdentifier (AKI) <Same value as the Sub CA SKI extension>
SubjectKeyIdentifier (SKI) <public key SHA1-digest>
KeyUsage critical: digitalSignature, keyEncipherment
ExtendedKeyUsage (EKU) serverAuth (1.3.6.1.5.5.7.3.1), clientAuth (1.3.6.1.5.5.7.3.2)
CertificatePolicies PolicyOID = 1.3.159.1.23.1 CPS-URI = <HTTP address of this CPS>
SubjectAlternativeName (SAN) <Same wildcard FQDN as in the Subject.CN field>
AuthorityInformationAccess (AIA) <HTTP address of OCSP responder>
CRLDistributionPoints (CDP) <HTTP address to access the CRL> <LDAP address to access the CRL>
The CA reserves the right to include in the certificate further information, in compliance with [RFC 5280] and
[BR], while ensuring the functionality of the certificate for its intended use.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 41 of 49 09 December 2014
7.2 CRL profile
The CRLs are compliant with the with the ISO/IEC 9594-8:2005 [X.509] International Standard and public speci-
fication [RFC 5280].
Besides the mandatory information, the CRLs also contain:
nextUpdate (date for next issue of CRL)
cRLNumber (sequential number of CRL)
The CRL is signed using the hashing algorithm sha256WithRSAEncryption (1.2.840.113549.1.1.11).
Moreover, in correspondence with each item of the CRL there is a reasonCode extension to indicate the rea-
sons for suspension or revocation.
8 Compliance audits and other assessments
The technological infrastructure, physical and logical security controls, several operating procedures, and the
personnel employed in providing the CA service described in this CPS are the same as those used for issuing
qualified certificates according to the EU directive on electronic signatures.
Actalis is a Qualified Certification Service Provider (CSP) according to European legislation; as such, it is subject
to a periodic conformity assessment (“supervision”) by AgID1 and is required to perform periodic internal
audits.
8.1 Frequency or circumstances of assessment
The external audits performed by AgID are carried out with the periodicity (18 months) required by the CNIPA
Circular n.52 of 2007. Regardless of that, Actalis commits to do what is necessary so that a compliance audit be
done at least every 12 months, if necessary by engaging an external independent auditing firm so to enforce
the annual periodicity.
The internal audits are carried out in accordance with a schedule which provides different periods (from quar-
terly to annual) for the various technical-operational aspects of the CA service.
8.1.1 Root CA
A compliance audit on the Root CA is performed at least annually by an external, independent and suitably
qualified auditor on the basis of auditing criteria ETSI TS 102 042 [REQPOL].
8.1.2 Sub CA
A compliance audit on the Sub CA is performed at least annually by an external, independent and suitably qual-
ified auditor on the basis of auditing criteria ETSI TS 102 042 [REQPOL].
8.1.3 Registration Authorities
Inspections on Registration Authorities (if any exist) are performed at least annually by the Sub CA.
1 Agenzia per l’Italia Digitale: see www.digitpa.gov.it
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 42 of 49 09 December 2014
8.2 Identity and qualification of assessor
The internal audits are carried out by Actalis’ internal auditor, who is suitably qualified for the task.
External audits, are performed by independent and suitably qualified auditors.
8.3 Assessor’s relationship to assessed entity
No relationship shall exist between the CA and any external auditors that can influence the outcome of the au-
dits in favor of Actalis.
Actalis’ internal auditor does not belong to the organizational unit in charge of CA operations.
8.4 Topics covered by assessment
Audits performed by external assessors (other than AgID) are aimed at verifying compliance of Actalis’ CA ser-
vice to this CPS based on ETSI TS 102 042 auditing criteria [REQPOL].
The main objective of the internal audit is to verify the respect of Actalis’ internal operating procedures and
their compliance with this CPS.
8.5 Actions taken as a result of deficiency
In the case of non-compliances, AgID will require the CA to adopt the necessary corrective measures within a
certain period of time, under penalty of suspension or revocation of the accreditation.
Non-compliances found by other external auditors are brought to the attention of Actalis’ top management
who decides how to handle them on a case-by-case basis.
8.6 Communication of results
The results of the audit carried out by AgID are communicated to the CA by a special audit report.
The results of internal audits are presented directly to Actalis' top management, and shared with the other in-
ternal stakeholders, via an audit report.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 43 of 49 09 December 2014
9 Other business and legal matters
The general Terms & Conditions of the CA service herein described are provided to customers as a separate
document, to be accepted at application time, published on the CA web site (see §2.2).
In the case of a discrepancy between this CPS and the separate “Terms & Conditions” document, this CPS will
take precedence.
9.1 Service fees
The maximum service fees are published on the CA web site: www.actalis.it.
Different conditions may be negotiated case by case, in accordance with the volumes requested.
Service fees are subjected to change without prior notification.
9.2 Financial responsibility
Actalis maintains the following insurance related to its performance and obligations under this CPS:
A. Commercial General Liability insurance with policy limits of at least two million US dollars in coverage;
and
B. Professional Liability/Errors and Omissions insurance, with policy limits of at least five million US dol-
lars in coverage, and including coverage for (i) claims for damages arising out of an act, error, or omis-
sion, unintentional breach of contract, or neglect in issuing or maintaining EV and non-EV Certificates,
and (ii) claims for damages arising out of infringement of the proprietary rights of any third party (ex-
cluding copyright, and trademark infringement), and invasion of privacy and advertising injury.
Such insurance is with a company rated no less than A- as to Policy Holder’s Rating in the current edition of
Best’s Insurance Guide.
9.3 Privacy of personal information
Actalis is the processor of the personal information collected during the identification and registration phase of
parties requesting certificates under this CPS, and shall process such information ensuring their confidentiality
and in compliance with the Italian Legislative Decree n.196/2003 [DLGS196].
9.3.1 Information pursuant to Legislative Decree n.196/2003
Actalis, processor of the personal data provided by the subscriber, hereby informs the subscriber that, pursuant
to the Italian Legislative Decree 196/2003 [DLGS196], such personal data shall be processed by means of both
paper archives and information systems that guarantee their security and confidentiality in keeping with the
aforesaid Decree.
The information supplied by the applicant falls into two categories: mandatory and optional. The mandatory
information is necessary for delivering the requested service; failure by the subscriber to provide that infor-
mation will not allow the contract to be concluded. The optional information is used to assist in the service;
failure by the subscriber to provide this information will not prevent the contract to be concluded.
The information provided by the applicant is processed exclusively for the purpose of issuing and managing the
certificates, and can be communicated to companies providing consultancy and technical support to the CA. In
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 44 of 49 09 December 2014
relation to this data processing, the applicant shall be granted the rights provided for in aforesaid Decree
[DLGS196].
9.3.2 Archives containing personal information
The archives containing personal data are:
CA database (comprised of multiple logically distinct databases)
paper archives (kept in secure storage with access restrictions)
The aforementioned archives are managed by the CA operations manager and are suitably protected against
unauthorized access.
9.3.3 Privacy protection measures
Actalis complies with the provisions of the Italian Legislative Decree n.196/2003 [DLGS196], and subsequent
modifications and amendments, by putting in place suitable security controls which, at least, conforms to
Chapter II (“Minimum security measures”) of the aforesaid Decree. In particular, Actalis:
adopts suitable measures to control access to the archives
adopts suitable procedures for management of authentication credentials
keeps a permanent audit log of access to the archives
performs periodic backup of data for recovery purposes.
Within the service regulated by this CPS, the CA does not collect and does not process sensitive data nor judi-
cial data (with reference to article 4 of the aforesaid Decree [DLGS196]).
9.4 Intellectual property rights
This CPS is the property of Actalis who reserves all rights associated with the same.
The subscriber of the certificate keeps all the rights on its own commercial marks (brand names) and its own
domain names.
With regards to the property rights of other data and information, the applicable law shall be applied.
9.5 Obligations and guarantees
9.5.1 Certification Authority
The CA shall:
operate in compliance with this CPS;
identify the applicants as described in this CPS;
issue and manage the certificates as described in this CPS;
provide an efficient suspension and revocation service for the certificates;
guarantee that the subscriber, at the time when the certificate is issued, did possess the corresponding
private key;
timely inform about any eventual compromise of its own private key;
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 45 of 49 09 December 2014
provide clear information about the procedures and requirements of the service;
provide a copy of this CPS to anyone requesting it;
guarantee processing of personal data in compliance with applicable law;
provide an efficient and reliable information service about the status of the certificates.
9.5.2 Registration Authority
This section only applies to external RAs, that is, to Customers acting as Enterprise RAs (see §1.3.2). They have
the following obligations:
only use the procedures and tools provided by the CA, and only in the way provided by the CA;
access the web-based certificate management interface provided by the CA only from clean working
stations (e.g. PCs), equipped with a good quality- and regularly updated antivirus;
ensure confidentiality of the credentials provided by the CA to access the web-based certificate
management interface.
9.5.3 Subscribers
Certificate Subscribers, namely certificate owners, shall:
read, understand and fully accept this CPS;
request the certificate by the methods prescribed in this CPS;
provide the CA with precise and true information during the registration phase;
ensure confidentiality of secret codes (e.g. passwords) provided to them by the CA;
adopt suitable technical and organizational measures to avoid compromise of their own private keys;
install and start using the certificate only after having checked that it contains correct information;
use the certificate only in the ways and for the purposes provided for in this CPS;
never use their private keys, for no reason whatsoever, for issuing other certificates in turn;
in the event of confirmed compromise of any of their own private keys, immediately request
revocation of the corresponding certificates and immediately stop using those certificates;
in the event of CA compromise, immediately stop using their certificates;
immediately request revocation of the certificate in the case when any of the information contained in
the certificate (i.e. company name, web site address etc.) is no longer valid;
immediately inform the CA, after issue and up to expiry or revocation of the certificate, of any changes
in the information supplied during the application phase;
respond within 48 ore to requests by the CA related to possible improper use of certificates or possible
key compromises;
upon revocation of their certificate(s), immediately stop using the revoked certificates, and:
– in the case of Code Signing certificates: immediately remove the signed software from the web
sites on which it is published;
– in the case of SSL Server certificates: immediately remove the certificate from the web site on
which it is installed.
stop using certificates upon their expiration.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 46 of 49 09 December 2014
Moreover, the subscribers of certificates shall:
in the case of Code Signing certificates: not sign malicious software (malware) and not describe the
signed software in a misleading way with respect to its real functionality and purpose;
in the case of SSL Server certificates: exclusively install the certificate on the proper web sites and
domains (as indicated in the certificate) and operate those web sites only in ways allowed by this CPS
and for lawful purposes only.
Subscribers acknowledge and accept that the CA, if made aware that a Subscriber’s certificate is being used for
unlawful purposes (e.g. phishing, Man-In-The-Middle attacks, distribution of malware, etc.), or for issuing other
certificates, will immediately revoke that certificate without notice.
9.5.4 Relying parties
The term “Relying Parties” refers to all those entities (other than subscribers) that rely on certificates for taking
a decision (such as: making information or resources available to the certificate owner, use/process the re-
sources or information obtained from the certificate owner, etc.).
The relying parties, when dealing with certificates issued under this CPS, are required to:
make a reasonable effort to acquire a sufficient understanding of certificates and PKIs;
verify the status of certificates by accessing the information services described at §4.10;
only rely on certificates which are not expired, nor suspended nor revoked.
9.6 Disclaimers of warranties
The CA has no further obligations and shall not be obliged to guarantee anything more than what is described
in this CPS (refer to section 9.5.1) or prescribed by applicable law.
9.7 Limitations of liability
The CA declines any responsibility for damages suffered by anyone due to the non-fulfilment, by the client or
third parties, of one or more parts of this CPS.
The CA declines any responsibility for damages suffered by the client due to non-reception of communications
from the CA as a consequence of an incorrect e-mail address supplied during the application phase.
Without prejudice to the mandatory provisions of law, Actalis shall only be held responsible, for any reason
whatsoever deriving from this CPS, in the cases of malice or gross negligence.
9.8 Indemnities
Customers shall pay compensation of any damages suffered by Actalis in the following cases:
false declarations in the certification request;
failure to provide information to the CA about essential matters and facts due to negligence or with
the objective of deceiving the CA;
use of names (for example, domain names, brand names) in violation of intellectual property rights;
use of certificates for unlawful purposes and/or for purposes not allowed by this CPS.
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 47 of 49 09 December 2014
9.9 Term and termination
This CPS shall enter into force at the time it is published on the CA web site (see chapter 2) and shall remain in
force until it is replaced with a new version.
9.10 Correspondence
Actalis accepts correspondence related to this CPS, to be sent with the methods indicated at §1.5, and shall re-
spond within five working days.
Problems and complaints related to certificates issued under this CPS (e.g. possible misuses, problems access-
ing certificate status information, possible breach of this CPS, etc.) can be reported to the CA at any time by
sending e-mail to [email protected]. Or, send a letter to the following address:
Assistenza Clienti
ACTALIS S.p.A.
Via dell’Aprica 18
20158 Milano
ITALIA
The message or letter must include, in addition to a clear description of the alleged problem, at least the name
and telephone number of the sender. Actalis commits to examine all proper messages within 2 working days
and take the necessary steps.
9.11 Amendments
Actalis reserves the right to modify this CPS at any time whatsoever without prior notification.
9.12 Resolution of disputes
Any controversies deriving from this CPS between Actalis and the clients of the service shall be deferred to an
arbitration committee. The seat of the arbitration shall be in Milan, Italy.
9.13 Applicable law
This CPS is subject to Italian Law and as such shall be interpreted and carried out. For that not expressly pre-
scribed in this CPS, the applicable law shall prevail.
Other contracts in which this CPS is incorporated by means of reference, may contain distinct and separate
clauses with respect to applicable law.
9.14 Compliance with applicable law
At the revision date of this CPS, Actalis is not aware of any legislation relevant to the services described herein.
In any case this CPS shall be subject to applicable laws.
9.15 Force majeure
Actalis shall not be responsible for the failure to carry out the obligations assumed herein in the case when
such non-fulfilment is due to causes not attributable to Actalis, such as – for instance, but not limited to – act of
providence, unforeseen technical problems completely out of any form of control, intervention by the authori-
ty, force majeure, natural disasters, industrial actions including company strikes – inclusive of those at the
CAACT-03-01-04 Certification Practice Statement
Copyright © Actalis S.p.A. Page 48 of 49 09 December 2014
premises of parties which are used for the execution of the activities associated with the services described
herein, and other causes attributable to third parties.
9.16 Service levels
The CA guarantees the following minimum service levels:
Metric Objective Measurement basis
Directory server availability (24 x 7) 99.8 % annual
Web portal availability (24 x 7) 99.8 % annual
Certificate issuing time max 5 working days in 95% of all cases
annual
Time for certificate suspension or revocation (when requested through the CA web site)
max 2 minutes in 95% of all cases
annual
Time for certificate revocation (when requested by e-mail, ordinary mail or fax)
max 6 hours in 95% of all cases
annual