GlobalSign
Certification Practice Statement

Date: August 21, 2023
Version: v10.1

Table of Contents
TABLE OF CONTENTS ................................................................................................................................ 2
DOCUMENT HISTORY ............................................................................................................................... 8
ACKNOWLEDGMENTS .............................................................................................................................. 9
1.0

INTRODUCTION ...........................................................................................................................10

1.1
OVERVIEW ........................................................................................................................................ 12
1.1.1
Certificate Naming ................................................................................................................. 14
1.2
DOCUMENT NAME AND IDENTIFICATION ................................................................................................. 16
1.3
PKI PARTICIPANTS .............................................................................................................................. 22
1.3.1
Certification Authorities ......................................................................................................... 22
1.3.2
Registration Authorities ......................................................................................................... 22
1.3.3
Subscribers ............................................................................................................................. 25
1.3.4
Relying Parties ....................................................................................................................... 25
1.3.5
Other Participants .................................................................................................................. 25
1.4
CERTIFICATE USAGE ............................................................................................................................ 25
1.4.1
Appropriate Certificate Usage ............................................................................................... 25
1.4.2
Prohibited Certificate usage .................................................................................................. 28
1.5
POLICY ADMINISTRATION ..................................................................................................................... 28
1.5.1
Organization Administering the Document ........................................................................... 28
1.5.2
Contact Person ....................................................................................................................... 28
1.5.3
Person Determining CPS Suitability for the Policy.................................................................. 29
1.5.4
CPS Approval Procedures ....................................................................................................... 29
1.6
DEFINITIONS AND ACRONYMS ............................................................................................................... 29
2.0
2.1
2.2
2.3
2.4
3.0

PUBLICATION AND REPOSITORY RESPONSIBILITIES .....................................................................38
REPOSITORIES .................................................................................................................................... 38
PUBLICATION OF CERTIFICATE INFORMATION ........................................................................................... 38
TIME OR FREQUENCY OF PUBLICATION.................................................................................................... 39
ACCESS CONTROLS ON REPOSITORIES ..................................................................................................... 39
IDENTIFICATION AND AUTHENTICATION .....................................................................................39

3.1
NAMING ........................................................................................................................................... 40
3.1.1
Types of Names...................................................................................................................... 40
3.1.2
Need for Names to be Meaningful ........................................................................................ 40
3.1.3
Anonymity or Pseudonymity of Subscribers ........................................................................... 40
3.1.4
Rules for Interpreting Various Name Forms .......................................................................... 40
3.1.5
Uniqueness of Names ............................................................................................................ 40
3.1.6
Recognition, Authentication, and Role of Trademarks .......................................................... 41
3.2
INITIAL IDENTITY VALIDATION................................................................................................................ 41
3.2.1
Method to Prove Possession of Private Key ........................................................................... 41
3.2.2
Authentication of Organization Identity ................................................................................ 41
3.2.3
Authentication of Individual identity ..................................................................................... 44
3.2.4
Non-Verified Subscriber Information ..................................................................................... 49
3.2.5
Validation of Authority .......................................................................................................... 49
3.2.6
Criteria for Interoperation ..................................................................................................... 51
3.2.7
Authentication of Domain Names ......................................................................................... 51
3.2.8
Authentication of IP Addresses .............................................................................................. 52
3.2.9
Authentication of Email Addresses ........................................................................................ 52
3.3
IDENTIFICATION AND AUTHENTICATION FOR RE-KEY REQUESTS.................................................................... 53
3.3.1
Identification and Authentication for Routine Re-key ........................................................... 53
3.3.2
Identification and Authentication for Re-key After Revocation ............................................. 53
3.4
IDENTIFICATION AND AUTHENTICATION FOR REVOCATION REQUEST ............................................................. 53
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

2 of 98

4.0

CERTIFICATE LIFECYCLE OPERATIONAL REQUIREMENTS ..............................................................53

4.1
CERTIFICATE APPLICATION .................................................................................................................... 53
4.1.1
Who Can Submit a Certificate Application............................................................................. 53
4.1.2
Enrollment Process and Responsibilities ................................................................................ 53
4.2
CERTIFICATE APPLICATION PROCESSING .................................................................................................. 54
4.2.1
Performing Identification and Authentication Functions ....................................................... 54
4.2.2
Approval or Rejection of Certificate Applications .................................................................. 54
4.2.3
Time to Process Certificate Applications ................................................................................ 55
4.3
CERTIFICATE ISSUANCE ........................................................................................................................ 55
4.3.1
CA Actions during Certificate Issuance .................................................................................. 55
4.3.2
Notifications to Subscriber by the CA of Issuance of Certificate ............................................ 56
4.4
CERTIFICATE ACCEPTANCE .................................................................................................................... 56
4.4.1
Conduct Constituting Certificate Acceptance ........................................................................ 56
4.4.2
Publication of the Certificate by the CA ................................................................................. 56
4.4.3
Notification of Certificate Issuance by the CA to Other Entities ............................................ 56
4.5
KEY PAIR AND CERTIFICATE USAGE......................................................................................................... 56
4.5.1
Subscriber Private Key and Certificate Usage ........................................................................ 56
4.5.2
Relying Party Public Key and Certificate Usage ..................................................................... 57
4.6
CERTIFICATE RENEWAL ........................................................................................................................ 57
4.6.1
Circumstances for Certificate Renewal .................................................................................. 57
4.6.2
Who May Request Renewal ................................................................................................... 57
4.6.3
Processing Certificate Renewal Requests .............................................................................. 57
4.6.4
Notification of New Certificate Issuance to Subscriber .......................................................... 57
4.6.5
Conduct Constituting Acceptance of a Renewal Certificate ................................................... 57
4.6.6
Publication of the Renewal Certificate by the CA .................................................................. 57
4.6.7
Notification of Certificate Issuance by the CA to Other Entities ............................................ 57
4.7
CERTIFICATE RE-KEY ........................................................................................................................... 57
4.7.1
Circumstances for Certificate Re-Key ..................................................................................... 58
4.7.2
Who May Request Certification of a New Public Key ............................................................ 58
4.7.3
Processing Certificate Re-Keying Requests ............................................................................ 58
4.7.4
Notification of New Certificate Issuance to Subscriber .......................................................... 58
4.7.5
Conduct Constituting Acceptance of a Re-Keyed Certificate ................................................. 58
4.7.6
Publication of the Re-Keyed Certificate by the CA ................................................................. 58
4.7.7
Notification of Certificate Issuance by the CA to Other Entities ............................................ 58
4.8
CERTIFICATE MODIFICATION ................................................................................................................. 58
4.8.1
Circumstances for Certificate Modification ........................................................................... 58
4.8.2
Who May Request Certificate Modification........................................................................... 58
4.8.3
Processing Certificate Modification Requests ........................................................................ 58
4.8.4
Notification of New Certificate Issuance to Subscriber .......................................................... 58
4.8.5
Conduct Constituting Acceptance of Modified Certificate ..................................................... 58
4.8.6
Publication of the Modified Certificate by the CA .................................................................. 59
4.8.7
Notification of Certificate Issuance by the CA to Other Entities ............................................ 59
4.9
CERTIFICATE REVOCATION AND SUSPENSION ............................................................................................ 59
4.9.1
Circumstances for Revocation ............................................................................................... 59
4.9.2
Who Can Request Revocation ................................................................................................ 61
4.9.3
Procedure for Revocation Request......................................................................................... 61
4.9.4
Revocation Request Grace Period .......................................................................................... 62
4.9.5
Time Within Which CA Must Process the Revocation Request .............................................. 62
4.9.6
Revocation Checking Requirements for Relying Parties ........................................................ 62
4.9.7
CRL Issuance Frequency ......................................................................................................... 63
4.9.8
Maximum Latency for CRLs ................................................................................................... 63
4.9.9
On-Line Revocation/Status Checking Availability .................................................................. 63
4.9.10 On-Line Revocation Checking Requirements ......................................................................... 63
4.9.11 Other Forms of Revocation Advertisements Available .......................................................... 64
4.9.12 Special Requirements Related to Key Compromise ............................................................... 64
4.9.13 Circumstances for Suspension ............................................................................................... 64
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

3 of 984.9.14 Who Can Request Suspension ................................................................................................ 64
4.9.15 Procedure for Suspension Request......................................................................................... 65
4.9.16 Limits on Suspension Period .................................................................................................. 65
4.10 CERTIFICATE STATUS SERVICES .............................................................................................................. 65
4.10.1 Operational Characteristics ................................................................................................... 65
4.10.2 Service Availability ................................................................................................................. 65
4.10.3 Operational Features ............................................................................................................. 65
4.11 END OF SUBSCRIPTION......................................................................................................................... 65
4.12 KEY ESCROW AND RECOVERY ................................................................................................................ 65
4.12.1 Key Escrow and Recovery Policy and Practices ...................................................................... 65
4.12.2 Session Key Encapsulation and Recovery Policy and Practices .............................................. 65
5.0

FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS ..........................................................66

5.1
PHYSICAL CONTROLS ........................................................................................................................... 66
5.1.1
Site Location and Construction .............................................................................................. 66
5.1.2
Physical Access....................................................................................................................... 66
5.1.3
Power and Air Conditioning ................................................................................................... 66
5.1.4
Water Exposures .................................................................................................................... 66
5.1.5Fire Prevention and Protection .............................................................................................. 67
5.1.6
Media Storage ....................................................................................................................... 67
5.1.7
Waste Disposal ...................................................................................................................... 67
5.1.8
Off-Site Backup ...................................................................................................................... 67
5.2
PROCEDURAL CONTROLS ...................................................................................................................... 67
5.2.1
Trusted Roles ......................................................................................................................... 67
5.2.2
Number of Persons Required per Task ................................................................................... 67
5.2.3
Identification and Authentication for Each Role .................................................................... 67
5.2.4
Roles Requiring Separation of Duties..................................................................................... 67
5.3
PERSONNEL CONTROLS ........................................................................................................................ 68
5.3.1
Qualifications, Experience, and Clearance Requirements...................................................... 68
5.3.2
Background Check Procedures ............................................................................................... 68
5.3.3
Training Requirements........................................................................................................... 68
5.3.4
Retraining Frequency and Requirements ............................................................................... 68
5.3.5
Job Rotation Frequency and Sequence .................................................................................. 69
5.3.6
Sanctions for Unauthorized Actions ....................................................................................... 69
5.3.7
Independent Contractor Requirements ................................................................................. 69
5.3.8
Documentation Supplied to Personnel................................................................................... 69
5.4
AUDIT LOGGING PROCEDURES .............................................................................................................. 69
5.4.1
Types of Events Recorded ...................................................................................................... 69
5.4.2
Frequency of Processing Log .................................................................................................. 70
5.4.3
Retention Period for Audit Log .............................................................................................. 70
5.4.4
Protection of Audit Log .......................................................................................................... 70
5.4.5
Audit Log Backup Procedures ................................................................................................ 70
5.4.6
Audit Collection System ......................................................................................................... 70
5.4.7
Notification to Event-Causing Subject ................................................................................... 70
5.4.8
Vulnerability Assessments ..................................................................................................... 70
5.5RECORDS ARCHIVAL ............................................................................................................................ 71
5.5.1
Types of Records Archived ..................................................................................................... 71
5.5.2
Retention Period for Archive .................................................................................................. 71
5.5.3
Protection of Archive ............................................................................................................. 71
5.5.4
Archive Backup Procedures .................................................................................................... 71
5.5.5
Requirements for Timestamping of Records .......................................................................... 71
5.5.6
Archive Collection System (Internal or External) .................................................................... 71
5.5.7
Procedures to Obtain and Verify Archive Information ........................................................... 71
5.6
KEY CHANGEOVER .............................................................................................................................. 72
5.7
COMPROMISE AND DISASTER RECOVERY ................................................................................................. 72
5.7.1
Incident and Compromise Handling Procedures .................................................................... 72
5.7.2
Computing Resources, Software, and/or Data Are Corrupted ............................................... 72
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

4 of 98

5.7.3
Entity Private Key Compromise Procedures ........................................................................... 72
5.7.4
Availability of revocation status ............................................................................................ 72
5.7.5
Business Continuity Capabilities After a Disaster .................................................................. 73
5.8
CA OR RA TERMINATION ..................................................................................................................... 73
5.8.1
Successor Issuing Certification Authority ............................................................................... 73
6.0

TECHNICAL SECURITY CONTROLS.................................................................................................73

6.1
KEY PAIR GENERATION AND INSTALLATION .............................................................................................. 73
6.1.1
Key Pair Generation ............................................................................................................... 73
6.1.2
Private Key Delivery to Subscriber ......................................................................................... 74
6.1.3
Public Key Delivery to Certificate Issuer ................................................................................. 75
6.1.4
CA Public Key Delivery to Relying Parties ............................................................................... 75
6.1.5
Key Sizes................................................................................................................................. 75
6.1.6
Public Key Parameters Generation and Quality Checking ..................................................... 76
6.1.7
Key Usage Purposes (as per X.509 v3 Key Usage Field) ......................................................... 76
6.2
PRIVATE KEY PROTECTION AND CRYPTOGRAPHIC MODULE ENGINEERING CONTROLS ....................................... 76
6.2.1
Cryptographic Module Standards and Controls ..................................................................... 76
6.2.2
Private Key (n out of m) Multi-Person Control ....................................................................... 76
6.2.3
Private Key Escrow ................................................................................................................. 77
6.2.4
Private Key Backup ................................................................................................................ 77
6.2.5
Private Key Archival ............................................................................................................... 77
6.2.6
Private Key Transfer into or from a Cryptographic Module ................................................... 77
6.2.7
Private Key Storage on Cryptographic Module ...................................................................... 77
6.2.8
Method of Activating Private Key .......................................................................................... 77
6.2.9
Method of Deactivating Private Key ...................................................................................... 77
6.2.10 Method of Destroying Private Key ......................................................................................... 77
6.2.11 Cryptographic Module Rating ................................................................................................ 77
6.3
OTHER ASPECTS OF KEY PAIR MANAGEMENT........................................................................................... 77
6.3.1
Public Key Archival ................................................................................................................. 77
6.3.2
Certificate Operational Periods and Key Pair Usage Periods ................................................. 77
6.4
ACTIVATION DATA .............................................................................................................................. 78
6.4.1
Activation Data Generation and Installation ......................................................................... 78
6.4.2
Activation Data Protection .................................................................................................... 78
6.4.3
Other Aspects of Activation Data .......................................................................................... 78
6.5
COMPUTER SECURITY CONTROLS ........................................................................................................... 78
6.5.1
Specific Computer Security Technical Requirements ............................................................. 78
6.5.2
Computer Security Rating ...................................................................................................... 79
6.6
LIFECYCLE TECHNICAL CONTROLS ........................................................................................................... 79
6.6.1
System Development Controls ............................................................................................... 79
6.6.2
Security Management Controls ............................................................................................. 79
6.6.3
Lifecycle Security Controls...................................................................................................... 79
6.7
NETWORK SECURITY CONTROLS ............................................................................................................ 79
6.8
TIMESTAMPING .................................................................................................................................. 80
6.8.1
PDF Signing Timestamping Services ...................................................................................... 80
6.8.2
Code Signing and EV Code Signing Timestamping Services ................................................... 80
7.0

CERTIFICATE, CRL, AND OCSP PROFILES .......................................................................................80

7.1
CERTIFICATE PROFILE........................................................................................................................... 80
7.1.1
Version Number(s) ................................................................................................................. 80
7.1.2
Certificate Extensions ............................................................................................................ 80
7.1.3
Algorithm Object Identifiers .................................................................................................. 80
7.1.4
Name Forms........................................................................................................................... 81
7.1.5
CertificatesName Constraints ................................................................................................ 81
7.1.6
Certificate Policy Object Identifier ......................................................................................... 81
7.1.7
Usage of Policy Constraints Extension ................................................................................... 81
7.1.8
Policy Qualifiers Syntax and Semantics ................................................................................. 81
7.1.9
Processing Semantics for the Critical Certificate Policies Extension ...................................... 81
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

5 of 98

7.1.10 Serial Numbers....................................................................................................................... 82
7.1.11 Special Provisions for Qualified Certificates........................................................................... 82
7.2
CRL PROFILE ..................................................................................................................................... 82
7.2.1
Version Number(s) ................................................................................................................. 82
7.2.2
CRL and CRL Entry Extensions ................................................................................................ 83
7.3
OCSP PROFILE................................................................................................................................... 83
7.3.1
Version Number(s) ................................................................................................................. 83
7.3.2
OCSP Extensions..................................................................................................................... 83
8.0
8.1
8.2
8.3
8.4
8.5
8.6
8.7
8.8
9.0

COMPLIANCE AUDIT AND OTHER ASSESSMENTS .........................................................................84
FREQUENCY AND CIRCUMSTANCES OF ASSESSMENT .................................................................................. 84
IDENTITY/QUALIFICATIONS OF ASSESSOR ................................................................................................ 84
ASSESSOR’S RELATIONSHIP TO ASSESSED ENTITY....................................................................................... 84
TOPICS COVERED BY ASSESSMENT.......................................................................................................... 84
ACTIONS TAKEN AS A RESULT OF DEFICIENCY ........................................................................................... 84
COMMUNICATIONS OF RESULTS ............................................................................................................ 84
SELF-AUDIT ....................................................................................................................................... 85
REVIEW OF DELEGATED PARTIES ............................................................................................................. 85
OTHER BUSINESS AND LEGAL MATTERS ......................................................................................85

9.1
FEES................................................................................................................................................. 85
9.1.1
Certificate Issuance or Renewal Fees ..................................................................................... 85
9.1.2
Certificate Access Fees ........................................................................................................... 85
9.1.3
Revocation or Status Information Access Fees ...................................................................... 85
9.1.4
Fees for Other Services .......................................................................................................... 85
9.1.5
Refund Policy ......................................................................................................................... 85
9.2
FINANCIAL RESPONSIBILITY ................................................................................................................... 85
9.2.1
Insurance Coverage ............................................................................................................... 85
9.2.2
Other Assets ........................................................................................................................... 85
9.2.3
Insurance or Warranty Coverage for End Entities ................................................................. 86
9.3
CONFIDENTIALITY OF BUSINESS INFORMATION ......................................................................................... 86
9.3.1
Scope of Confidential Information ......................................................................................... 86
9.3.2
Information Not Within the Scope of Confidential Information ............................................ 86
9.3.3
Responsibility to Protect Confidential Information ................................................................ 86
9.4
PRIVACY OF PERSONAL INFORMATION .................................................................................................... 86
9.4.1
Privacy Plan ........................................................................................................................... 86
9.4.2
Information Treated as Private .............................................................................................. 86
9.4.3
Information Not Deemed Private........................................................................................... 86
9.4.4
Responsibility to Protect Private Information ........................................................................ 86
9.4.5
Notice and Consent to Use Private Information .................................................................... 86
9.4.6
Disclosure Pursuant to Judicial or Administrative Process ..................................................... 87
9.4.7
Other Information Disclosure Circumstances ........................................................................ 87
9.5
INTELLECTUAL PROPERTY RIGHTS ........................................................................................................... 87
9.6
REPRESENTATIONS AND WARRANTIES..................................................................................................... 87
9.6.1
CA Representations and Warranties ...................................................................................... 87
9.6.2
RA Representations and Warranties...................................................................................... 89
9.6.3
Subscriber Representations and Warranties ......................................................................... 89
9.6.4
Relying Party Representations and Warranties ..................................................................... 92
9.6.5
Representations and Warranties of Other Participants......................................................... 93
9.7
DISCLAIMERS OF WARRANTIES .............................................................................................................. 93
9.8
LIMITATIONS OF LIABILITY..................................................................................................................... 93
9.9
INDEMNITIES ..................................................................................................................................... 93
9.9.1
Indemnification by GlobalSign ............................................................................................... 93
9.9.2
Indemnification by Subscribers .............................................................................................. 94
9.9.3
Indemnification by Relying Parties ........................................................................................ 94
9.10 TERM AND TERMINATION..................................................................................................................... 94
9.10.1 Term ....................................................................................................................................... 94
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

6 of 989.10.2 Termination ........................................................................................................................... 94
9.10.3 Effect of Termination and Survival......................................................................................... 94
9.11 INDIVIDUAL NOTICES AND COMMUNICATIONS WITH PARTICIPANTS .............................................................. 94
9.12 AMENDMENTS ................................................................................................................................... 94
9.12.1 Procedure for Amendment .................................................................................................... 94
9.12.2 Notification Mechanism and Period ...................................................................................... 94
9.12.3 Circumstances Under Which OID Must be Changed .............................................................. 94
9.13 DISPUTE RESOLUTION PROVISIONS......................................................................................................... 94
9.14 GOVERNING LAW ............................................................................................................................... 95
9.15 COMPLIANCE WITH APPLICABLE LAW...................................................................................................... 95
9.16 MISCELLANEOUS PROVISIONS ............................................................................................................... 95
9.16.1 Entire Agreement ................................................................................................................... 95
9.16.2 Assignment ............................................................................................................................ 95
9.16.3 Severability ............................................................................................................................ 95
9.16.4 Enforcement (Attorney’s Fees and Waiver of Rights) ............................................................ 95
9.16.5 Force Majeure ........................................................................................................................ 96
9.17 OTHER PROVISIONS ............................................................................................................................ 96
10.0

APPENDIX A .................................................................................................................................97

10.1 S/MIME BR CERTIFICATES .................................................................................................................. 97
10.1.1 Enterprise RA Requirements .................................................................................................. 97

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

7 of 98

Document History
VersionRelease Date

Description

7.0

March 28, 2023

Updated naming of "PSD2" Certificates to "Open Banking"Updates for CA/B Forum ballots CSC-13 and CSC-17
Revision of OIDs
Removed requirement of digitally signing this document for
releaseClarified “subject uniqueness”
Included RA as a role in the notification and revocation process
Review of audit logging and records archival sections
Review of private key protection and cryptographic module
engineering section
Clarified revocation limitations of short-term Certificates
Grammatical updates, language consistency

7.1

August 21, 2023

Updates for Baseline Requirements for S/MIME
Updates for Baseline Requirements for TLS (v2.0.0)
Updates to revocation reasons and status changes
Review of Registration Authorities and Enterprise RAs
Review of Representations and Warranties
Clarified revocation limitations of short-term Certificates
Grammatical updates, language consistency

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

8 of 98

Acknowledgments
GlobalSign® and the GlobalSign Logo are registered trademarks of GMO GlobalSign K.K.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

9 of 981.0 Introduction
This Certification Practice Statement (CPS) applies to the products and services of GlobalSign
NV/SA and affiliated entities (“GlobalSign”). Primarily this pertains to the issuance and lifecycle
management of Certificates including validity checking services. GlobalSign may also provide
additional services, such as timestamping. This CPS may be updated from time to time as outlined
in Section 1.5 Policy Administration. The latest version may be found on the GlobalSign groupcompany Repository at https://www.globalsign.com/repository. (Alternative language versions may
be available to aid Relying Parties and Subscribers in their understanding of this CPS; however, inthe event of any inconsistency, the English language version shall control.)
A CPS highlights the "procedures under which a Digital Certificate is issued to a particularcommunity and/or class of application with common security requirements.” This CPS meets theformal requirements of Internet Engineering Task Force (IETF) RFC 3647, dated November 2003
with regard to content, layout, and format (RFC 3647 obsoletes RFC 2527). An RFC issued by
IETF is an authoritative source of guidance with regard to standard practices in the area ofelectronic signatures and Certificate management. While certain section titles are included in thisCPS according to the structure of RFC 3647, the topic may not necessarily apply to services of
GlobalSign. These sections state ‘No stipulation.’ Additional information is presented in subsectionsof the standard structure where necessary. Meeting the format requirements of RFC 3647
enhances and facilitates the mapping and interoperability with other third party CAs and provides
Relying Parties with advance notice of GlobalSign’s practices and procedures.
This CPS aims to comply with the requirements of:
•
•
•
•
•
•
•
•
•
•
•

Browsers’ root programs
RFC3647, Request for Comments: 3647, Internet X.509 Public Key Infrastructure:
Certificate Policy and Certification Practices Framework, Chokhani, et al, November 2003
North American Energy Standards Board (NAESB) Accreditation Requirements for
Authorized Certificate Authorities
WebTrust Principles and Criteria for Certification Authorities
WebTrust Principles and Criteria for Certification Authorities - SSL Baseline with Network
Security
WebTrust Principles and Criteria for Certification Authorities - Extended Validation SSL
WebTrust Principles and Criteria for Certification Authorities – Code Signing Baseline
Requirements
WebTrust Principles and Criteria for Certification Authorities – S/MIME
Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July
2014 on electronic identification and trust services for electronic transactions in the internalmarket and repealing Directive 1999/93/EC
The Electronic Identification and Trust Services for Electronic Transactions (Amendmentetc.) (EU Exit) Regulations 2019)
The Electronic Identification and Trust Services for Electronic Transactions Regulation
2016 (2016 No.696))

GlobalSign conforms to current versions of the CA/Browser Forum Requirements:
•
•
•
•
•

CA/Browser Forum Baseline Requirements for the Issuance and Management of
Publicly-Trusted Certificates (“Baseline Requirements for TLS”)
CA/Browser Forum Guidelines For The Issuance And Management Of Extended
Validation Certificates (“EV Guidelines”)
CA/Browser Forum Network and Certificate System Security Requirements
CA/Browser Forum Baseline Requirements for Code Signing (“Baseline Requirements for
Code Signing”)
CA/Browser Forum Baseline Requirements for the Issuance and Management of PubliclyTrusted S/MIME Certificates (“Baseline Requirements for S/MIME”)1

1 Effective September 1st, 2023

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

10 of 98

published at http://www.cabforum.org. If there is any inconsistency between this document and the
CA/Browser Forum Requirements above, the CA/Browser Forum Requirements take precedence
over this document.
This CPS addresses the technical, procedural and personnel policies and practices of GlobalSign
during the complete lifecycle of Certificates issued by GlobalSign. This CPS addresses therequirements of the CA that issues Certificates of various types. The chaining to any particular Root
CA may vary depending on the choice of intermediate Certificate and Cross Certificate used orprovided by a platform or client.
This CPS is applicable to the Subscriber and/or Relying Party, who uses, relies upon, or attempts
to rely upon certification services made available by the Certification Authority referring to this CPS.
For Subscribers, this CPS becomes effective and binding by accepting a Subscriber Agreement or
Terms of Use. For Relying Parties, this CPS becomes binding by relying upon a Certificate issued
under this CPS. In addition, Subscribers are required by the Subscriber Agreement to inform their
Relying Parties that the CPS is itself binding upon those Relying Parties.
The English version of this CPS is the primary version. In the event of any conflict or inconsistency
between the English CPS and any localized or translated version, the provisions of the English
version shall prevail.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

11 of 98

1.1

Overview

This CPS applies to the complete hierarchy of Certificates issued by GlobalSign. The purpose ofthis CPS is to present the GlobalSign practices and procedures in managing Certificates and todemonstrate compliance with requirements pertaining to the issuance of Certificates according to
GlobalSign’s own and industry requirements pursuant to the standards set out above. Additionally,
eIDAS Regulation (Regulation (EU)N910/2014) (“eIDAS”) and eIDAS (UK Legislation) and The
Electronic Identification and Trust Services for Electronic Transactions Regulations 2016 (“UKeIDAS”) provide for the recognition of electronic signatures that are used for the purposes ofauthentication or non-repudiation/contentCommitment. In this regard, GlobalSign operates within
the scope of the applicable sections of the Law when delivering its services. Trust services for theUnited Kingdom are operated by and provided through GMO GlobalSign LTD., an affiliate entity of
GlobalSign.
This CPS aims to document GlobalSign’s delivery of certification services and management of theCertificate lifecycle of any issued Subordinate CA, client, server, and other purpose end entity
Certificates.
The Certificate types addressed in this CPS are the following:
PersonalSign 1
PersonalSign 2
PersonalSign 2 Pro
PersonalSign 2 Pro DepartmentSign
PersonalSign 3 Pro

PersonalSign Partners
IntranetSSL
DomainSSL
AlphaSSL
OrganizationSSL
Extended Validation SSL2
GlobalSign Timestamping
AATL
Code Signing3
Extended Validation Code Signing1
North American Energy Standard Board(NAESB) Authorized CA Certificates
Hosted Root

Qualified Certificates for Electronic
Signatures
Qualified Certificates for Electronic
Seals

A personal Certificate of low assurance
A personal Certificate of medium assurance
A personal Certificate of medium assurance with reference toprofessional context
A machine, device, department, or role Certificate of medium
assurance with reference to professional context
A personal authentication Certificate of high assurance withreference to professional context
A private Certification Authority created as a trust anchor issuing
PersonalSign 2 Pro or PersonalSign 2 Pro DepartmentSign
A Certificate to authenticate web servers which does not chain
to a publicly trusted GlobalSign RootA Certificate to authenticate web servers
A Certificate to authenticate web servers
A Certificate to authenticate web servers
A Certificate to authenticate web servers
A Certificate to authenticate time sources
A Certificate of medium hardware assurance for use with Adobe
AATL and Microsoft Office documents
A Certificate to authenticate data objects
A Certificate to authenticate data objects
A personal, role, server, or device Certificate of either
rudimentary, basic, or medium, with reference to professional
context authorized by an Authorized Certification Authority
A service whereby GlobalSign maintains a Root Key andCertificate on behalf of a non-GlobalSign entity and in parallel
provides a cross certificate until such time as the Root has been
embedded into Root stores. The non-GlobalSign entity procuresa WebTrust audit in their name during this period.
eIDAS/UK eIDAS compliant qualified Certificates used forproviding electronic signatures
eIDAS/UK eIDAS compliant qualified Certificates used forproviding Electronic Seals

2

These Certificates are issued and managed in accordance with the EV Guidelines and Baseline
Requirements for Code Signing. The remaining Certificate types shall be issued and managed inaccordance with the Baseline Requirements if so, indicated by the inclusion of CA/Browser Forum Policy
OIDs as detailed in Section 1.2 below.
3

These Certificates are issued and managed in accordance with the Baseline Requirements for CodeSigning.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

12 of 98

Qualified Web Authentication
Certificates
Certificates for Qualified Timestamping
S/MIMEeIDAS/UK eIDAS compliant qualified Certificates for web
authentication (SSL)
Certificates used for signing eIDAS compliant qualified
timestamps
A Certificate to sign, verify, encrypt, and decrypt email.

Note: As of September 1, 2023, all S/MIME Certificates (in scope of the Baseline Requirements
For S/MIME) issued must be S/MIME BR Certificates.
GlobalSign Certificates:••••

Can be used for electronic signatures in order to replace handwritten signatures wheretransacting parties choose.
Can be used to authenticate web resources, such as servers and other devices.
Can be used to digitally sign code, documents, and other data objects; andCan be used for encryption of data.

This CPS identifies the roles, responsibilities and practices of all entities involved in the lifecycle,
use, reliance upon and management of GlobalSign Certificates. The provisions of this CPS apply
to practices, level of services, responsibilities, and liability bind all parties involved, including
GlobalSign, GlobalSign RA, Subscribers and Relying Parties. Certain provisions might also apply
to other entities such as the certification service provider, application provider, etc.
A GlobalSign Certificate Policy (CP) complements this CPS. The purpose of the GlobalSign CP isto state the “what is to be adhered to” and, therefore, set out an operational rule framework for thebroad range of GlobalSign products and services.
This CPS states “how the Certification Authority adheres to the Certificate Policy.” In doing so, thisCPS features a greater amount of detail and provides the end user with an overview of theprocesses, procedures, and conditions that GlobalSign uses in creating and maintaining theCertificates that it manages. In addition to the CP and CPS, GlobalSign maintains additional
documented polices addressing such issues as:
•
•
•
•
•

Business continuity and disaster recovery
Security policy
Personnel policies
Key management policies
Registration procedures

Additionally, other relevant documents include:•••

The GlobalSign Warranty Policy that addresses issues on warranties offered by
GlobalSign.
The GlobalSign Privacy Policy on the protection of personal data; andThe GlobalSign Certificate Policy that addresses the trust objectives for the GlobalSign
Root Certificates.

A Subscriber or Relying Party of a GlobalSign Issuing CA Certificate must refer to this CPS in orderto establish trust in a Certificate issued by GlobalSign as well as for information about the practices
of GlobalSign. It is also essential to establish the trustworthiness of the entire Certificate chain of
the hierarchy. This includes the Root CA Certificate as well as any operational Certificates. Thiscan be established based on the assertions within this CPS. For Qualified Certificates, validationof the certificate chain must be carried out successfully up to the GlobalSign trust anchor within therelevant EU or UK eIDAS trusted list.
All applicable GlobalSign policies are subject to audit by authorized third parties, which
GlobalSign highlights on its public facing web site via a WebTrust Seal of Assurance. Additional
information can be made available upon request.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

13 of 98

GlobalSign Certification Practice Statement

1.1.1

Certificate Naming

The GlobalSign Root CA Certificates governed by this CPS are:GlobalSign Public Root CA Certificates
•
•
•

•
•
•

GlobalSign Root CA – R1 with fingerprint EBD41040E4BB3EC742C9E381D31EF2A41A48B6685C96E7CEF3C1DF6CD4331C99
GlobalSign Root CA – R3 with fingerprint CBB522D7B7F127AD6A0113865BDF1CD4102E7D0759AF635A7CF4720DC963C53B
GlobalSign Root CA – R5 with fingerprint 179FBC148A3DD00FD24EA13458CC43BFA7F59C8182D783A513F6EBEC100C8924
GlobalSign Root CA – R6 with fingerprint 2CABEAFE37D06CA22ABA7391C0033D25982952C453647349763A3AB5AD6CCF69
GlobalSign Root CA – R46 with fingerprint 4FA3126D8D3A11D1C4855A4F807CBAD6CF919D3A5A88B03BEA2C6372D93C40C9
GlobalSign Root CA – E46 with fingerprint CBB9C44D84B8043E1050EA31A69F514955D7BFD2E2C6B49301019AD61D9F5058

GlobalSign actively promotes the inclusion of the Root Certificates above in hardware and software platforms that are capable of supporting Certificates andassociated cryptographic services. Where possible, GlobalSign will seek to enter into a contractual agreement with platform providers to ensure effective Root
Certificate life cycle management. However, GlobalSign also actively encourages platform providers at their own discretion to include GlobalSign CA Root
Certificates without contractual obligation. GlobalSign Root CA R2 & GlobalSign Root CA R4 are no longer owned by GlobalSign.
GlobalSign Public Non-TLS Root CA Certificates
•
•
•
•
•
•
•
•
•
•
•
•

GlobalSign Client Authentication Root R45 with fingerprint 165C7E810BD37C1D57CE9849ACCD500E5CB01EEA37DC550DB07E598AAD2474A8
GlobalSign Client Authentication Root E45 with fingerprint 8B0F0FAA2C00FE0532A8A54E7BC5FD139C1922C4F10F0B16E10FB8BE1A634964
GlobalSign Code Signing Root R45 with fingerprint 7B9D553E1C92CB6E8803E137F4F287D4363757F5D44B37D52F9FCA22FB97DF86
GlobalSign Code Signing Root E45 with fingerprint 26C6C5FD4928FD57A8A4C5724FDD279745869C60C338E262FFE901C31BD1DB2B
GlobalSign Document Signing Root R45 with fingerprint 38BE6C7EEB4547D82B9287F243AF32A9DEEB5DC5C9A87A0056F938D91B456A5A
GlobalSign Document Signing Root E45 with fingerprint F86973BDD0514735E10C1190D0345BF89C77E1C4ADBD3F65963B803FD3C9E1FF
GlobalSign Secure Mail Root R45 with fingerprint 319AF0A7729E6F89269C131EA6A3A16FCD86389FDCAB3C47A4A675C161A3F974
GlobalSign Secure Mail Root E45 with fingerprint 5CBF6FB81FD417EA4128CD6F8172A3C9402094F74AB2ED3A06B4405D04F30B19
GlobalSign Timestamping Root R45 with fingerprint 2BCBBFD66282C680491C8CD7735FDBBAB7A8079B127BEC60C535976834399AF7
GlobalSign Timestamping Root E46 with fingerprint 4774674B94B78F5CCBEF89FDDEBDABBD894A71B55576B8CC5E6876BA3EAB4538
GlobalSign IoT Root R60 with fingerprint 36E80B78775DDA9D0BAC964AC29D5A5EC4F3684E0C74445E954A191C2939B8E0
GlobalSign IoT Root E60 with fingerprint 43ED443C1F0CD46C9914B4272C24DC42CF6FE62B4AAB37585878A26D882AE4CB

The Root Certificates above are Public, WebTrust-audited Certificates that are configured for non-TLS use, to cater to GlobalSign’s various product offerings.
GlobalSign actively promotes the inclusion of the Root Certificates above in hardware and software platforms that are capable of supporting Certificates andassociated cryptographic services according to the specified GlobalSign use case and applicable hardware/software trust bits. Where possible, GlobalSign willseek to enter into a contractual agreement with platform providers to ensure effective Root Certificate life cycle management. However, GlobalSign also actively
encourages platform providers at their own discretion to include GlobalSign Root Certificates without contractual obligation.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

14 of 98

GlobalSign Certification Practice Statement

GlobalSign Non-public Root CA Certificates
•
•
•
•
•
•

1.1.1.1

GlobalSign Non-Public Root CA – R1 with fingerprint 8D2EEFC79397F86BD4DB5B16A84144156D7EE352B57DE36B2C4FC738081DF9C9GlobalSign Non-Public Root CA – R2 with fingerprint 24FD17248F3B76F82AF2FD9C57D60F3EF60551508EE98DC460FD3A67866ECCEA
GlobalSign Non-Public Root CA – R3 with fingerprint A3BB9A2462E728818A6D30548BD3950B8C8DAE1B63FC89FE66E10BB7BAB5725A
GlobalSign Non-Public Root R43 with fingerprint D6273949002299CC84DA84984EAF3F20F4B09CC2A7B241DFD4B361A8432460EB
GlobalSign Trusted Platform Module Root CA with fingerprint F27BF02C6E00C73D915EEB6A6A2F5FBF0C31AE0393149E6B5C31E41B113841C3
GlobalSign Trusted Platform Module ECC Root CA with fingerprint 5A8C7B5EB888CFCE9322068E80E82B28B554FFEB7FDC9638DCB3763077401D26

Public Disclosure of Subordinate Issuing CA Certificates

Browser root programs require that all Subordinate CAs that are not technically constrained (using Name Constraints and Extended Key Usage Constraints)
are publicly disclosed. All “Active” Subordinate CA Certificates which chain directly or transiently to any Public Root certificate are listed in the Common CA
Database (CCADB). Retired CA Certificates that are not revoked are reported on a semi-annual basis to root programs via bugs or e-mails as required by theapplicable root program. Revoked Subordinate CA Certificates are also reported in the same manner, either shortly after revocation if routine or immediately
after for a security concern.
Certificates allow entities that participate in an electronic transaction to prove their identity to other participants or sign data digitally. By means of a Certificate,
GlobalSign provides confirmation of the relationship between a named entity (Subscriber) and its Public Key. The process to obtain a Certificate includes theidentification, naming, authentication, and registration of the Subscriber as well as aspects of Certificate management such as the issuance, revocation, andexpiration of the Certificate. By means of this procedure to issue Certificates, GlobalSign provides confirmation of the identity of the Subject of a Certificate bybinding the Public Key the Subscriber uses through the issuance of a Certificate. GlobalSign makes available Certificates that can be used for nonrepudiation/contentCommitment, encryption and authentication. The use of these Certificates can be further limited to a specific business or contractual context
or transaction level in support of a warranty policy or other limitations imposed by the applications in which Certificates are used.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

15 of 98

GlobalSign Certification Practice Statement

1.2

Document Name and Identification

This document is the GlobalSign Certification Practice Statement.
The OID for GlobalSign NV/SA (GlobalSign) is an iso (1) identified-organization (3) dod (6) internet(1) private (4) enterprise (1) GlobalSign (4146).
GlobalSign organizes its OID arcs for the various Certificates and documents described in this CPS
as follows:
Category

OID

Description

TLS

1.3.6.1.4.1.4146.10.1

TLS Policies Arc

1.3.6.1.4.1.4146.10.1.1

Extended Validation TLS Policy

1.3.6.1.4.1.4146.10.1.2

Organization Validation TLS Policy

1.3.6.1.4.1.4146.10.1.3

Domain Validation TLS Policy

1.3.6.1.4.1.4146.10.2

Authentication Policies Arc

1.3.6.1.4.1.4146.10.2.1

Extended Validation Auth Policy

1.3.6.1.4.1.4146.10.2.2

Organization Validation Auth Policy

1.3.6.1.4.1.4146.10.2.3

Domain Validation Auth Policy

1.3.6.1.4.1.4146.10.2.4

Individual Validation Auth Policy

1.3.6.1.4.1.4146.10.3

S/MIME Policies Arc

1.3.6.1.4.1.4146.10.3.1

Organization Validation S/MIME Policy

1.3.6.1.4.1.4146.10.3.2

Sponsored Validation S/MIME Policy

1.3.6.1.4.1.4146.10.3.3

Mailbox Validation S/MIME Policy

1.3.6.1.4.1.4146.10.3.4

Individual Validation S/MIME Policy

1.3.6.1.4.1.4146.1.40.70

Client Certificates Policy (Email Protection)

1.3.6.1.4.1.4146.10.4

Code Signing Policies Arc

1.3.6.1.4.1.4146.10.4.1

Extended Validation Code Signing Policy

1.3.6.1.4.1.4146.10.4.2

Organization Validation Code Signing Policy

1.3.6.1.4.1.4146.10.5

Document Signing Policies Arc

Authentication

S/MIME

Code Signing

Document
SigningGlobalSign CPS (Certification Practice Statement)
Version: 10.1

16 of 98

GlobalSign Certification Practice Statement

Category

OID

Description

Qualified

1.3.6.1.4.1.4146.1.40.36

eIDAS Qualified Certificates - QSCD

1.3.6.1.4.1.4146.1.40.36.1

Qualified Certificates for Electronic Signatures

Private key on QSCDManaged by Subscriber

1.3.6.1.4.1.4146.1.40.36.2

Qualified Certificates for Electronic Seals

Private key on QSCDManaged by Subscriber

1.3.6.1.4.1.4146.1.40.37

eIDAS Qualified Certificates – Non QSCD

1.3.6.1.4.1.4146.1.40.37.1

Qualified Certificates for Electronic Signatures

Private key not on QSCDManaged by Subscriber

1.3.6.1.4.1.4146.1.40.37.2

Qualified Certificates for Electronic Seals

Private key not on QSCDManaged by Subscriber

1.3.6.1.4.1.4146.1.40.37.3

Qualified Certificates for Electronic Seals - Open Banking

Private key not on QSCDManaged by Subscriber

1.3.6.1.4.1.4146.1.40.38

eIDAS Qualified Certificates – Remote QSCD

1.3.6.1.4.1.4146.1.40.38.1

Qualified Certificates for Electronic Signatures

Private key on QSCDManaged on behalf of Subscriber

1.3.6.1.4.1.4146.1.40.38.2

Qualified Certificates for Electronic Seals

Private key on QSCDManaged on behalf of Subscriber

1.3.6.1.4.1.4146.1.40.39

Qualified Certificates for Authentication

1.3.6.1.4.1.4146.1.40.39.1

Qualified Certificates for Authentication (Natural Persons)

1.3.6.1.4.1.4146.1.40.39.2

Qualified Certificates for Authentication (Legal Persons)

1.3.6.1.4.1.4146.1.40.39.3

Qualified Certificates for Website Authentication (QWAC)

1.3.6.1.4.1.4146.1.40.39.4

Qualified Certificates for Website Authentication (QWAC) – OpenBanking

1.3.6.1.4.1.4146.1.40.41

eIDAS Qualified Certificates – Remote Non QSCD

1.3.6.1.4.1.4146.1.40.41.1

Qualified Certificates for Electronic Signatures

Private key not on QSCDManaged on behalf of Subscriber

1.3.6.1.4.1.4146.1.40.41.2

Qualified Certificates for Electronic Seals

Private key not on QSCDManaged on behalf of Subscriber

1.3.6.1.4.1.4146.1.44.36

UK eIDAS Qualified Certificates – QSCD

1.3.6.1.4.1.4146.1.44.36.1

Qualified Certificates for Electronic Signatures

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

Private Key

Private key on QSCD

17 of 98

GlobalSign Certification Practice Statement

Category

OID

Description

Private Key
Managed by Subscriber
Private key on QSCDManaged by Subscriber

1.3.6.1.4.1.4146.1.44.36.2

Qualified Certificates for Electronic Seals

1.3.6.1.4.1.4146.1.44.37

UK eIDAS Qualified Certificates – Non QSCD

1.3.6.1.4.1.4146.1.44.37.1

Qualified Certificates for Electronic Signatures

Private key not on QSCDManaged by Subscriber

1.3.6.1.4.1.4146.1.44.37.2

Qualified Certificates for Electronic Seals

Private key not on QSCDManaged by Subscriber

1.3.6.1.4.1.4146.1.44.37.3

Qualified Certificates for Electronic Seals - Open Banking

Private key not on QSCDManaged by Subscriber

1.3.6.1.4.1.4146.1.44.38

UK eIDAS Qualified Certificates – Remote QSCD

1.3.6.1.4.1.4146.1.44.38.1

Qualified Certificates for Electronic Signatures

Private key on QSCDManaged on behalf of Subscriber

1.3.6.1.4.1.4146.1.44.38.2

Qualified Certificates for Electronic Seals

Private key on QSCDManaged on behalf of Subscriber

1.3.6.1.4.1.4146.1.44.39

UK Qualified Certificates for Authentication

1.3.6.1.4.1.4146.1.44.39.1

Qualified Certificates for Authentication (Natural Persons)

1.3.6.1.4.1.4146.1.44.39.2

Qualified Certificates for Authentication (Legal Persons)

1.3.6.1.4.1.4146.1.44.40

UK eIDAS Qualified Certificates for Website Authentication (QWAC)

1.3.6.1.4.1.4146.1.44.40.1

Qualified Certificates for Website Authentication (QWAC)

1.3.6.1.4.1.4146.1.44.40.2

Qualified Certificates for Website Authentication (QWAC) – OpenBanking

1.3.6.1.4.1.4146.1.44.41

UK eIDAS Qualified Certificates – Remote Non QSCD

1.3.6.1.4.1.4146.1.44.41.1

Qualified Certificates for Electronic Signatures

Private key not on QSCDManaged on behalf of Subscriber

1.3.6.1.4.1.4146.1.44.41.2

Qualified Certificates for Electronic Seals

Private key not on QSCDManaged on behalf of Subscriber

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

18 of 98

GlobalSign Certification Practice Statement

Category

OID

Description

Registration
Authorities

1.3.6.1.4.1.4146.1.45.1

LRA for Qualified Certificates

1.3.6.1.4.1.4146.1.45.2

External RA for Qualified CertificatesTimestamping

1.3.6.1.4.1.4146.1.30

Timestamping Certificates Policy

1.3.6.1.4.1.4146.1.31

Timestamping Certificates Policy – AATL

1.3.6.1.4.1.4146.1.32

Timestamping Certificate Policy – Certificates for Qualified Timestamping(QTS) under eIDAS regulation

1.3.6.1.4.1.4146.1.33

Timestamping Certificate Policy – Certificates for Qualified Timestamping(QTS) under UK eIDAS regulation

1.3.6.1.4.1.4146.1.34

Hosted Timestamping Certificates Policy

1.3.6.1.4.1.4146.1.35

Hosted Timestamping Certificates Policy – AATL

1.3.6.1.4.1.4146.2

Policy by which the timestamping services operated by GlobalSign
incorporates the time into IETF RFC 3161 responses

1.3.6.1.4.1.4146.2.2

Timestamping policy covering Timestamp Tokens (TST) issued under IETF
RFC 3161 with a Secure Hash Algorithm version 1 (SHA1)

1.3.6.1.4.1.4146.2.3

Timestamping policy covering Timestamp Tokens (TST) issued under IETF
RFC 3161 with a Secure Hash Algorithm version 2 (SHA2)

1.3.6.1.4.1.4146.2.3.1

Timestamping policy covering Timestamp Tokens (TST) issued under IETF
RFC 3161 with a Secure Hash Algorithm version 2 (SHA2) with R6 CA
hierarchy

1.3.6.1.4.1.4146.2.3.1.1

Trusted Timestamping policy covering Timestamp Tokens (TST) issued
under IETF RFC 3161 with a Secure Hash Algorithm version 2 (SHA2) withR6 CA hierarchy

1.3.6.1.4.1.4146.2.3.1.2

CodeSign Timestamping policy covering Timestamp Tokens (TST) issued
under IETF RFC 3161 with a Secure Hash Algorithm version 2 (SHA2) withR6 CA hierarchy

1.3.6.1.4.1.4146.2.4

Policy by which the time-stamping services operated by GlobalSign
incorporate the time into IETF RFC 3161 responses specifically for extended
validation code signing services

1.3.6.1.4.1.4146.2.6

JP Accredited Timestamping Tokens - AATL

1.3.6.1.4.1.4146.2.7

JP Accredited Timestamping Tokens - non-AATL

1.3.6.1.4.1.4146.1.40

Non-Generic use Certificates Policy

1.3.6.1.4.1.4146.1.40.20

Japan Certificate Authority Network (JCAN) Issuing CA Policy

1.3.6.1.4.1.4146.1.40.30

GlobalSign AATL Certificates Policy

1.3.6.1.4.1.4146.1.40.30.2

GlobalSign AATL Certificates Policy (Class 2)

1.3.6.1.4.1.4146.1.80

Retail Industry Electronic Data Interchange Client Certificate Policy

1.3.6.1.4.1.4146.1.81

Retail Industry Electronic Data Interchange Server Certificate Policy

1.3.6.1.4.1.4146.1.95

Online Certificate Status Protocol Policy

1.3.6.1.4.1.4146.3

GlobalSign's documents (such as Certificate Policy (CP) and Certification
Practice Statement (CPS))

1.3.6.1.4.1.4146.4

GlobalSign-specific certificate extensions Internet of Things (IoT)

1.3.6.1.4.1.4146.5

GlobalSign Time Assessment policies

1.3.6.1.4.1.4146.5.1

GlobalSign Japan Accredited Time Assessment Service Policy

1.3.6.1.4.1.4146.11.1

Private Hierarchy Certificate Policy Arc

1.3.6.1.4.1.4146.11.1.1

Shared Customer Certificates Arc

1.3.6.1.4.1.4146.11.1.1.1

IntranetSSL

1.3.6.1.4.1.4146.11.1.1.2

IntranetS/MIME

1.3.6.1.4.1.4146.11.1.1.3

Demo Certificates Policy – Should not be trusted as it may not containaccurate information. This is to be used for testing and integration purposes.

1.3.6.1.4.1.4146.11.1.2

GlobalSign Internal Certificates

Other Certificate
Policies

Private hierarchy

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

19 of 98

GlobalSign Certification Practice Statement

1.3.6.1.4.1.4146.11.1.3

Customer Branded Certificates

Legacy OIDs
The following OIDs are marked as legacy and where applicable are being replaced with a newhierarchy indicated in the table above.
Category

OID

Description

TLS

1.3.6.1.4.1.4146.1.1

Extended Validation Certificates Policy – SSL - Legacy

1.3.6.1.4.1.4146.1.1.1

Qualified Certificates under eIDAS Regulation – Qualified Web Authentication
Certificates (QWAC) - Legacy

1.3.6.1.4.1.4146.1.1.2

Qualified Certificates under eIDAS Regulation – Qualified Web Authentication
Certificates (QWAC) – Open Banking - Legacy

1.3.6.1.4.1.4146.1.2

Extended Validation Certificates Policy – Code Signing - Legacy

1.3.6.1.4.1.4146.1.10

Domain Validation Certificates Policy - Legacy

1.3.6.1.4.1.4146.1.10.10

Domain Validation Certificates Policy – AlphaSSL - Legacy

1.3.6.1.4.1.4146.1.20

Organization Validation Certificates Policy - Legacy

1.3.6.1.4.1.4146.1.25

IntranetSSL Validation Certificates Policy - Legacy

1.3.6.1.4.1.4146.1.40.35

eIDAS Qualified Certificates (Generic) - Legacy

1.3.6.1.4.1.4146.1.40.35.1

Qualified Certificates for Electronic Seals (Legal Persons with QSCD) managed by Subscriber - Legacy

1.3.6.1.4.1.4146.1.40.35.1.1

Qualified Certificates for Electronic Seals (Legal Persons) - Open Banking Legacy

1.3.6.1.4.1.4146.1.40.35.2

Qualified Certificates for Electronic Signatures (Natural Persons with QSCD) managed by Subscriber – Legacy

1.3.6.1.4.1.4146.40.40.1

Qualified Certificates for Website Authentication (QWAC) – Legacy

1.3.6.1.4.1.4146.40.40.2

Qualified Certificates for Website Authentication (QWAC) – Open Banking Legacy

1.3.6.1.4.1.4146.1.50

Code Signing Certificates Policy (Certificates issued by GlobalSign containing
1.3.6.1.4.1.4146.1.50 are issued and managed in accordance with the Baseline
Requirements for Code Signing)

Authentication

1.3.6.1.4.1.4146.1.40.60

Client Certificates Policy (Client Authentication)

Client Certificates

1.3.6.1.4.1.4146.1.40.10

Client Certificates Policy (EPKI – Enterprise PKI - Legacy)

1.3.6.1.4.1.4146.1.40.40

Client Certificates Policy (EPKI for private CAs - Legacy)

1.3.6.1.4.1.4146.1.40.50

Client Certificates Policy (Private Hierarchy - AEG - Legacy)

1.3.6.1.4.1.4146.1.26

Test Certificate Policy –Should not be trusted as it may not contain accurate
information. This is to be used for testing and integration purposes. (Legacy)

1.3.6.1.4.1.4146.1.70

High Volume CA Policy

1.3.6.1.4.1.4146.1.100

Internet of Things Device Certificates Policy (legacy)

Qualified

Code signing

OthersGlobalSign CPS (Certification Practice Statement)
Version: 10.1

20 of 98

GlobalSign Certification Practice Statement

Community OIDs
Certificates that comply with the applicable community requirements will include one of the following
additional identifiers.
Community

OID

Description

CA/Browser
Forum

2.23.140.1.1

Extended Validation Certificate Policy

2.23.140.1.2.1

Domain Validation Certificates Policy

2.23.140.1.2.2

Organization Validation Certificates Policy

2.23.140.1.3

EV Code Signing Certificates Policy

2.23.140.1.4.1

Code Signing Minimum Requirements Policy

2.23.140.1.4.2

Code Signing Minimum Requirements Timestamping Policy

2.23.140.1.5.1.1

S/MIME Mailbox-validated Legacy Certificate Policy

2.23.140.1.5.1.2

S/MIME Mailbox-validated Multipurpose Certificate Policy

2.23.140.1.5.1.3

S/MIME Mailbox-validated Strict Certificate Policy

2.23.140.1.5.2.1

S/MIME Organization-validated Legacy Certificate Policy

2.23.140.1.5.2.2

S/MIME Organization-validated Multipurpose Certificate Policy

2.23.140.1.5.2.3

S/MIME Organization-validated Strict Certificate Policy

2.23.140.1.5.3.1

S/MIME Sponsor-validated Legacy Certificate Policy

2.23.140.1.5.3.2

S/MIME Sponsor-validated Multipurpose Certificate Policy

2.23.140.1.5.3.3

S/MIME Sponsor-validated Strict Certificate Policy

2.23.140.1.5.4.1

S/MIME Individual-validated Legacy Certificate Policy

2.23.140.1.5.4.2

S/MIME Individual-validated Multipurpose Certificate Policy

2.23.140.1.5.4.3

S/MIME Individual-validated Strict Certificate Policy

0.4.0.194112.1.0

QCP-n: certificate policy for EU qualified Certificates issued to natural persons

0.4.0.194112.1.1

QCP-l: certificate policy for EU qualified Certificates issued to legal persons

0.4.0.194112.1.2

QCP-n-qscd: certificate policy for EU qualified Certificates issued to natural
persons with private key related to the certified public key in a QSCD

0.4.0.194112.1.3

QCP-l-qscd: certificate policy for EU qualified Certificates issued to legal
persons with private key related to the certified public key in a QSCD

0.4.0.194112.1.4

QCP-w: certificate for EU qualified website certificate issued to a natural or alegal person and linking the website to that person

2.16.840.1.114505.1.12.1.2

NAESB Rudimentary Assurance

2.16.840.1.114505.1.12.2.2

NAESB Basic Assurance

2.16.840.1.114505.1.12.3.2

NAESB Medium Assurance

ETSI

NAESB

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

21 of 98

GlobalSign Certification Practice Statement

1.3

PKI Participants

1.3.1

Certification Authorities

GlobalSign is a Certification Authority that issues Certificates in accordance with this CPS. As a
Certification Authority, GlobalSign performs functions related to Certificate lifecycle management
such as Subscriber registration, Certificate issuance, Certificate renewal, Certificate distribution
and Certificate revocation. GlobalSign also provides Certificate status information using a
Repository in the form of a Certificate Revocation List (CRL) distribution point and/or Online
Certificate Status Protocol (OCSP) responder. A Certification Authority may also be described by
the term “Issuing Authority” or “GlobalSign” to denote the purpose of issuing Certificates at therequest of a Registration Authority (RA) from a subordinate Issuing CA.
The GlobalSign PACOM1 - CA Governance Policy Authority, which is composed of members of
the GlobalSign management team and appointed by its Board of Directors, is responsible formaintaining this CPS relating to all Certificates in the GlobalSign hierarchy. Through its Policy
Authority, GlobalSign has ultimate control over the lifecycle and management of the GlobalSign
Root CA and any subsequent subordinate Issuing CAs belonging to the hierarchy.
GlobalSign is also a Timestamping Authority (TSA) and provides proof of existence of data at aparticular point in time. GlobalSign may outsource specific TSA services as necessary to allow for
additional independent verification of time related functions.
GlobalSign ensures the availability of all services pertaining to the management of Certificates
under the GlobalSign Roots, including without limitation the issuing, revocation, and statusverification of a Certificate, as they may become available or required in specific applications.
GlobalSign also manages a core online registration system and a number of APIs for all Certificate
types issued under GlobalSign Subordinate/Issuing CAs.
Some of the tasks associated with Certificate lifecycle are delegated to select GlobalSign RAs, who
operate on the basis of a service agreement with GlobalSign.
1.3.2

Registration Authorities

GlobalSign performs delegation in accordance with Section 1.3.2 of the GlobalSign CP.
GlobalSign may act as a Registration Authority for Certificates it issues in which case GlobalSign
is responsible for:
•
•
•
•
•
•

Accepting, evaluating, approving, or rejecting the registration of Certificate applications.
Registering Subscribers for certification services.
Providing systems to facilitate the identification of Subscribers (according to the type of
Certificate requested).
Using officially notarized or otherwise authorized documents or sources of information toevaluate and authenticate an Applicant’s application.
Requesting issuance of a Certificate via a multi-factor authentication process following theapproval of an application; andInitiating the process to revoke a Certificate from the applicable GlobalSign subordinate
Issuing CA or partner Subordinate CA.

In addition to identifying and authenticating Applicants for Certificates, a Registration Authority (RA)may also initiate or pass along revocation requests for Certificates and requests for renewal andre-key of Certificates.
RAs may implement more restrictive vetting practices if their internal policy dictates.
GlobalSign may also delegate the performance of all, or any part, of Section 3.2 requirements to a
Delegated Third Party, except for the following sections, provided that the process as a whole fulfills
all of the requirements of Section 3.2:

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

22 of 98

GlobalSign Certification Practice Statement

Certificate type

Section

TLS and EV TLS

3.2.7 (Authentication of Domain Names) and3.2.8 (Authentication of IP Addresses)

S/MIME

3.2.9 (Authentication of Email Addresses)

Before GlobalSign authorizes a Delegated Third Party to perform a delegated function, GlobalSign
will contractually require the Delegated Third Party to:
1. Meet the qualification requirements of Section 5.3.1, when applicable to the delegatedfunction;
2. Retain documentation in accordance with Section 5.5.2;
3. Abide by the other provisions of the applicable CA/Browser Forum Requirements that are
applicable to the delegated function; and4. Comply with (a) the CA's CP and/or CPS or (b) the Delegated Third Party's practicestatement that the CA has verified complies with the CA/Browser Forum Requirements
and other applicable requirements.
In the case of EPKI (Enterprise PKI) and MSSL (Managed SSL) RAs, Certificates are constrainedby a pre-defined and validated GlobalSign configuration.
To issue certain Certificate types, RAs may need to rely on Certificates issued by third party
Certification Authorities or other third-party databases and sources of information such as
government national identity cards such as passports, eID, and drivers’ licenses. Where the RA
relies on Certificates issued by a third party Certification Authority, RA must review the validation
practices of the third party and relying party obligations by referring to such third party’s CPS.
1.3.2.1

Enterprise Registration Authorities

GlobalSign may designate an Enterprise RA to verify Certificate requests from the Enterprise RA’s
own organization, in which case the Subscriber’s organization is validated, pre-defined andconstrained by system configuration.
GlobalSign may permit the use of Enterprise RA's, subject to the Enterprise RA's agreement with
GlobalSign and the requirements in Appendix A of this CPS.
GlobalSign imposes the limitations applicable to Enterprise Registration Authorities as a contractual
requirement on the Enterprise RA and monitors compliance by the Enterprise RA in accordancewith Section 8.8.
1.3.2.1.1 TLS Certificates
For TLS Certificates, GlobalSign will not accept Certificate requests authorized by an Enterprise
RA unless the following requirements are satisfied:
1. GlobalSign confirms that the requested Fully-Qualified Domain Name(s) are within theEnterprise RA's verified Domain Namespace.
2. If the Certificate request includes a Subject name of a type other than a Fully-Qualified
Domain Name, GlobalSign confirms that the name is either that of the delegated enterprise,or an Affiliate of the delegated enterprise, or that the delegated enterprise is an agent of
the named Subject.
1.3.2.1.2 Extended Validation Certificates
For Extended Validation TLS or Extended Validation Code Signing Certificates:
1. The Subscriber must be an organization verified by the CA in accordance with the EV
Guidelines.
2. GlobalSign shall not delegate the performance of the final cross-correlation and due
diligence requirements of Section 11.12 of the EV Guidelines.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

23 of 98

GlobalSign Certification Practice Statement

1.3.2.1.3 S/MIME BR Certificates
For S/MIME BR Certificates, GlobalSign will not accept Certificate requests authorized by anEnterprise RA unless the following requirements are satisfied:
1. If the Certificate request is for a Mailbox-validated, Organization-validated, or Sponsorvalidated profile, GlobalSign confirms that the Enterprise RA has authorization or controlof the requested email domain(s) in accordance with Section 3.2.2.1 or Section 3.2.2.3.
2. GlobalSign confirms that the subject:organizationName name is either that of thedelegated enterprise, or an Affiliate of the delegated enterprise, or that the delegatedenterprise is an agent of the named Subject.
An Enterprise RA may also submit Certificate requests using the Mailbox-validated profile for users
whose email domain(s) are not under the delegated organization’s authorization or control. In thiscase, GlobalSign confirms that the mailbox holder has control of the requested Mailbox Address(es)in accordance with Section 3.2.2.2.
1.3.2.2

Qualified Certificates

GlobalSign may delegate identity proofing and certificate lifecycle events to a third party acting as
a local or external Registration Authority. GlobalSign shall ensure adherence of RAs to theapplicable regulations, laws, industry standards and policies.
For both local and external RAs, a contract shall exist between GlobalSign and the RA for thedelegated activities, covering at least the following:• Obligation of the RA to abide by the relevant regulations, laws, industry standards andpolicies;• Allocation of liability between GlobalSign and the RA;• GlobalSign’s ability to revoke the delegation; and• GlobalSign’s ability to monitor the RA’s adherence to the relevant regulations, laws,
industry standards and policies by having the ability to perform audits.
1.3.2.2.1 Local RAs
Subjects
Identity proofing is limited to employees (natural persons) employed by the local RA, its parents,
subsidiaries or affiliated group organizations.
Delegated activities
Delegation to a local RA is limited to identity proofing and authentication of individual subjects
and certificate lifecycle events including certificate request and revocation.
Compliance
GlobalSign will apply appropriate measures to ensure adherence of the local RA to the applicableregulations, laws, industry standards and policies.
1.3.2.2.2 External RAs
Subjects
Subjects can be individuals (natural persons) and/or organizations (legal persons).
Delegated activities
Delegation may include identity proofing of the subscriber (and/or subject), authentication of therequest and certificate lifecycle events including request and revocation.
AuditsTo ensure compliance to the relevant regulations, laws, industry standards and policies, theexternal RA shall:••

Undergo audits as part of GlobalSign’s audits; orProvide an audit report from a Conformity Assessment Body or equivalent.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

24 of 98

GlobalSign Certification Practice Statement

1.3.3

Subscribers

Subscribers are either Legal Entities or natural persons that successfully apply for and receive a
Certificate to support their use in transactions, communications, and the application of Digital
Signatures.
A Subscriber, as used herein, refers to both the Subject of the Certificate and the entity that
contracted with GlobalSign for the Certificate’s issuance. Prior to verification of identity andissuance of a Certificate, a Subscriber is an Applicant.
Legal Entities are identified on the basis of review of the entity’s published by-laws and appointment
of director(s) as well as the subsequent government gazette or similar official government
publication or other Qualified Independent Information Source (QIIS) or Qualified Government
Information Source (QGIS) third party databases. Self-employed Subjects are identified based on
proof of professional registration supplied by the competent authority in the Country in which they
reside.
For all categories of Subscribers, additional credentials are required as explained in the online
process for the application for a Certificate.
Subscribers of end entity Certificates issued by GlobalSign include employees and agents involved
in day-to-day activities within GlobalSign that require access to GlobalSign network resources.
Subscribers are also sometimes operational or legal owners of signature creation devices that areissued for the purpose of generating a Key Pair and storing a Certificate.
It is expected that a Subscriber organization has a service agreement or other pre-existing
contractual relationship with GlobalSign authorizing it to carry out a specific function within thescope of an application that uses GlobalSign Certificate services. Issuance of a Certificate to a
Subscriber organization is only permitted pursuant to such an agreement between GlobalSign andthe subscribing end entity.
1.3.4

Relying Parties

To verify the validity of a Certificate, Relying Parties must always refer to GlobalSign’s revocation
information either in the form of a CRL distribution point or an OCSP responder.
1.3.5

Other Participants

Other participants include bridge CAs and CAs that cross certify Issuing CAs to provide trust among
other PKI communities.

1.4

Certificate Usage

A Certificate allows an entity taking part in an electronic transaction to prove its identity to otherparticipants in such transaction. Certificates are used in commercial environments as a digital
equivalent of an identification card.
1.4.1

Appropriate Certificate Usage

End entity Certificate use is restricted by the key usage and extended key usage values.
Certificates issued by GlobalSign can be used for public domain transactions that require:••••

Non-repudiation/contentCommitment A party cannot deny having engaged in thetransaction or having sent the electronic message.
Authentication The assurance to one entity that another entity is who he/she/it claims tobe.
Confidentiality (Privacy) The assurance to an entity that no one can read a particularpiece of data except the receiver(s) explicitly intended.
Integrity The assurance to an entity that data has not been altered (intentionally orunintentionally) from sender to recipient and from time of transmission to time of receipt.

Digital Signature: Digital (Electronic) Signature can only be used for specific transactions that
support digital signing of electronic forms, electronic documents, or electronic mail. A Certificate is
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

25 of 98

GlobalSign Certification Practice Statement

used to verify the Digital Signature made by the Private Key that matches the Public Key within theCertificate and therefore only in the context of applications that support Certificates. Certificate
types that are appropriate for Digital Signatures are the following:• PersonalSign 2 Non-repudiation/contentCommitment of a transaction (medium levelassurance)• PersonalSign 2 Pro Non-repudiation/contentCommitment of the transaction by a party
acting in an organizational context (medium level assurance)• AATL Non-repudiation/contentCommitment of the transaction by a party acting in an
organizational context (medium hardware level assurance). (It is not recommended that
the Certificate be used for encryption due to the singularity of the Certificate)• Qualified Certificates Non-repudiation/contentCommitment of signatures by Individuals(Qualified Certificates for Electronic Signatures) and legal persons (Qualified Certificatesfor Electronic Seals)
Authentication (Users): User authentication Certificates can be used for specific electronic
authentication transactions that support accessing web sites and other online content, electronic
mail, etc. The authentication function of a Certificate is often the result of a combination of tests on
specific properties of the Certificate such as the identity of the Subscriber bound to the Public Key.
To describe the function of authentication, the term Digital Signature is often used as this is themethod by which the Subscriber can provide a proof of ownership of the Private Key that matches
the Public Key within the Certificate.
•
•
•
•
•

•

PersonalSign 2 Authentication of a natural person (medium level assurance) and theexistence of an email address
PersonalSign 2 Pro Authentication of a natural person within an organizational context
or a machine, device, department, or role within an organizational context (medium levelassurance) and optionally the existence of an email address
PersonalSign 3 Pro Authentication of a natural person within an organizational context(high level assurance)
NAESB Rudimentary Authentication as prescribed in NIST SP800-63A Digital Identity
Guidelines: Enrollment and Identity Proofing, Section 4.3 “Identity Proofing Assurance
Level I.
NAESB Basic Authentication as prescribed in the Baseline Requirements for TLS. Section
3.2.3 Authentication of Individual Identity: Employers who verified the identity of theirapplicants by means comparable to those stated above for Basic Level may elect tobecome an LRA and perform identity proofing of applicants either in-person by inspectionof its corporate issued photo ID or through the LRA’s secure online process. The corporate
issued photo ID or online process should originate with a government issued photo ID.
NAESB Medium Authentication as prescribed in EV Guidelines. Chapter 11.2.2:
Acceptable Method of Verification (4) Principal Individual

Authentication (Devices and Objects): Device authentication Certificates can be used forspecific electronic authentication transactions that support the identification of web sites and other
online resources, such as software objects. The authentication function of a Certificate is often the
result of a combination of tests on specific properties of the Certificate such as the identity of thedevice (web server) bound to the Public Key. To describe the function of authentication, the term
Digital Signature is often used as this is the method by which, for example, a web server can provide
a proof of ownership of the Private Key that matches the Public Key within the Certificate for the
Domain Name within the Certificate.
•
•
•
•
•

DomainSSL Authentication of a remote Domain Name and webservice and encryption of
the communication channel
AlphaSSL Authentication of a remote Domain Name and webservice and encryption of
the communication channel
OrganizationSSL
Authentication of a remote Domain Name and associatedorganizational context and webservice and encryption of the communication channel
Extended Validation SSL Authentication of a remote domain name and associatedorganizational context and webservice and encryption of the communication channel
Code Signing Authentication of a data object with a legal person or a Legal Entity

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

26 of 98

GlobalSign Certification Practice Statement

•
•
•
•
•
•

EV Code Signing Authentication of a data object with a legal person or a Legal Entity
Timestamping Authentication of a time and date related to a service within an
organizational context
PersonalSign (All) Authentication of device or machine associated with an organization
NAESB Rudimentary Authentication as prescribed in NIST SP800-63 A Digital Identity
Guidelines: Enrollment and Identity Proofing, Section 4.3 “Identity Proofing Assurance
Level I.
NAESB Basic Authentication as prescribed in the Baseline Requirements for TLS. Section
3.2.3 Authentication of Individual Identity.
NAESB Medium Authentication as prescribed in the EV Guidelines. Chapter 11.2.2:
Acceptable Method of Verification (4) Principal Individual

Assurance Levels: Subscribers should choose an appropriate level of assurance in their identitythat they wish to present to Relying Parties. For example, Subscribers with an unknown brandname should positively assure Relying Parties of their identity with an EV Certificate, whereas aclosed community with a well-known URL or specific server to server transactions may choose a
low assurance level.
•
•
•
•
•

•

•

Low assurance (Class 1) Certificates are not suitable for identity verification as noauthenticated identity information is included within the Certificate. These Certificates do
not support non-repudiation/contentCommitment.
Medium assurance (Class 2) Certificates are individual and organizational Certificatesthat are suitable for securing moderately risky inter and, intra-organizational, andcommercial transactions.
High assurance (Class 3) Certificates are individual and organizational Certificates thatprovide a high level of assurance of the identity of the Subject as compared to Class 1 and
2.
High assurance (EV) Extended Validation Certificates are Class 3 Certificates issued by
GlobalSign in conformance with the EV Guidelines.
NAESB Rudimentary This level provides the lowest degree of assurance. One of the
primary functions of this level is to provide data integrity of the information being signed.
This level is appropriate for environments in which the risk of malicious activity is
considered to be low. It is not suitable for transactions requiring authentication, and isgenerally insufficient for transactions requiring confidentiality, but may be used for the latter
where Certificates having higher levels of assurance are unavailable.
NAESB Basic This level provides a basic level of assurance appropriate for environments
where there are risks and consequences of data Compromise, but they are not considered
to be of major significance. This may include access to private information where thelikelihood of malicious access is not high. It is assumed at this assurance level that users
are not likely to be malicious.
NAESB Medium This level is appropriate for environments where risks and consequencesof data compromise are moderate. This may include transactions having substantial
monetary value or risk of fraud or involving access to private information where thelikelihood of malicious access is substantial.

Confidentiality: All Certificate types, with the exception of timestamping and code signing
Certificates, can be used to ensure the confidentiality of communications effected by means ofCertificates. Confidentiality may apply to business and personal communications as well as
personal data protection and privacy.
Certificates issued under the NAESB PKI may be used for transactions under the WEQ-001, WEQ002, WEQ-003, WEQ-004, and WEQ-005 business practice standards. They may be used for othertransactions by mutual agreement of the parties. Certificates issued under the NAESB Wholesale
Electric Quadrant Business Practice Standards WEQ-012 (“NAESB WEQ PKI Standards”) should
never be used for performing either of the following functions:••

Any transaction or data transfer that may result in imprisonment if Compromised or falsified;and
Any transaction or data transfer deemed illegal under federal law

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

27 of 98

GlobalSign Certification Practice Statement

Any other use of a Certificate is not supported by this CPS: When using a Certificate, thefunctions of electronic signature (non-repudiation/contentCommitment) and authentication (Digital
Signature) are permitted together within the same Certificate. The different terms relate to different
terminologies used by IETF and the vocabulary adopted within the legal framework of the European
Union Directive 1999/93/EC (a Community framework on electronic signatures), eIDAS Regulation(Regulation (EU)N910/2014) (“eIDAS”) or eIDAS (UK Legislation) and The Electronic Identification
and Trust Services for Electronic Transactions Regulations 2016 (“UK eIDAS”).
1.4.2

Prohibited Certificate usage

Certificate use is restricted by using Certificate extensions on key usage and extended key usage.
Any usage of the Certificate inconsistent with these extensions is not authorized. Certificates are
not authorized for use for any transactions above the designated reliance limits that have been
indicated in the GlobalSign Warranty Policy.
Certificates issued under this CPS do not guarantee that the Subject is trustworthy, operating a
reputable business or that the equipment on which the Certificate has been installed is not freefrom defect, malware, or virus. In the case of code signing, Certificates do not guarantee that signed
code is free from bugs or vulnerabilities.
Certificates issued under this CPS may not be used:
•
•
•
•
•

1.5
1.5.1

For any application requiring fail safe performance
For any application or mechanism where issues with the certificate could cause a safety
risk (e.g., human or environmental risk)
Where prohibited by law
Qualified Certificates for Electronic Signatures should only be used by natural persons
whereas Certificates for Electronic Seals should only be used by legal persons
Certificates issued under the NAESB WEQ PKI shall never be used for performing eitherof the following functions:o Any transaction or data transfer that may result in imprisonment if compromised or
falsified.
o Any transaction or data transfer deemed illegal under federal law

Policy Administration
Organization Administering the Document

Requests for information on the compliance of Issuing CAs with accreditation schemes as well as
any other inquiry associated with this CPS should be addressed to:
PACOM1 – CA Governance GlobalSign
Diestsevest 14,
3000 Leuven, Belgium
Tel: + 32 (0)16 891900
Fax: + 32 (0) 16 891909
Email: policy-authority@globalsign.com
1.5.2

Contact Person

General Inquiries
GlobalSign NV/SA
attn. Legal Practices,
Diestsevest 14,
3000 Leuven, Belgium
Tel: + 32 (0)16 891900
Fax: + 32 (0) 16 891909
Email: legal@globalsign.com
URL: www.globalsign.com
Certificate Problem Report

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

28 of 98

GlobalSign Certification Practice Statement

Anti-Malware Organizations, Subscribers, Relying Parties, Application Software Suppliers, andother third parties may report suspected Private Key Compromise, Certificate misuse, Certificatesused to sign Suspect Code, Takeover Attacks, or other types of fraud, compromise, misuse,inappropriate conduct, or any other matter related to Certificates by sending email to:report-abuse@globalsign.com
GlobalSign may or may not revoke in response to this request. See section 4.9.5 for detail of actions
performed by GlobalSign for making this decision.
1.5.3

Person Determining CPS Suitability for the Policy

PACOM1 – CA Governance determines the suitability and applicability of the CP and theconformance of this CPS based on the results and recommendations received from a Qualified
Auditor.
In an effort to maintain credibility and promote trust in this CPS and better correspond toaccreditation and legal requirements, the PACOM1 – CA Governance shall review this CPS at least
annually and may make revisions and updates to policies as it sees fit or as required by othercircumstances. Any updates become binding for all Certificates that have been issued or are to beissued upon the date of the publication of the updated version of this CPS.
1.5.4

CPS Approval Procedures

PACOM1 – CA Governance reviews and approves any changes to the CPS. The updated CPS isreviewed against the CP in order to check for consistency. CP changes are also added on an asneeded basis. Upon approval of a CPS update by PACOM1 – CA Governance, the new CPS is
published in the GlobalSign Repository at https://www.globalsign.com/repository.
The updated version is binding upon all Subscribers including the Subscribers and parties relying
on Certificates that have been issued under a previous version of the CPS.

1.6

Definitions and Acronyms

Any terms used but not defined herein shall have the meaning ascribed to them in the CA/Browser
Forum Requirements and eIDAS regulations.
Adobe Approved Trust List (AATL): A document signing certificate authority trust store createdby the Adobe Root CA policy authority implemented from Adobe PDF Reader version 9.0
Affiliate: A corporation, partnership, joint venture, or other entity controlling, controlled by, or undercommon control with another entity, or an agency, department, political subdivision, or any entity
operating under the direct control of a Government Entity.
Anti‐Malware Organization: An entity that maintains information about Suspect Code and/or
develops software used to prevent, detect, or remove malware.
Applicant: The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate.
Once the Certificate issues, the Applicant is referred to as the Subscriber. For Certificates issued
to devices, the Applicant is the entity that controls or operates the device named in the Certificate,even if the device is sending the actual Certificate request.
Application Software Supplier: A supplier of Internet browser software or other Relying Party
application software that displays or uses Certificates and incorporates Root Certificates.
Attestation Letter: A letter attesting that Subject Identity Information is correct.
Authorization Domain Name: The FQDN used to obtain authorization for a given FQDN to be
included in a Certificate. The CA may use the FQDN returned from a DNS CNAME lookup as the
FQDN for the purposes of domain validation. If a Wildcard Domain Name is to be included in a
Certificate, then the CA must remove “*.” from the left‐most portion of the Wildcard Domain
Name to yield the corresponding FQDN. The CA may prune zero or more Domain Labels of the
FQDN from left to right until encountering a Base Domain Name and may use any one of the
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

29 of 98

GlobalSign Certification Practice Statement

values that were yielded by pruning (including the Base Domain Name itself) for the purpose of
domain validation.
Authorized Certification Authority: A Certification Authority that complies with all provisions of
the North American Energy Standards Board (NAESB) Business Practice Standard for Public Key
Infrastructure (PKI) – WEQ-012.
Base Domain Name: The portion of an applied‐for FQDN that is the first Domain Name node leftof a registry‐controlled or public suffix plus the registry‐controlled or public suffix (e.g.
“example.co.uk” or “example.com”). For FQDNs where the right‐most Domain Name node is agTLD having ICANN Specification 13 in its registry agreement, the gTLD itself may be used as theBase Domain Name.
Business Entity: Any entity that is not a Private Organization, Government Entity, or noncommercial entity as defined in the EV Guidelines. Examples include, but are not limited to, generalpartnerships, unincorporated associations, sole proprietorships, etc.
CA/Browser Forum Requirements: The following set of documents published by CA/Browser
Forum covering requirements for issuance and management of Certificates: CA/Browser Forum
Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates,
CA/Browser Forum Guidelines For The Issuance And Management Of Extended Validation
Certificates, CA/Browser Forum Network and Certificate System Security Requirements,
CA/Browser Forum Baseline Requirements for Code Signing, CA/Browser Forum Baseline
Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates.
Certificate: An electronic document that uses a Digital Signature to bind a Public Key and an
identity.
Certificate Authority Authorization (CAA): The CAA record is used to specify which Certificate
Authorities are allowed to issue Certificates for a domain.
Certificate Beneficiaries: The Subscriber that is a party to the Subscriber Agreement or Terms of
Use for the Certificate, all Application Software Suppliers with whom GlobalSign has entered into acontract for inclusion of its Root Certificate in software distributed by such Application Software
Supplier, and all Relying Parties who reasonably rely on a Valid Certificate.
Certificate Data: Certificate requests and data related thereto (whether obtained from theApplicant or otherwise) in the CA’s possession or control or to which the CA has access.
Certificate Management Process: Processes, practices, and procedures associated with the useof keys, software, and hardware, by which the CA verifies Certificate Data, issues Certificates,
maintains a Repository, and revokes Certificates.
Certificate Policy: A set of rules that indicates the applicability of a named Certificate to aparticular community and/or PKI implementation with common security requirements.
Certificate Problem Report: A complaint of suspected Key Compromise, Certificate misuse, orother types of fraud, compromise, misuse, or inappropriate conduct related to Certificates.
Certificate Revocation List: A regularly updated timestamped list of revoked Certificates that iscreated and digitally signed by the CA that issued the Certificates.
Certificate Authority: An organization that is responsible for the creation, issuance, revocation,and management of Certificates. The term applies equally to both Roots CAs and Subordinate CAs.
Certification Practice Statement: One of several documents forming the governance frameworkin which Certificates are created, issued, managed, and used.
Common CA Database (CCADB): A certificate repository run by Mozilla, where all publicly trusted
root and issuing Certificates are listed.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

30 of 98

GlobalSign Certification Practice Statement

Compromise: A violation of a security policy that results in loss of control over sensitive
information.
Conformity Assessment Body: A body defined in point 13 of Article 2 of Regulation (EC) No
765/2008, which is accredited in accordance with that Regulation as competent to carry out
conformity assessment of a qualified trust service provider and the qualified trust services it
providesCountry: Either a member of the United Nations OR a geographic region recognized as asovereign nation by at least two UN member nations.
Cross Certificate: A Certificate that is used to establish a trust relationship between two RootCAs.
DCF77: A German longwave time signal and standard-frequency radio station.
Digital Signature: To encode a message by using an asymmetric cryptosystem and a hashfunction such that a person having the initial message and the signer’s Public Key can accurately
determine whether the transformation was created using the Private Key that corresponds to thesigner’s Public Key and whether the initial message has been altered since the transformation wasmade.
DNS CAA Email Contact:
Requirements for TLS.

The email address defined in Appendix B.1.1. of the Baseline

DNS TXT Record Email Contact: The email address defined in Appendix B.2.1. of the Baseline
Requirements for TLS.
DNS TXT Record Phone Contact: The phone number defined in Appendix B.2.2. of the Baseline
Requirements for TLS.
Domain Contact: The Domain Name Registrant, technical contact, or administrative contract (orthe equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a
DNS SOA record, or as obtained through direct contact with the Domain Name Registrar.
Domain Label: From RFC 8499 (http://tools.ietf.org/html/rfc8499): “An ordered list of zero or more
octets that makes up a portion of a domain name. Using graph theory, a label identifies one node
in a portion of the graph of all possible domain names.”
Domain Name: An ordered list of one or more Domain Labels assigned to a node in the Domain
Name System.
Domain Name System: An Internet service that translates Domain Names into IP addresses.
Domain Namespace: The set of all possible Domain Names that are subordinate to a single nodein the Domain Name System.
Domain Name Registrant: Sometimes referred to as the “owner” of a Domain Name, but more
properly the person(s) or entity(ies) registered with a Domain Name Registrar as having the rightto control how a Domain Name is used, such as the natural person or Legal Entity that is listed as
the “Registrant” by WHOIS or the Domain Name Registrar.
Domain Name Registrar: A person or entity that registers Domain Names under the auspices ofor by agreement with: (i) the Internet Corporation for Assigned Names and Numbers (ICANN), (ii)a national Domain Name authority/registry, or (iii) a Network Information Center (including theiraffiliates, contractors, delegates, successors, or assigns).
eIDAS Regulation (“eIDAS”): REGULATION (EU) No 910/2014 OF THE EUROPEANPARLIAMENT AND OF THE COUNCIL of 23 July 2014 on electronic identification and trust
services for electronic transactions in the internal market and repealing Directive 1999/93/EC.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

31 of 98

GlobalSign Certification Practice Statement

Electronic Seal: Data in electronic form, which is attached to or logically associated with otherdata in electronic form to ensure the latter’s origin and integrity.
Electronic Signature: Data in electronic form which is attached to or logically associated with otherdata in electronic form, and which is used by the signatory to sign
Enterprise PKI (EPKI): A GlobalSign product for organizations to manage the full lifecycle ofMicrosoft Windows trusted digital IDs, Adobe Approved Trust List, including issuing, reissuing,
renewing, and revoking.
Enterprise RA: An employee or agent of an organization unaffiliated with the CA who authorizes
issuance of Certificates to that organization or its subsidiaries. An Enterprise RA may also authorize
issuance of client authentication Certificates to partners, customers, or affiliates wishing to interact
with that organization.
Expiry Date: The “Not After” date in a Certificate that defines the end of a Certificate’s Validity
Period.
Fully-Qualified Domain Name: A Domain Name that includes the Domain Labels of all
superior nodes in the Internet Domain Name System
GlobalSign Certificate Center (GCC): A cloud-based Certificate management system throughwhich customers and partners may purchase and manage Certificates from GlobalSign.
Global Positioning System (GPS): A U.S.-owned utility that provides users with positioning,navigation, and timing (PNT) services.
Governmentally Accepted Form of ID: A physical or electronic form of ID issued by the local
country/state government, or a form of ID that the local government accepts for validating identities
of individuals for its own official purposes.
Government Entity: A government-operated legal entity, agency, department, ministry, branch,or similar element of the government of a Country, or political subdivision within such Country (suchas a state, province, city, county, etc.).
Hash (e.g., SHA1 or SHA256): An algorithm that maps or translates one set of bits into another(generally smaller) set in such a way that:• A message yields the same result every time the algorithm is executed using the samemessage as input.
• It is computationally infeasible for a message to be derived or reconstituted from the result
produced by the algorithm.
• It is computationally infeasible to find two different messages that produce the same hashresult using the same algorithm.
Hardware Security Module (HSM): A type of secure crypto processor targeted at managing digitalkeys, accelerating crypto processes in terms of digital signings/second and for providing strong
authentication to access critical keys for server applications.
Incorporate by Reference: To make one document a part of another by identifying the document
to be incorporated, with information that allows the recipient to access and obtain the incorporated
message in its entirety, and by expressing the intention that it be part of the incorporating message.
Such an incorporated message shall have the same effect as if it had been fully stated in themessage.
Incorporating Agency: In the context of a Private Organization, the government agency in the
Jurisdiction of Incorporation under whose authority the legal existence of the entity is registered(e.g., the government agency that issues certificates of formation or incorporation). In the context
of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal
existence of Government Entities.
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

32 of 98

GlobalSign Certification Practice Statement

Individual: A natural person.
Internal Name: A string of characters (not an IP address) in a Common Name or Subject
Alternative Name field of a Certificate that cannot be verified as globally unique within the public
DNS at the time of certificate issuance because it does not end with a Top Level Domain registeredin IANA’s Root Zone Database.
Internationalized Domain Name (IDN): An internet domain name containing at least one
language-specific script or alphabetic character which is then encoded in punycode for use in DNS
which accepts only ASCII strings.
IP Address: A 32-bit or 128-bit number assigned to a device that uses the Internet Protocol forcommunication.
IP Address Contact: The person(s) or entity(ies) registered with an IP Address Registration
Authority as having the right to control how one or more IP Addresses are used.
IP Address Registration Authority: The Internet Assigned Numbers Authority (IANA) or a
Regional Internet Registry (RIPE, APNIC, ARIN, AfriNIC, LACNIC).
Issuing CA: In relation to a particular Certificate, the CA that issued the Certificate. This could beeither a Root CA or a Subordinate CA.
Jurisdiction of Incorporation: In the context of a Private Organization, the country and (whereapplicable) the state or province or locality where the organization’s legal existence was establishedby a filing with (or an act of) an appropriate government agency or entity (e.g., where it wasincorporated). In the context of a Government Entity, the country and (where applicable) the stateor province where the Entity’s legal existence was created by law.
Key Compromise: A Private Key is said to be Compromised if its value has been disclosed to an
unauthorized person, an unauthorized person has had access to it, or there exists a practicaltechnique by which an unauthorized person may discover its value.
Key Pair: The Private Key and its associated Public Key.
Legal Entity: An association, corporation, partnership, proprietorship, trust, government entity orother entity with legal standing in a country’s legal system.
North American Energy Standards Board (NAESB) Accreditation Requirements for
Authorized Certification Authorities (“NAESB Accreditation Specification”): The technicaland management details which a Certification Authority is required to meet in order to be accredited
as an Authorized Certification Authority (ACA) by NAESB.
NAESB Business Practice Standards for Public Key Infrastructure (PKI) – WEQ-012(“NAESB Business Practice Standards”): Defines the minimum requirements that must be met
by Certification Authorities, the Certificates issued by those Certification Authorities and end entities
that use those Certificates in order to comply with NAESB PKI standards.
Network Time Protocol (NTP): A networking protocol for clock synchronization between
computer systems over packet-switched, variable-latency data networks.
Object Identifier (OID): A unique alphanumeric or numeric identifier registered under theInternational Organization for Standardization’s applicable standard for a specific object or object
class.
OCSP Responder: An online server operated under the authority of the CA and connected to its
Repository for processing Certificate status requests. See also, Online Certificate Status Protocol.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

33 of 98

GlobalSign Certification Practice Statement

Online Certificate Status Protocol: An online Certificate-checking protocol that enables Relying
Party application software to determine the status of an identified Certificate. See also OCSP
Responder.
Open Banking Certificate: A Qualified Certificate that includes Open Banking Specific Attributes.
Open Banking Specific Attributes: Attributes that are specific to Open Banking Certificates whichare:• authorization number if it is issued by the NCA, or registration number recognized onnational or European level or Legal Entity Identifier included in the register of credit
institutions.
• role or roles of PSP.
• NCA name (NCAName) and unique identifier (NCAId).
Payment Services Directive (PSD2): European Union Directive (EU) 2015/2366 that regulates
payment services and payment service providers throughout the European Union and European
Economic Area.
Place of Business: The location of any facility (such as a factory, retail store, warehouse, etc.)
where the Applicant’s business is conducted.
Private Key: The key of a Key Pair that is kept secret by the holder of the Key Pair, and that isused to create Digital Signatures and/or to decrypt electronic records or files that were encryptedwith the corresponding Public Key.
Private Organization: A non-governmental legal entity (whether ownership interests are privately
held or publicly traded) whose existence was created by a filing with (or an act of) the Incorporating
Agency or equivalent in its Jurisdiction of Incorporation.
Public Key: The key of a Key Pair that may be publicly disclosed by the holder of thecorresponding Private Key and that is used by a Relying Party to verify Digital Signatures createdwith the holder's corresponding Private Key and/or to encrypt messages so that they can bedecrypted only with the holder's corresponding Private Key.
Public Key Infrastructure (PKI): A set of hardware, software, people, procedures, rules, policies,
and obligations used to facilitate the trustworthy creation, issuance, management, and use of
Certificates and keys based on Public Key cryptography.
Publicly-Trusted Certificate: A Certificate that is trusted by virtue of the fact that its corresponding
Root Certificate is distributed as a trust anchor in widely available application software.
Pseudonym: A fictitious identity that a person assumes for a particular purpose. Unlike ananonymous identity, a pseudonym can be linked to an Individual's real identity.
Qualified Auditor: A natural person or Legal Entity that meets the requirements of Section 8.2(Identity/ Qualifications of Assessor).
Qualified Certificate: A Certificate that meets the qualification requirements defined by theeIDAS/UK eIDAS Regulation.
Qualified Certificate for Electronic Seals: A Certificate for Electronic Seals, that is issued by aqualified trust service provider and meets the requirements laid down in Annex III of eIDAS/UK
eIDAS Regulation.
Qualified Certificate for Electronic Signature: A Certificate for Electronic signatures, that isissued by a qualified trust service provider and meets the requirements laid down in Annex I ofeIDAS/UK eIDAS Regulation.
Qualified Electronic Seals: An advanced Electronic Seal, which is created by a Qualified
Electronic Seal Creation Device, and that is based on a Qualified Certificate for Electronic Seal.
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

34 of 98

GlobalSign Certification Practice Statement

Qualified Electronic Signature: An advanced Electronic Signature that is created by a Qualified
Electronic Signature Creation Device, and which is based on a Qualified Certificate for Electronic
Signatures.
Qualified Government Information Source: A database maintained by a Government Entity.
Qualified Government Tax Information Source: A Qualified Governmental Information Sourcethat specifically contains tax information relating to Private Organizations, Business Entities, orIndividuals.
Qualified Independent Information Source: A regularly updated and current, publicly available,
database designed for the purpose of accurately providing the information for which it is consulted,
and which is generally recognized as a dependable source of such information.
Qualified Electronic Signature/Seal Creation Device (QSCD): An electronic signature/seal
creation device that meets the requirements as stipulated within Annex II of eIDAS Regulation.
Qualified Timestamping (QTS): The provisioning of timestamps that comply with Article 42 of theeIDAS/UK eIDAS Regulation.
Qualified Trust Service Provider (QTSP): A natural or a legal person who provides one or moretrust services and is granted the qualified status by the supervisory body as defined within theeIDAS/UK eIDAS regulation.
Qualified Web Authentication Certificates (QWAC): A qualified SSL Certificate that meets therequirements of Article 45 of the eIDAS/UK eIDAS Regulation.
Registered Domain Name: A Domain Name that has been registered with a Domain Name
Registrar.
Registration Authority (RA): Any Legal Entity that is responsible for identification andauthentication of Subjects of Certificates, but is not a CA, and hence does not sign or issue
Certificates. An RA may assist in the Certificate application process or revocation process or both.
When “RA” is used as an adjective to describe a role or function, it does not necessarily imply aseparate body, but can be part of the CA.
Relying Party: Any natural person or Legal Entity that relies on a Valid Certificate. An Application
Software Supplier is not considered a Relying Party when software distributed by such supplier
merely displays information relating to a Certificate.
Reserved IP Address: An IPv4 or IPv6 address that is contained in the address block ofany entry in either of the following IANA registries:
https://www.iana.org/assignments/iana‐ipv4‐special‐registry/iana‐ipv4‐special‐registry.xhtml
https://www.iana.org/assignments/iana‐ipv6‐special‐registry/iana‐ipv6‐special‐registry.xhtml
Repository: An online database containing publicly disclosed PKI governance documents (suchas Certificate Policies and Certification Practice Statements) and Certificate status information,either in the form of a CRL or an OCSP response.
Root CA: The top-level Certification Authority whose Root Certificate is distributed by Application
Software Suppliers and that issues Subordinate CA Certificates.
Root Certificate: The self-signed Certificate issued by the Root CA to identify itself and to facilitate
verification of Certificates issued to its Subordinate CAs.
S/MIME Certificate: Certificate intended to be used to sign, verify, encrypt, and decrypt email.
Certificate with Extended Key Usage (EKU) for id-kp-emailProtection (OID: 1.3.6.1.5.5.7.3.4) andGlobalSign CPS (Certification Practice Statement)
Version: 10.1

35 of 98

GlobalSign Certification Practice Statement

the inclusion of a rfc822Name or an otherName of type id-on-SmtpUTF8Mailbox in thesubjectAltName extension.
S/MIME BR Certificate: S/MIME Certificate following the Baseline Requirements for S/MIME
policy.
SSL Certificate: Certificates intended to be used for authenticating servers accessible throughthe Internet.
Subject: The natural person, device, system, unit, or Legal Entity identified in a Certificate as the
Subject. If the Subject is a device or system, it must be under the control and operation of the
Subscriber.
Subject Identity Information: Information that identifies the Certificate Subject. Subject Identity
Information does not include a Domain Name listed in the subjectAltName extension or thecommonName field.
Subordinate CA: A Certification Authority whose Certificate is signed by the Root CA, or another
Subordinate CA.
Subscriber: A natural person or Legal Entity to whom a Certificate is issued and who is legallybound by a Subscriber Agreement or Terms of Use.
Subscriber Agreement: An agreement between the CA and the Applicant/Subscriber thatspecifies the rights and responsibilities of the parties.
Supervisory Body: A body responsible for the task of supervising the qualified trust service
providers established in the territory of the Member State and to take action, if necessary, in relation
to non-qualified trust service providers established in the territory of the Member State. Details aredescribed in eIDAS Article 17.
Takeover Attack: An attack where a Signing Service or Private Key associated with a CodeSigning Certificate has been compromised by means of fraud, theft, intentional malicious act of
the Subject’s agent, or other illegal conduct.
Technically Constrained Subordinate CA Certificate: A Subordinate CA certificate which uses
a combination of Extended Key Usage settings and Name Constraint settings to limit the scope
within which the Subordinate CA may issue Subscriber or additional Subordinate CA Certificates.
Terms of Use: Provisions regarding the safekeeping and acceptable uses of a Certificate issuedin accordance with the CA/Browser Forum Requirements when the Applicant/Subscriber is an
Affiliate of the CA.
Third Party Validator: An individual or a legal entity that is competent and authorized to perform
any of the following actions in accordance with national law: 1. to render an opinion on factual
claims about the Applicant, including the verification of any specific attributes of the natural or legal
person, 2. to authenticate the execution of a signature on a document. Examples may include public
officials, notaries, chartered professional accountants, or lawyers.
Trusted Platform Module (TPM): A hardware cryptographic device which is defined by the Trusted
Computing Group. https://www.trustedcomputinggroup.org/specs/TPM.
Trusted Third Party: A service provider with a secure process used for individual identity
verification based on Governmentally Accepted Form(s) of ID, or whose service itself is considered
to generate a Governmentally Acceptable Form of ID.
Trustworthy System: Computer hardware, software, and procedures that are: reasonably securefrom intrusion and misuse; provide a reasonable level of availability, reliability, and correct
operation; are reasonably suited to performing their intended functions; and enforce the applicablesecurity policy.
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

36 of 98

GlobalSign Certification Practice Statement

UK eIDAS ("UK eIDAS"): eIDAS (UK Legislation) and The Electronic Identification and Trust
Services for Electronic Transactions Regulations 2016.
Valid Certificate: A Certificate that passes the validation procedure specified in RFC 5280.
Validation Specialist: Someone who performs the information verification duties specified by thisCPS.
Validity Period: The period of time measured from the date when the Certificate is issued until the
Expiry Date.
WebTrust Program for CAs: The then-current version of the AICPA/CICA WebTrust Program for
Certification Authorities.
WebTrust Seal of Assurance: An affirmation of compliance resulting from the WebTrust Programfor CAs.
Wildcard Certificate: A Certificate containing at least one Wildcard Domain Name in the Subject
Alternative Names in the Certificate.
Wildcard Domain Name: A string starting with “*.” (U+002A ASTERISK, U+002E FULL STOP)
immediately followed by a Fully‐Qualified Domain Name.
WHOIS Lookup: Information retrieved directly from the Domain Name Registrar or registry
operator via the protocol defined in RFC 3912, the Registry Data Access Protocol defined in RFC
7482, or an HTTPS website.
X.400: The standard of the ITU-T (International Telecommunications Union-T) for E-mail.
X.500: The standard of the ITU-T (International Telecommunications Union-T) for Directory
Services.
X.509: The standard of the ITU-T (International Telecommunications Union-T) for Certificates.
AATL
AICPA
API
ARL
CA
CAA
CCADB
ccTLD
CICA
CP
CPS
CRL
DBA
DNS
EIR
EKU
EPKI
ETSI
EV
FIPS
FQDN
GCC
GPS
IANA
ICANN

Adobe Approved Trust List
American Institute of Certified Public Accountants
Application Programming Interface
Authority Revocation List (A CRL for Issuing CAs rather than end entities)
Certification Authority
Certificate Authority Authorization
Common CA Database
Country Code Top-Level Domain
Canadian Institute of Chartered Accountants
Certificate Policy
Certification Practice Statement
Certificate Revocation List
Doing Business As
Domain Name System
Electric Industry Registry
Extended Key UsageEnterprise PKIEuropean Telecommunications Standards Institute
Extended Validation(US Government) Federal Information Processing Standard
Fully Qualified Domain Name
GlobalSign Certificate Center
Global Positioning System
Internet Assigned Numbers Authority
Internet Corporation for Assigned Names and Numbers

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

37 of 98

GlobalSign Certification Practice Statement

IETF
ISO
ITU
LRA
NAESB
NCA
NIST
NTP
OCSP
OID
PKI
PSP
QGIS
QGTIS
QIIS
RA
RFC
S/MIME
SSCD
SSL
TLD
TLS
VAT
WEQ

Internet Engineering Task Force
International Organization for Standardization
International Telecommunications Union
Local Registration Authority
North American Energy Standards Board
National Competent Authority(US Government) National Institute of Standards and Technology
Network Time Protocol
Online Certificate Status Protocol
Object Identifier
Public Key Infrastructure
Payment service provider
Qualified Government Information Source
Qualified Government Tax Information Source
Qualified Independent Information Source
Registration Authority
Request for Comments
Secure MIME (Multipurpose Internet Mail Extensions)
Secure Signature Creation Device
Secure Sockets Layer
Top-Level Domain
Transport Layer Security
Value Added Tax
Wholesale Electric Quadrant

2.0 Publication and Repository Responsibilities
2.1

Repositories

GlobalSign publishes all CA Certificates and Cross Certificates, revocation data for issued
Certificates, CP, CPS, and Relying Party agreements and Subscriber Agreements in Repositories.
GlobalSign ensures that revocation data for issued Certificates and its Root Certificates areavailable through a Repository 24 hours a day, 7 days a week with a minimum of 99% availability
overall per year with a scheduled downtime that does not exceed 0.5% annually.
GlobalSign may publish submitted information on publicly accessible directories for the provisionof Certificate status information.
GlobalSign refrains from making publicly available sensitive and/or confidential documentation
including security controls, operating procedures, and internal security policies. These documents
are, however, made available to Qualified Auditors as required during any WebTrust or ETSI audit
performed on GlobalSign.
Country specific web sites and translations of this CPS and other public documentation may bemade available by GlobalSign and/or group companies for marketing purposes, however therepositories
forall
GlobalSign
publicfacingdocumentationarehttps://www.globalsign.com/repository and https://www.globalsign.com/en/company/corporatepolicies and in the event of any inconsistency, the English language version shall control.

2.2

Publication of Certificate Information

GlobalSign publishes its CP, CPS, Subscriber Agreements, and Relying Party agreements at
https://www.globalsign.com/repository. The CP and CPS include all the material required by RFC
3647, and are structured in accordance with RFC 3647. CRLs are published in online repositories.
The CRLs contain entries for all revoked unexpired Certificates with a validity period that depends
on Certificate type and/or position of the Certificate within the Certificate chain.
GlobalSign hosts test Web pages that allow Application Software Suppliers to test their softwarewith Subscriber Certificates that chain up to each publicly trusted Root Certificate. Below are test
Web pages for (i) valid, (ii) revoked, and (iii) expired Certificates.
Root R1:
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

38 of 98

GlobalSign Certification Practice Statement

https://valid.r1.roots.globalsign.com
https://revoked.r1.roots.globalsign.com
https://expired.r1.roots.globalsign.com

Root R3:
https://valid.r3.roots.globalsign.com
https://revoked.r3.roots.globalsign.com
https://expired.r3.roots.globalsign.com

Root R5:https://valid.r5.roots.globalsign.com
https://revoked.r5.roots.globalsign.com
https://expired.r5.roots.globalsign.com

Root R6https://valid.r6.roots.globalsign.com
https://revoked.r6.roots.globalsign.com
https://expired.r6.roots.globalsign.com

Root R46
https://valid.r46.roots.globalsign.com
https://revoked.r46.roots.globalsign.com
https://expired.r46.roots.globalsign.com

Root E46
https://valid.e46.roots.globalsign.com
https://revoked.e46.roots.globalsign.com
https://expired.e46.roots.globalsign.com

2.3

Time or Frequency of Publication

CA Certificates are published in a Repository via support pages as soon as possible after issuance.
GlobalSign reviews its CP and CPS at least every 365 days and makes appropriate changes sothat GlobalSign operation remains accurate, transparent and complies with external requirements
listed in the “Acknowledgements” section of this document.
GlobalSign closely monitors CA/Browser Forum ballots and updates to the CA/Browser Forum
Requirements and implements updates to GlobalSign operations in a timely manner.
New or modified versions of the CP, this CPS, Subscriber Agreements, or Relying Party
agreements are published within seven days after approval.

2.4

Access Controls on Repositories

GlobalSign makes its Repository publicly available in a read-only manner.
Logical and physical security measures are implemented to prevent unauthorized persons fromadding, deleting, or modifying repository entries.

3.0 Identification and Authentication
GlobalSign acts as an RA and verifies and authenticates the identity and other attributes of an
Applicant prior to inclusion of those attributes in a Certificate.
Applicants are prohibited from using names in their Certificate that infringe upon the intellectual
property rights of others. GlobalSign does not verify whether an Applicant has intellectual property
rights in the name appearing in the Certificate application or arbitrate, mediate, or otherwise resolve
any dispute concerning the ownership of any Domain Name, trademark, trade name or service
mark. GlobalSign reserves the right, without liability to any Applicant, to reject an application
because of such a dispute.
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

39 of 98

GlobalSign Certification Practice Statement

GlobalSign RAs authenticate the requests of parties wishing to revoke Certificates.

3.1
3.1.1

NamingTypes of Names

GlobalSign Certificates are issued with subject DNs (Distinguished Names) which meet therequirements of X.500 naming, RFC-822 naming and X.400 naming. DNs respect name space
uniqueness and are not misleading. However, some Certificates such as DV TLS, OV TLS andIntranetSSL SSL Common Names may also include RFC2460 (IP version 6) or RFC791 (IP version4) addresses.
Wildcard SSL Certificates include a wildcard asterisk character as the first character in a CN or
SAN. Before issuing a Certificate with a wildcard character (*) in the CN or SAN, GlobalSign follows
best practices to determine if the wildcard character occurs in the first label position to the left of a“registry-controlled” label or “public suffix.” (e.g., “*.com”, “*.co.uk”, see RFC 6454 Section 8.2 forfurther explanation.) and, if it does, it will reject the request if that Domain Namespace is not owned
or controlled by the Subscriber.
For S/MIME BR Certificates, when the subject:commonName of a Certificate issued to an Individual
does not contain a Mailbox Address, it is specified as a Personal Name or Pseudonym as describedin Section 7.1.4.2.2(a). Names consisting of multiple words are permitted. Given names joined witha hyphen are considered as one single given name. Subjects with more than one given name may
choose one or several of their given names in any sequence. Subjects may choose the order of
their given name(s) and surname in accordance with national preference. GlobalSign allows
common variations or abbreviations of Personal Names consistent with local practice.
3.1.2

Need for Names to be Meaningful

In cases where a GlobalSign product allows the use of a role or departmental name, and where the
OU field is included in the DN, additional unique elements may be added to the DN within the OU
field to allow Relying Parties to differentiate between Certificates with common DN elements.
For S/MIME BR Certificates, Personal Names shall be a meaningful representation of the Subject’s
name as verified in the identifying documentation or Enterprise RA records.
3.1.3

Anonymity or Pseudonymity of Subscribers

GlobalSign may issue end entity anonymous or pseudonymous Certificates provided that such
Certificates are not prohibited by applicable policy and, where possible, name space uniqueness ispreserved. GlobalSign reserves the right to disclose the identity of the Subscriber if required bylaw. Requests for internationalized domain names (IDNs) in Certificates will be flagged for
additional manual review. The decoded hostname will undergo additional review to attempt tomitigate the risk for phishing and other fraudulent usage and the decoded hostname may becompared with previously rejected Certificate requests or revoked Certificates. GlobalSign may
reject applications based on risk-mitigation criteria, for instance; names at risk for phishing or otherfraudulent usage, names listed on the Google Safe Browsing lists or names listed in the databasemaintained by the Anti-Phishing Working Group.
GlobalSign allows the use of Pseudonyms for S/MIME Certificates in accordance with section 3.1.3of the GlobalSign CP.
3.1.4

Rules for Interpreting Various Name Forms

Distinguished names in Certificates are interpreted using X.500 standards and ASN.1 syntax. See
RFC 2253 and RFC 2616 for further information on how X.500 distinguished names in Certificatesare interpreted as Uniform Resource Identifiers and HTTP references.
GlobalSign does not perform non-ascii character substitution for S/MIME BR Certificates.
3.1.5

Uniqueness of Names

GlobalSign includes distinct Subject attributes in the Certificate to ensure Subject uniqueness.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

40 of 98

GlobalSign Certification Practice Statement

3.1.6

Recognition, Authentication, and Role of Trademarks

Subscribers may not request Certificates with any content that infringes the intellectual property
rights of a third party. GlobalSign does not require that an Applicant’s right to use a trademark beverified. GlobalSign reserves the right to revoke any Certificate that is involved in a dispute.

3.2

Initial Identity Validation

GlobalSign may perform identification of the Applicant or for services including CA chaining
services using any legal means of communication or investigation necessary to identify the Legal
Entity or individual.
GlobalSign uses the results of successful initial identity validation processes to create alternative
product offerings by combining elements of previously verified information with alternative, newly
verified information. A customer account is used to authenticate the use of any previously verified
information for returning Applicants provided that the re-verification requirements of Section 3.3.1
are complied with by the customer account holder.
3.2.1

Method to Prove Possession of Private Key

No Stipulation.
3.2.2

Authentication of Organization Identity

GlobalSign maintains internal policies and procedures which are reviewed regularly in order tocomply with the requirements of the various root programs that GlobalSign is a member of, as wellas the CA/Browser Forum Requirements.
Validation policy and procedure documents are under the control of PACOM5 – Subscriber
Validation (subordinate to the main Policy Authority in section 1.5.1) fulfilling the criteria of Principle
6 of the WebTrust Program for CAs. The method by which GlobalSign verifies the organization
identity is generally consistent across all product types, however alternative methods, in line withaccepted alternatives, may be used where authentication is not possible through the morecommonly used QGIS method outlined below.
For all Certificates that include an organization identity, Applicants are required to provide theorganization’s name and registered or trading address. For all Certificates that include anorganization identity, GlobalSign verifies legal existence and identity, legal name, assumed name
(if applicable), legal form (where included in the request or part of the legal name in the jurisdictionof incorporation), requested address of the organization and a reliable method of communication.
For Extended Validation, GlobalSign additionally verifies physical existence, operational existence
and, where required to perform additional validation steps, a reliable means of communication.
This information may be verified using one of the following validation methods:••••

A government agency (QTIS or QGIS, including Incorporating Agency or Registration
Agency) in the jurisdiction of the Applicant, or a superior governing governmental agency
if the Applicant claims they are a government agency themselves.
A QIISA Verified Legal Opinion or a Verified Accountant Letter
Independent Confirmation from the Applicant.

Additionally, for non-Extended Validation Certificates, GlobalSign may verify the Applicant’s
information using one of the following reliable data sources:• A letter attesting that Subject Information is correct written by an accountant, lawyer,
government official, or other reliable third party customarily relied upon for suchinformation.
• A document, generally a utility bill, bank statement, credit card statement, governmentissued tax document, or other form of identification that has been determined by GlobalSign
to be reasonably accurate and reliable. These documents are recognized amongcommercial enterprises and governments as reliable and are created by a third party for a
purpose other than the Applicant obtaining a Certificate.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

41 of 98

GlobalSign Certification Practice Statement•

A third party database, created by a third party for a purpose other than the Applicant
obtaining a Certificate, that is generally recognized among commercial enterprises andgovernments as reliable, and that is used to verify information, and which is periodically
updated. The third party database is evaluated by GlobalSign for its reliability, accuracy,
and resistance to alteration or falsification.

These validation methods are used in accordance with the industry standards. Not all validation
methods will be acceptable in all circumstances or be available to use for all types of information.
The list of Incorporating Agencies or Registration Agencies is published in the Legal Repository on
GlobalSign’s website (globalsign.com), under the section “Validation Resources”.
The authority of the Applicant to request a Certificate on behalf of the organization is verified inaccordance with Section 3.2.5 below.
3.2.2.1

Local Registration Authority Authentication

For EPKI and MSSL accounts, GlobalSign sets authenticated organizational details in the form of
a Profile. Suitably authenticated account administrators acting in the capacity of a Local
Registration Authority authenticate individuals affiliated with the organization and/or any subdomains owned or controlled by the organization. (While LRAs are able to authenticate individuals
under contract, all domains to be authenticated will have previously been verified by GlobalSign).
3.2.2.2

Role Based Certificate Authentication (DepartmentSign)

GlobalSign ensures that requests for machine, device, department, or role-based Certificates areauthenticated. LRAs are contractually obligated to ensure that machine, device, department, orrole-based names relating to the organization profile and its business are accurate and correct.
3.2.2.3

S/MIME BR Certificates

Applicant’s information includes the following:• Formal name of the Legal Entity;• A registered Assumed Name for the Legal Entity (optional)• An organizational unit of the Legal Entity (optional);• An address of the Legal Entity;• Organization Identifier, consisting of an appropriate registration scheme identifier, 2character ISO 3166 country code for the nation where the scheme is operated (“XG” shallbe used when the scheme is operated globally), where applicable the ISO 3166‐2
identifier for the subdivision of the nation in which the Registration Scheme is operated,
and where applicable the registration reference allocated in accordance with theidentified registration scheme.
GlobalSign verifies the Applicant’s information using at least one of the following methods:• A government agency in the jurisdiction of the Legal Entity’s creation, existence, or
recognition;• A Legal Entity Identifier (LEI) data reference. In this case, GlobalSign verifies that theRegistration Status is ISSUED and the EntityStatus is ACTIVE. GlobalSign only allows
use of an LEI if the ValidationSources entry is FULLY_CORROBORATED;• A site visit by the CA or a third party who is acting as an agent for the CA; or• An Attestation which includes a copy of supporting documentation used to establish theApplicant’s legal existence, such as a certificate of registration, articles of incorporation,
operating agreement, statute, or regulatory act.
GlobalSign uses the following registration schemes:• NTR: For an identifier allocated by a national or state trade register to the Legal Entity
named in the subject:organizationName.
• VAT: For an identifier allocated by the national tax authorities to the Legal Entity namedin the subject:organizationName.
• LEI: For a Legal Entity Identifier as specified in ISO 17442 for the entity named in thesubject:organizationName. The 2 character ISO 3166 country code shall be set to ‘XG’
• GOV: For Government Entities
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

42 of 98

GlobalSign Certification Practice Statement•

INT: for Non Commercial Entities. The 2 character ISO 3166 country code shall be set to‘XG’

GlobalSign verifies Assumed Names by verifying that:• The Applicant has registered its use of the Assumed Name with the appropriate
government agency for such filings in the jurisdiction of its incorporation or registration;and• The Assumed Name filing continues to be valid.
GlobalSign may rely on an attestation that indicates the Assumed Name under which theApplicant conducts business, the government agency with which the Assumed Name isregistered, and that such filing continues to be valid.
3.2.2.4

Qualified Certificates

GlobalSign issues three types of Qualified Certificates that include an Organization Identity:• Qualified Certificate for Electronic Seals, which assert the identity of an Organization• Qualified Certificates for Electronic Signatures, which assert the Individual’s affiliation withan Organization.
• Qualified Website Authentication Certificates.
For all Qualified Certificates that include an organization identity, Applicants are required to indicate
the organization’s full legal name (including the legal form) and the address of the physical locationof the Subject’s place of business.
GlobalSign verifies the legal existence and the address by reference to:• official government records provided in Qualified Government Information Sources; or• documentation provided by or confirmation received from a government agency in thejurisdiction of the Organization’s legal creation, existence, or recognition; or• records provided by a Qualified Independent Information Source.
Additionally, GlobalSign may verify the address by reference to:• a Verified Legal Opinion or a Verified Accountant letter; or• an attestation of the physical location signed using the Organization’s valid Qualified
Electronic Seal.
The information in the attestation must match the content of the Qualified Certificate.
The Full Legal Name of the Organization, doing business as names (Trade Name or Trading As
Name) may also be included in the Qualified Certificate. GlobalSign will verify that the Organization
has registered the use of any included doing business as name with the appropriate government
agency for such filings in the jurisdiction of its Place of Business, and that such filing continues tobe valid.
For Certificates that assert the Individual’s affiliation with an Organization, GlobalSign will verify thisaffiliation by reference to:• Confirmation provided by the Organization, obtained using a Verified Method ofCommunication; or• Independent Confirmation from the Organization; or• a Verified Legal Opinion or a Verified Accountant letter; or• an attestation signed using the Organization’s valid Qualified Electronic Seal; or• an attestation obtained by a suitably authenticated account administrator acting in thecapacity of a Local Registration Authority.
For Qualified Certificates that assert the identity of the Organization and for Qualified Website
Authentication Certificates, GlobalSign will verify the identity and the authority of the Organization’s
authorized representative(s).
GlobalSign will verify the authority of the authorized representative(s) by reference to:

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

43 of 98

GlobalSign Certification Practice Statement

•
•
•
•
•

official government records provided in Qualified Government Information Sources; or
documentation provided by or confirmation received from a government agency in thejurisdiction of the Organization’s legal creation, existence, or recognition; orrecords provided by a Qualified Independent Information Source; ora Verified Legal Opinion or a Verified Accountant letter; oran attestation signed using the Organization’s valid Qualified Electronic Seal. The
information in the attestation must match the content of the Qualified Certificate.

GlobalSign will verify the identity of the authorized representative in accordance with section 3.2.3.
GlobalSign may subscribe Certificates for GlobalSign affiliate companies, or persons identified inassociation with these companies (as a Subject). GlobalSign affiliate companies include
GlobalSign's parent and subsidiary companies, as well and other companies that share a same
parent company as GlobalSign.
For any PSD2 Specific Attributes, GlobalSign will validate attributes using information provided by
the National Competent Authority, which includes but is not limited to national public registers,
European Banking Authority registers and authenticated communication from the National
Competent Authority.
If GlobalSign is notified of an email address where it can inform the NCA identified in a newly issued
Certificate then GlobalSign shall send to that email address information on the content of theCertificate in plain text including the Certificate serial number in hexadecimal, the subject
distinguished name, the issuer distinguished name, the Certificate validity period, as well as contact
information and instructions for revocation requests and a copy of the Certificate file.
3.2.3

Authentication of Individual identity

GlobalSign authenticates Individuals depending upon the class of Certificate as indicated below.
3.2.3.1

Class 1The Applicant is required to demonstrate control of their email address or domain name to which
the Certificate relates. GlobalSign does not authenticate additional information/attributes which may
be provided by the Applicant during the application and enrollment process. This encompasses DV
Certificates.
For Domain SSL, the Applicant is required to demonstrate control of all domain names to be
included in a Certificate.
3.2.3.2

Class 2The Applicant is required to demonstrate control of certain identity attributes included in the request,
such as his/her email address or domain name to which the Certificate relates if included in theCertificate request. This encompasses OV Certificates.
For Organization Validation SSL, the Applicant is required to demonstrate control of all domainnames to be included in a Certificate.
The Applicant may also be required to submit a legible copy of a valid government issued national
identity document or photo ID (driver’s license, military ID or equivalent). A suitable non-government
issued identity document or photo ID may also be required for additional proof. GlobalSign verifies
to a reasonable level of assurance that the copy of the ID matches the requested name and that
other Subject information such as Country and/or state and locality fields are correct.
GlobalSign may also authenticate the Applicant’s identity through one of the following methods:•••

Performing a telephone challenge/response to the Applicant using a telephone number
from a reliable source; orPerforming a fax challenge/response to the Applicant using a fax number from a reliable
source; orPerforming an email challenge/response to the Applicant using an email address from areliable source; orGlobalSign CPS (Certification Practice Statement)
Version: 10.1

44 of 98

GlobalSign Certification Practice Statement••

Performing a postal challenge to the Applicant using an address obtained from a reliable
source; or
The Applicant’s seal impression (in jurisdictions that permit their use to legally sign adocument) is included with any application received in writing.

For AATL, the options are defined as follows. Please note that these options are also available forother Class 2 products:
•
•

•
•
•

Receiving an attestation from an appropriate notary or Trusted Third Party that they haveverified the individual identity based on a Governmentally Accepted Form of ID.
In the case of individuals affiliated with an organization: obtaining an executed declarationof identity of the individual that includes at least one unique biometric identifier of theindividual (such as a fingerprint or handwritten signature). In this executed declaration ofidentity, an authorized representative of the Organization mentioned in the certificate
confirms having seen the individual, reviewed the individual’s photo ID, and confirm thatthe individual’s identity information in the certificate requests matches the information
contained in the reviewed photo ID. GlobalSign confirms the document’s authenticity
directly with the authorized representative of the organization using contact information
confirmed using a Qualified Independent Information Source or a Qualified Government
Information Source or any other method in line with the EV Guidelines. GlobalSign confirms
the authorized representative’s authority to represent the Organization in line with the EV
Guidelines.
In the case of individuals affiliated with an organization, GlobalSign may rely on attestations
from the approved Local RA. Refer to 3.2.3.5 in case of a Class 2 Certificate requested
through an EPKI or an MSSL profile.
Receiving an attestation from an organization to validate the identities of its own end
customers based on a verification of a Governmentally Accepted Form of ID, while theorganization maintains a secure auditable trail of these verifications.
Other verifications in line with the verification of individuals for Qualified Certificates.

For AATL, GlobalSign may establish the Individual’s identity and perform inspection of aGovernmentally Accepted Form of ID through a video-based meeting or an approach withequivalent assurance.
GlobalSign may request further information from the Applicant. Other information and/or methods
may be utilized in order to demonstrate an equivalent level of confidence.
If an email address is to be included in the Certificate request, GlobalSign or LRA shall verify thevalidity and ownership of that email address.
3.2.3.3

Class 3For EV Code Signing, the Applicant is required to demonstrate control of any email address to be
included in a Certificate.
For Extended Validation SSL, the Applicant is required to demonstrate control of all domain names
to be included in a Certificate.
The Applicant is required to submit a legible copy of a valid government issued national identity
document or photo ID (driver’s license, military ID or equivalent). A suitable non-government issued
identity document or photo ID may also be required for additional proof. GlobalSign or a trusted
third party verifies to a reasonable level of assurance that the copy of the ID matches the requested
name and that other Subject information such as Country and/or state and locality fields are correct.
Where the submission of a copy of a government issued national identity document or photo ID is
prohibited by local law or regulation, GlobalSign shall use an alternative method to authenticate theidentity of the Applicant. In such cases, GlobalSign shall accept attestation or documentation froma Trusted Third Party authorized to conduct identity verification.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

45 of 98

GlobalSign Certification Practice Statement

For PersonalSign 3 Pro, a face-to-face meeting is required to establish the individual’s identity withan attestation from the notary or trusted third party that they have met the individual and haveinspected their national photo ID document, and that the application details for the order are correct.
GlobalSign may establish the Individual’s identity and perform inspection of a Governmentally
Accepted Form of ID through a video-based meeting or an approach with equivalent assurance.
The Applicant is also required to demonstrate control of any email address to be included in a
Certificate.
GlobalSign also authenticates the Applicant’s authority to represent the organization wishing to be
named as the Subject in the Certificate using reliable means of communication, verified by
GlobalSign as a reliable way of communicating with the Applicant in accordance with the EV
Guidelines and the Baseline Requirements for Code Signing.
Further information may be requested from the Applicant or the Applicant’s organization. Other
information and/or methods may be utilized in order to demonstrate an equivalent level ofconfidence.
3.2.3.4

S/MIME BR Certificates

Applicant’s information includes the following:
1.
2.
3.
4.

Given name(s) and surname(s), which shall be current names;
Pseudonym (if used);
Title (if used); andFurther information as needed to uniquely identify the Applicant.

GlobalSign must verify the Individual Applicant’s identity and identity attributes information using
at least one of the following methods:•

For the collection of Applicant’s identity and identity attributes:
o Using an official physical identity document, issued to the Applicant by a relevant
government agency in the Applicant’s jurisdiction, for the purposes ofidentification, containing a photo and/or other (biometric) information that can becompared with the Applicant’s physical appearance. Examples include but are
not limited to passports, identity cards, drivers' licenses and military IDs. (S/MIME
BR Section 3.2.4.1 (1)); oro Using a digital or electronic identity document, considered eMRTD identity
documents according to ICAO 9303 part 10 (S/MIME BR Section 3.2.4.1 (2)); oro Using a valid eID issued under a “notified” eID schemes according to Article 9 ofthe eIDAS Regulation and the eID shall conform to eIDAS LoA “Substantial” or“High” (S/MIME BR Section 3.2.4.1 (3)); oro Using a Certificate request signed with a valid digital signature, based on a valid
personal Certificate that was issued under an Approved Framework described in
the S/MIME BRs (S/MIME BR Section 3.2.4.1 (4)); oro For Sponsor-validated Certificates only, using Enterprise RA records (S/MIME
BR Section 3.2.4.1 (5)).
o For authority or affiliation of an Individual to represent an Organization to be
included in the subject:organizationName of the Certificate, using an Attestation
provided by the Organization (S/MIME BR Section 3.2.4.1 (6)).
o Using an Attestation from a qualified legal practitioner or notary in the Applicant’s
jurisdiction (S/MIME BR Section 3.2.4.1 (7)).

GlobalSign shall verify supplementary evidence using authorized sources such as additional official
documents, government or regulatory registers, or national population registers (S/MIME BR
Section 3.2.4.1 (8)). Before relying on a source of verification data, GlobalSign verifies its suitability
as a Reliable Data Source.
In terms of validation, the following practices apply:

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

46 of 98

GlobalSign Certification Practice Statement

Any physical identity document shall be presented in its original form. GlobalSign employs
procedures to ensure the evidence presented by the Applicant is a genuine identity document thatis not counterfeited or falsified/modified. When using a remote process, this process ensures that
the Applicant has the document in hand and presents the document in real‐time in front of a camera.
GlobalSign maintains an internal authoritative source of information which covers documents
accepted by GlobalSign, their appearance and how to validate these documents. (S/MIME BR
Section 3.2.4.2 (1))
For digital identity documents, GlobalSign checks that the issuer’s digital signature on the document
is successfully validated according to ICAO 9303 part 11. (S/MIME BR Section 3.2.4.2 (2))
For both physical and digital identity documents, GlobalSign may use manual (in person) or remote
procedures, or a combination of both. GlobalSign records the following information: issuer, validity
period, and the document’s unique identification number. To ensure that the Applicant’s identity isverified, GlobalSign makes a visual comparison of the physical appearance of the Applicant andthe face photo and/or other information on the physical or digital identity document. (S/MIME BR
Section 3.2.4.2 (1) and 3.2.4.2 (2))
For authentication using the eID, the validation with the eID’s Identity Provider (IdP) is documented
and retained (S/MIME BR Section 3.2.4.2 (3)).
For validation of a digital signature with a certificate, the signature shall have been created as partof the identity validation process. GlobalSign validates the digital signature and only uses thesigning Certificate as evidence for identity attributes if the signature is valid (S/MIME BR Section
3.2.4.2 (4)).
For validation of an attestation, GlobalSign verifies the reliability of the Attestation Letter inaccordance with Section 3.2.8 of the Baseline Requirements for S/MIME. GlobalSign verifies that
the Attestation was written by an accountant, lawyer, government official, or other reliable third
party in the Applicant’s jurisdiction customarily relied upon for such information. An Attestation
includes a copy of documentation supporting the fact to be attested. GlobalSign uses a Reliable
Method of Communication to contact the sender and to confirm the Attestation is authentic (S/MIME
BR Section 3.2.4.2 (5)).
For validation using an Enterprise RA Record, the Enterprise RA issuing a Sponsor-validated
Certificate validates all identity attributes of an Individual to be included in the Certificate. The
Enterprise RA may rely upon existing internal records to validate Individual identity (S/MIME BR
Section 3.2.4.2 (6)).
3.2.3.5

Qualified Certificates

GlobalSign verifies the Identity of Individual Subscribers according to Article 24.1 of the eIDAS/UK
eIDAS Regulation, in particular using the following methods:• In-person identity verification• Using electronic identification means• Using Qualified Electronic Signature• Video-verification
3.2.3.5.1 In-person Verification
In-person verification requires a physical presence of the Subscriber, and requires the productionof the following documents:• Government Issued Photo ID• Signed personal statement
The likeness of the Individual is compared to the Photo ID, and the security features of the Photo
ID are inspected. The signature on the personal statement is compared to the signature on the
Photo ID.
This verification may be performed by a Third Party Validator.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

47 of 98

GlobalSign Certification Practice Statement

Additional secondary evidence may be required to ensure the uniqueness of the Applicant’s
identity, or to validate information included in the certificate other than the given name.
3.2.3.5.2 Using Remote Electronic Identification Means
GlobalSign may use electronic identification means to verify the Individual Identity. All electronic
identification means have an assurance level of ‘Substantial’ or ‘High’ as set out in Article 8 of theeIDAS Regulation. Prior to issuance, the physical presence of the Individual is ensured.
1. For notified electronic identification schemes, the assurance level will be determined by the
notification given by the Member State to the Commission.
2. For electronic identification means that have not been notified, the assurance level will be
determined according to the factors described by the European Commission. After review
by the Conformity Assessment Body, GlobalSign will present the findings to theSupervisory Body for acceptance prior to accepting the electronic identification means inthis section.
3.2.3.5.3 Qualified Electronic Signature
GlobalSign uses the Subscriber’s valid qualified electronic signature on a personal statement toverify the Applicant's identity and additional attributes contained in the Certificate used to create
the qualified electronic signature. The Certificate must be issued in compliance with Article 24 (a)or (b) of the eIDAS/UK eIDAS Regulation.
3.2.3.5.4 Video Verification
GlobalSign may use video verification. Similar to in-person verification, the Subscriber will be
required to provide of the following documents:• Government Issued Photo ID• (Electronically) signed personal statement
Additional secondary documentary evidences may be required to ensure the uniqueness of the
Applicant’s identity, or to validate information included in the certificate other than the given name.
The likeness of the Individual is compared to the Photo ID, and the security features of the Photo
ID are inspected. This method requires that the Subscriber has access to an internet-enabled
device, a working webcam or other video-equipment and a working microphone and sound-system.
3.2.3.6

Local Registration Authority Authentication

For Organization accounts which allow the concept of a Local Registration Authority, GlobalSign
sets authenticated organizational details in the form of a profile. Certificates issued within theseaccounts are populated with data fields from the profile. The Organization is contractually obligatedto authenticate individuals affiliated with the organization.
3.2.3.7

North American Energy Standards Board (NAESB) Certificates

For NAESB Certificate requests, authenticity of organization identity requests for Certificates in thename of an affiliated organization shall include the organization name, address, and documentationof the existence of the organization. GlobalSign or the RA shall verify the information, in addition to
the authenticity of the requesting representative and the representative’s authorization to act in thename of the organization. End entities using Certificates for WEQ-012 applications shall beobligated to register their legal business identification and secure an “Entity Code” that will be
published in the NAESB EIR and used in all Subscriber applications submitted by, and Certificatesissued to, that end entity. When issuing Certificates for use within the energy industry for other than
WEQ-012 applications, ACAs must comply with the provisions of the NAESB WEQ-012 Public Key
Infrastructure Business Practice Standards and Models, except provisions in WEQ-012-1.9.1,
WEQ-012-1.3.3, and WEQ-012-1.4.3, which require End Entity registration within the NAESB EIR.
GlobalSign may elect to perform RA operations/functions in-house or choose to delegate some, orall, RA operations/functions to other parties that are separate legal entities via one of its managed
service offerings. In both cases, the party or parties performing RA operations/functions are subject
to the obligations for identity proofing, auditing, logging, protection of Subscriber information, record
retention and other aspects germane to the RA function outlined in this CPS and the NAESB
Accreditation Specification and NAESB Business Practice Standards. All RA infrastructure andGlobalSign CPS (Certification Practice Statement)
Version: 10.1

48 of 98

GlobalSign Certification Practice Statement

operations performing RA operations/functions shall be held to this requirement as incumbent upon
the Certificate Authority when performing in-house RA operations/functions. The Authorized
Certification Authority and/or delegated entity are responsible for ensuring that all parties
performing RA operations/functions understand and agree to conform to the NAESB Accreditation
Specification.
For Subscribers, GlobalSign, and/or associated RAs shall ensure that the Applicant’s identity
information is verified in accordance with the process established by the GlobalSign CP and CPS.
The process shall depend upon the Certificate level of assurance and shall be addressed in the
NAESB Accreditation Specification. The documentation and authentication requirements shall varydepending upon the level of assurance.
Registration of Identity Proofing Requirements shall use the following mappings:
NIST Assurance Level

NAESB Assurance Level

Level 1

Rudimentary

Level 2

Basic

Level 3MediumGlobalSign, or its designated RA in the case of EPKI, shall verify all of the identification information
supplied by the Applicant in compliance with the authentication requirements defined by the Identity
Proofing Process (IPP) Method described in section 2.2.2: Authentication of Subscribers of the“NAESB Accreditation Requirements for Authorized Certification Authorities.”
3.2.4

Non-Verified Subscriber Information

GlobalSign does not verify the contents of the Subject:OrganizationalUnitName field, except for
Code Signing Certificates where the Subject:OrganizationalUnitName field contains a name, DBA,
tradename, trademark, address, location, or other text that refers to a specific natural person orLegal Entity.
GlobalSign may allow the use of the Subject:SerialNumber as a location for non-verified Subscriber
information where permitted by industry standards.
For IntranetSSL SSL Certificates only, GlobalSign relies upon information provided by the Applicant
to be included within the subjectAlternativeName, such as internal or non-public DNS names,
hostnames, and RFC 1918 IP addresses.
For S/MIME BR Certificates, Subscriber information that has not been verified in accordance with
the Baseline Requirements for S/MIME will not be included in the Certificate.
3.2.5

Validation of Authority

PersonalSign1 Certificates

Verification that the Applicant has control over the email address
to be listed within the Certificate through a challenge response
mechanism.

PersonalSignDemo
Certificates

Verification that the Applicant has control over the email address
to be listed within the Certificate.

PersonalSign2 Certificates

Verification through a reliable means of communication with theindividual Applicant together with verification that the Applicant
has control over any email address included.

NAESB Certificates

Verification through a reliable means of communication with theorganization or individual Applicant together with verification that
the Applicant has control over any email address included (seeSection 3.2.3.5.)

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

49 of 98

GlobalSign Certification Practice Statement

PersonalSign2 Pro

Verification of the individual Applicant together with verificationthat the Applicant has control over the email address included if
required. Additionally, verification that the Applicant
Representative has the authority and approval to perform one ormore of the following: to request issuance or revocation of
Certificates; or to assign responsibilities to others to act in theseroles. For Certificates issued through an EPKI account, theAuthority of the Applicant Representative to act as an Enterprise
RA will be verified at the time of the set-up of the profile.

PersonalSign2 Department
Certificates

Verification of the individual Applicant together with verificationthat the Applicant has control over the email address included if
required. Additionally, verification that the Applicant
Representative has the authority and approval to perform one ormore of the following: to request issuance or revocation of
Certificates; or to assign responsibilities to others to act in theseroles. For Certificates issued through an EPKI account, theAuthority of the Applicant Representative to act as an Enterprise
RA will be verified at the time of the set-up of the profile.

PersonalSign3 Certificates

Verification through a reliable means of communication with theApplicant Representative that they have the authority andapproval to perform one or more of the following: to request
issuance or revocation of Certificates; or to assign responsibilities
to others to act in these roles, together with verification that the
Applicant has control over the email address if an email address
is requested to be included in the Certificate. For Certificatesissued through an EPKI account, the Authority of the Local
Registration Authority will be verified at the time of the set-up of
the profile.

S/MIME Certificates

Verification through a reliable means of communication with theorganization or individual Applicant together with verification that
the Applicant has control over any email address included.
Additionally, verification that the Applicant Representative has theauthority and approval to perform one or more of the following: torequest issuance or revocation of Certificates; or to assign
responsibilities to others to act in these roles. For Certificatesissued through an EPKI account, the Authority of the Applicant
Representative to act as an Enterprise RA will be verified at thetime of the set-up of the profile.

S/MIME BR Certificates

Validation in accordance with the Baseline Requirements for
S/MIME.

Code Signing Certificates

Verification through a reliable means of communication with theorganization or individual Applicant together with verification that
the Applicant has control over any email address that may be
optionally listed within the Certificate.

EV Code Signing
Certificates

Verifying the authority of the contract signer and Certificate
approver in accordance with the EV Guidelines and Baseline
Requirements for Code Signing.

DV/AlphaSSL Certificates

Validation of the ownership or control of the domain name isperformed via one of the domain validation methods defined in
Section 3.2.7.

OV SSL Certificates

Verification through a reliable means of communication with theorganization or individual Applicant together with verification that
the Applicant has ownership or control of the domain name via
the methods listed in section 3.2.7. For Certificates issued throughGlobalSign CPS (Certification Practice Statement)
Version: 10.1

50 of 98

GlobalSign Certification Practice Statement

an MSSL account, the Authority of the Local Registration
Authority will be verified at the time of the set-up of the profile.
EV SSL Certificates

Verifying the authority of the contract signer and Certificate
approver in accordance with the EV Guidelines together withverification that the Applicant has ownership or control of thedomain name via the methods listed in section 3.2.7. For
Certificates issued through an MSSL account, the Authority of the
Local Registration Authority will be verified at the time of the setup of the profile.

Timestamping Certificates

Verification through a reliable means of communication with theorganization’s Applicant.

AATL

Verification through a reliable means of communication with theorganization or individual Applicant together with verification that
the Applicant has control over the email address if an email
address is requested to be included in the Certificate. For
Certificates issued through an EPKI account, the Authority of the
Local Registration Authority will be verified at the time of the setup of the profile.

Qualified Website
Authentication Certificates

Verifying the authority of the contract signer/Certificate approverand the authorized representative in accordance with themethods listed in section 3.2.2.3 together with verification that the
Applicant has ownership or control of the domain name via themethods listed in section 3.2.7.

Qualified Certificate forElectronic Seal

Verifying the authority of the contract signer Certificate approverand the authorized representative in accordance with themethods listed in section 3.2.2.3.

Qualified Certificate forElectronic Signature

Verification of the authenticity of the individual Applicant’s request
with the methods listed in section 3.2.3.4.

Alternative to any reliable means of communication with the organization, authority can be
confirmed using either:• an advanced (or higher) electronic seal which includes the name of the organization, its
parent, subsidiary or affiliate; or• an advanced (or higher) electronic signature which includes the name of the organization,
its parent, subsidiary or affiliate. In this case, GlobalSign will verify that the individual has
been appropriately verified as either a confirmed employee or an agent of the organization
listed in the certificate.; or• an advanced (or higher) electronic signature of a confirmed employee or agent of theorganization.
3.2.6

Criteria for Interoperation

Cross Certificates are published in the GlobalSign Repository.
3.2.7

Authentication of Domain Names

For all SSL Certificates, authentication of the Applicant’s (or the Applicant’s parent company’s,
subsidiary company’s, or Affiliate’s, collectively referred to as “Applicants” for the purposes of thissection) ownership or control of all requested FQDN(s) is done using one of the following methods:
1. Having the Applicant demonstrate control over the requested FQDN by sending a Random
Value to a Domain Contact via email and then receiving a confirming response utilizing theRandom Value. (TLS BR section 3.2.2.4.2); or
2. Having the Applicant demonstrate control over the requested FQDN by sending a Random
Value to an email address created by prepending ‘admin’, ‘administrator’, ‘webmaster’,‘hostmaster’, or ‘postmaster’ in the local part, followed by the at-sign (“@”), followed by an
Authorization Domain Name and obtaining a response utilizing the Random Value (TLS
BR section 3.2.2.4.4); or
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

51 of 98

GlobalSign Certification Practice Statement

3. Having the Applicant demonstrate control over the requested FQDN by confirming thepresence of a Random Value in a DNS CNAME or TXT record on an Authorization Domain
Name (TLS BR section 3.2.2.4.7); or
4. Having the Applicant demonstrate control over the requested FQDN by sending a Random
Value to an email address sent to a DNS CAA Email Contact. The relevant CAA Resource
Record Set must be found using the search algorithm defined in RFC 8659 Section 3 (TLS
BR section 3.2.2.4.13); or
5. Having the Applicant demonstrate control over the requested FQDN by sending a Random
Value to a DNS TXT Record Email Contact via email and then receiving a confirming
response utilizing the Random Value (TLS BR section 3.2.2.4.14); or
6. Having the Applicant demonstrate control over the requested FQDN by calling the Domain
Contact’s phone number and obtaining a response confirming the Applicant's request forvalidation of the FQDN. (TLS BR section 3.2.2.4.15); or
7. Having the Applicant demonstrate control over the requested FQDN by calling the DNS
TXT Record Phone Contact’s phone number and obtaining a confirming response tovalidate the ADN. (TLS BR section 3.2.2.4.16); or
8. Having the Applicant demonstrate control over the requested FQDN by confirming thepresence of a Random Value within a file under the "/.well-known/pki-validation" directoryon an Authorization Domain Name that is accessible by the CA via HTTP/HTTPS over an
Authorized Port. (TLS BR section 3.2.2.4.18), or
9. Having the Applicant demonstrate control over the requested FQDN by validating domain
control of the FQDN using the ACME HTTP Challenge method defined in Section 8.3 of
RFC 8555 in accordance with BR section 3.2.2.4.19. (TLS BR section 3.2.2.4.19).
GlobalSign uses the methods above except for method 9 (TLS BR 3.2.2.4.18) and method 10 (TLS
BR 3.2.2.4.19) for validating Wildcard FQDNs. Following redirects is supported for methods 9 (TLS
BR 3.2.2.4.18 and 10 (TLS BR 3.2.2.4.19).
3.2.7.1

CAA Records

GlobalSign validates each server FQDN in publicly trusted SSL Certificates against the domain's
CAA records. GlobalSign's CAA issuer domain is "globalsign.com." If a CAA record exists that does
not list globalsign.com as an authorized CA, GlobalSign will not issue the Certificate. GlobalSign:• caches CAA records for reuse for up to 8 hours• supports the issue and issuewild CAA tags
• processes but does not act on iodef property tag (i.e., GlobalSign does not dispatch reportsof such issuance requests to the contact(s) stipulated in the CAA iodef record(s))• does not support any additional property tags
3.2.8

Authentication of IP Addresses

GlobalSign uses the following methods to confirm that the Applicant has control of or right to use
IP addresses:
1. Having the Applicant demonstrate control over the requested IP address by confirming thepresence of a Random Value within a file under the "/.well-known/pki-validation" directorythat is accessible by the CA via HTTP/HTTPS over an Authorized Port. (TLS BR section
3.2.2.5.1)
2. Having the Applicant demonstrate control of the IP address by sending a Random Valueto an IP Address Contact via email and then receiving a confirming response utilizing theRandom Value (TLS BR section 3.2.2.5.2); or,
3. Performing a reverse IP address lookup and then verifying control over the resulting
Domain Name using one of the options in section 3.2.7 (TLS BR section 3.2.2.5.3); or
4. Confirming the Applicant's control over the IP Address by calling the IP Address Contact’s
phone number and obtaining a response confirming the Applicant's request for validationof the IP Address (TLS BR section 3.2.2.5.5).
3.2.9

Authentication of Email Addresses

GlobalSign uses the following methods to confirm that the Applicant has control of or right to use
email addresses:

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

52 of 98

GlobalSign Certification Practice Statement

1. Verifying the entity's control over the domain portion of the Mailbox Address to be used in
the Certificate (S/MIME BR Section 3.2.2.1); or
2. Confirming the Applicant's control over each Mailbox Field to be included in a Certificate
by sending a Random Value via email and then receiving a confirming response utilizing
the Random Value (S/MIME BR Section 3.2.2.2).

3.3

Identification and Authentication for Re-key Requests

GlobalSign supports re-key requests from Subscribers prior to the expiry of the Subscriber’s
existing Certificate.
3.3.1

Identification and Authentication for Routine Re-key

For products supporting re-key, authentication of the re-key request is based on the authentication
mechanism provided during the initial issuance of the Certificate, or equivalent.
Identification of the request is subject to the re-use conditions specified in section 4.2.1. If at any
point any information included in a Certificate is changed in any way, additional validation must be
performed.
3.3.2

Identification and Authentication for Re-key After Revocation

A routine re-key after revocation is not supported. Re-key after revocation of a Certificate requires
the Subscriber to follow the initial validation process that was previously completed to allow theinitial issuance of the Certificate.

3.4

Identification and Authentication for Revocation Request

All revocation requests are authenticated by GlobalSign or RA. Revocation requests may be
granted following a suitable challenge response such as, logging into an account with the username
and password, proving possession of unique elements incorporated into the Certificate (e.g.,
Domain Name or email address), or authentication of specific information from within the accountwhich is authenticated out of band.
GlobalSign may also perform revocation on behalf of Subscribers in accordance with the CPS
and/or Subscriber Agreement.

4.0 Certificate Lifecycle Operational Requirements
4.1
4.1.1

Certificate Application
Who Can Submit a Certificate Application

GlobalSign maintains its own blocklists of individuals from whom and entities from which it will not
accept Certificate applications. In addition, other external sources such as government denied lists
or internationally recognized denied persons lists which are applicable to the jurisdictions in which
GlobalSign operates are used to screen out unwanted Applicants.
GlobalSign does not issue Certificates to entities that reside in Countries where the laws of a
GlobalSign office location prohibit doing business.
EV Guidelines highlight the specific rules to follow in order to obtain an Extended Validation SSL /Extended Validation Code Signing Certificate. Applicants must submit and agree to a Certificate
request and Subscriber Agreement, which may be electronic or pre-authorized depending upon thenature of the service required from GlobalSign.
4.1.2

Enrollment Process and Responsibilities

Prior to the issuance of a Certificate, GlobalSign obtains a Certificate request and an executed
Subscriber Agreement and/or Terms of Use in accordance with the applicable CA/Browser Forum
Requirements.
GlobalSign maintains systems and processes that sufficiently authenticate the Applicant’s identity
for all Certificate types that present the identity to Relying Parties. Applicants must submit sufficient
information to allow GlobalSign and any GlobalSign RA to successfully perform the required
verification. GlobalSign and RAs shall protect communications and securely store information

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

53 of 98

GlobalSign Certification Practice Statement

presented by the Applicant during the application process in compliance with the GlobalSign
Privacy Policy.
Generally, the application process includes the following steps (but not necessarily in this order assome workflow processes generate Key Pairs after the validation has been completed):
•
•
•
•
•

4.2

Generating a suitable Key Pair using a suitably secure platform.
Generating a Certificate Signing Request (CSR) using an appropriately secure tool.
Submitting a request for a Certificate type and appropriate application information.
Agreeing to a Subscriber Agreement or other applicable terms and conditions; andPaying any applicable fees.

Certificate Application Processing

4.2.1

Performing Identification and Authentication Functions

GlobalSign maintains systems and processes to sufficiently authenticate the Applicant’s identity incompliance with this CPS.
Initial identity vetting may be performed by GlobalSign’s validation team as set forth in Section 3.2
or by Registration Authorities under contract. All communications sent through as faxes/email are
securely stored along with all information presented directly by the Applicant via the GlobalSign
web interface or API. Future applications for Certificates are authenticated using single (username
and password) or multi-factor (Certificate in combination with username/password) authentication
techniques.
GlobalSign may use the documents and data provided in Section 3.2 to verify Certificate
information, or may reuse previous validations themselves, provided that:
•
•
•

•

GlobalSign obtained the data or document from a source specified under Section 3.2 orcompleted the validation itself no more than 825 days prior to issuing the Certificate;
For S/MIME BR Certificates, for validation of mailbox authorization or control: any reused
data, document, or completed validation has been obtained no more than 398 days prior
to issuing the Certificate;
For SSL Certificates, for validation of Domain Names and IP Addresses according to
Section 3.2.2.4 and 3.2.2.5 of the Baseline Requirements for TLS, any reused data,
document, or completed validation has been obtained no more than 398 days prior toissuing the Certificate; andFor EV SSL and EV Code Signing Certificates, GlobalSign obtained the data or documentfrom a source specified under Section 3.2 or completed the validation itself no more than
398 days prior to issuing the Certificate. Except for reissuance of an EV Certificate under
Section 11.14.2 and except when permitted otherwise in Section 11.14.1 of the EV
Guidelines.

In some cases, GlobalSign may rely on a contract with the Applicant that specifies a different term
for the validation of authority, verified in accordance with section 3.2.5. For example, the contract
may include the perpetual assignment of roles until revoked by the Applicant or CA, or until thecontract expires or is terminated. GlobalSign may establish a process that allows an Applicant tospecify the Individuals who may request Certificates. In case of Local Registration Authorities, theAuthority of the Local Registration Authority will be verified at the time of the set-up of the profile.
This authority may remain valid until revoked.
Customers may request a replacement certificate (“reissue”), which follows the process of a newcertificate. Where applicable, Certificate information may be reused.
If at any point any Subject name information embodied in a Certificate is changed in any way, theprocedures outlined in herein must be re-performed.
4.2.2

Approval or Rejection of Certificate Applications

GlobalSign shall reject requests for Certificates where validation of all items cannot be successfullycompleted.
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

54 of 98

GlobalSign Certification Practice Statement

Assuming all validation steps can be completed successfully following the procedures in this CPS,
then GlobalSign shall generally approve the Certificate request. GlobalSign may reject applications
including for the following reasons:•GlobalSign may reject requests based on potential brand damage to GlobalSign inaccepting the request.
•
GlobalSign may also reject applications for Certificates from Applicants who havepreviously been rejected or have previously violated a provision of their Subscriber
Agreement.
GlobalSign is under no obligation to provide a reason to an Applicant for rejection of a Certificate
request.
For Extended Validation, Qualified and Code Signing Certificates, separation of duties requires two
members of the validation team to approve the request. GlobalSign operates in many jurisdictions;however, it may choose to outsource a pre-vetting function to suitably trained and experienced
external RA partners who have additional relevant language and local jurisdiction knowledge to beable to process and/or translate documentation that is not in a language that GlobalSign itself canprocess internally.
GlobalSign does not issue publicly trusted SSL Certificates to Internal Names or Reserved IP
Addresses.
4.2.3

Time to Process Certificate Applications

GlobalSign shall ensure that all reasonable methods are used to evaluate and process Certificate
applications. Where issues outside of the control of GlobalSign occur, GlobalSign shall strive tokeep the Applicant duly informed.
For Extended Validation Certificates, GlobalSign first validates that all information provided by the
Applicant is correct before requesting the contract signer to approve the Subscriber Agreement.
The following approximations are given for processing and issuance.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

4.3
4.3.1

PersonalSign1 Certificates Approximately 1 minute
PersonalSign2 Certificates Approximately 24-48 business hours
PersonalSign2 Pro Certificates Approximately 36-72 business hours
NAESB Certificates Approximately 24-48 business hours
PersonalSign3 Pro Certificates Approximately 48-72 business hours
Code Signing Certificates Approximately 24-48 business hours
EV Code Signing Certificates Approximately 48-96 business hours
DV SSL Certificates Approximately3 1-5 minutes
AlphaSSL Certificates Approximately4 1-5 minutes
OV SSL Certificates Approximately 24-48 business hours
EV SSL Certificates Approximately 48-96 business hours
Qualified Certificates Approximately 48-96 business hours
Timestamping Certificates Approximately 5-10 business days
AATL Certificates Approximately 24-48 business hours
S/MIME Certificates Approximately 48-72 business hours

Certificate IssuanceCA Actions during Certificate Issuance

Certificate issuance by GlobalSign Root CA requires an authorized Trusted Role member from
GlobalSign to issue a direct command for the Root CA to perform a certificate signing operation.

4

In cases where the Domain Name to be validated for a DV/Alpha SSL Certificate is deemed to be high risk,
the process followed will be closer to the processing time for OV SSL.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

55 of 98

GlobalSign Certification Practice Statement

GlobalSign shall ensure it communicates with any RA accounts capable of causing Certificate
issuance using multi-factor authentication. This includes RAs directly operated by GlobalSign or
RAs contracted by GlobalSign. RAs shall perform validation of all information sent to the CA andensure that any database used to store any information is suitably protected from unauthorized
modification or tampering.
4.3.2

Notifications to Subscriber by the CA of Issuance of Certificate

GlobalSign or RA shall notify the Subscriber of the issuance of a Certificate at an email address
which was supplied by the Subscriber during the enrollment process or by any other equivalentmethod. The email may contain the Certificate itself or a link to download depending upon theworkflow of the Certificate requested.

4.4
4.4.1

Certificate Acceptance
Conduct Constituting Certificate Acceptance

GlobalSign shall inform the Subscriber that s/he may not use the Certificate until the Subscriber
has reviewed and verified the accuracy of the data incorporated into the Certificate. Unless the
Subscriber notifies GlobalSign within seven (7) days from receipt, the Certificate is deemed
accepted.
4.4.2

Publication of the Certificate by the CA

GlobalSign publishes the Certificate by delivering it to the Subscriber and may also publish to one
or more Certificate Transparency Logs. In addition, for Enterprise PKI customers GlobalSign may
publish the Certificate into a directory such as LDAP.
4.4.3

Notification of Certificate Issuance by the CA to Other Entities

RAs, local RA, partners/resellers, GlobalSign and other entities may be informed of the issuance ifthey were involved in the initial enrollment.

4.5
4.5.1

Key Pair and Certificate Usage
Subscriber Private Key and Certificate Usage

Subscribers must protect their Private Key taking care to avoid disclosure to third parties.
GlobalSign’s Subscriber Agreement identifies the obligations of the Subscriber with respect toPrivate Key protection. Private Keys must only be used as specified in the appropriate key usage
and extended key usage fields as indicated in the corresponding Certificate.
For Qualified Certificates where the Private Key related to the certified Public Key resides in a
QSCD, Subscriber keys must be generated and stored within a recognized Qualified Signature
Creation Device (QSCD).
For Non-EV Code Signing Certificates issued prior to April 24, 2023, the Subscriber’s private key
should be generated, stored and used in a crypto module which meets the requirements of FIPS
140-2 level 2 or Common Criteria EAL 4+ or within a Trusted Platform Module (TPM) that generates
and secures a key pair and that can document the Subscriber’s private key protection through a
TPM key attestation.
For EV Code Signing Certificates issued prior to April 24, 2023, the Subscriber’s private key mustbe generated, stored and used in a crypto module that meets or exceeds the requirements of FIPS
140-2 level 2 or Common Criteria EAL 4+.
Effective April 24, 2023, Subscriber Private Keys for EV and Non-EV Code Signing Certificatesmust be generated and protected in a Hardware Crypto Module with a unit design form factor
certified as conforming to at least FIPS 140‐2 Level 2 or Common Criteria EAL 4+.
Where it is possible to make a backup of a Private Key, Subscribers must use the same level ofcare and protection attributed to the live Private Key. At the end of the useful life of a Private Key,
Subscribers must securely delete the Private Key and any fragments that it has been split into forthe purposes of backup.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

56 of 98

GlobalSign Certification Practice Statement

In the case of GlobalSign’s digital signing service, and with the consent of the Subscriber,
GlobalSign shall host, secure, and manage short-lived Certificates and corresponding Private Keys
in a conformant HSM/QSCD.
See Section 9.6.3, provisions 2. and 4.
4.5.2

Relying Party Public Key and Certificate Usage

Within this CPS GlobalSign provides the conditions under which Certificates may be relied upon by
Relying Parties including the appropriate Certificate services available to verify Certificate validity
such as CRL and/or OCSP. GlobalSign provides a Relying Party agreement to Subscribers, thecontent of which should be presented to the Relying Party. Relying Party must accept and act inaccordance with the Relying Party Agreement prior to reliance upon a Certificate from GlobalSign.
Relying Parties should use the information to make a risk assessment and as such are solely
responsible for performing the risk assessment prior to relying on the Certificate or any assurances
made.
Software used by Relying Parties should be fully compliant with X.509 standards including bestpractice for chaining decisions around policies and key usage.

4.6

Certificate Renewal

Certificate renewal means the issuance of a Certificate with a new validity period ending after thevalidity period of the old Certificate, but without changing the Subscriber or other participant's Public
Key or any other information in the Certificate.
Certificate renewal requests are processed as new Certificate requests when Subscriber or otherparticipant’s Public Key or any other information in the Certificate is different.
4.6.1

Circumstances for Certificate Renewal

If supported for the product, Certificate renewal may be performed upon request of the Subscriber,
an authorized representative of Subscriber or by GlobalSign at its sole discretion.
Certificate renewal can only be performed if the original Certificate has not been revoked.
4.6.2

Who May Request Renewal

Requests for renewal must be submitted by the Subscriber of the Certificate or their authorized
representative.
4.6.3

Processing Certificate Renewal Requests

To process a renewal request, GlobalSign verifies the request with Subscriber or their authorized
representative.
Certificate renewal requests are processed as new Certificate requests.
4.6.4

Notification of New Certificate Issuance to Subscriber

As per 4.3.2
4.6.5

Conduct Constituting Acceptance of a Renewal Certificate

As per 4.4.1
4.6.6

Publication of the Renewal Certificate by the CA

As per 4.4.2
4.6.7

Notification of Certificate Issuance by the CA to Other Entities

No stipulation

4.7

Certificate Re-Key

Certificate re-key means the issuance of a new Certificate with a different Public Key, but withoutchanging the validity period or any other information in the Certificate.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

57 of 98

GlobalSign Certification Practice Statement

Certificate re-key requests are processed as new Certificate requests when the validity period ischanged or any other information in the Certificate is different.
4.7.1

Circumstances for Certificate Re-Key

If supported for the product, Certificate re-key may be performed upon request of the Subscriber,
an authorized representative of Subscriber or by GlobalSign at its sole discretion.
Certificate re-key may be requested upon compromise of the Certificate Private Key.
4.7.2

Who May Request Certification of a New Public Key

Requests for re-key must be submitted by the Subscriber of the Certificate or their authorized
representative.
4.7.3

Processing Certificate Re-Keying Requests

To process a re-key request, GlobalSign verifies the request with the Subscriber or their authorized
representative.
Certificate re-key requests are processed as new Certificate requests.
4.7.4

Notification of New Certificate Issuance to Subscriber

As per 4.3.2
4.7.5

Conduct Constituting Acceptance of a Re-Keyed Certificate

As per 4.4.1
4.7.6

Publication of the Re-Keyed Certificate by the CA

As per 4.4.2
4.7.7

Notification of Certificate Issuance by the CA to Other Entities

No stipulation

4.8

Certificate Modification

Certificate modification means issuance of a new Certificate due to changes in the information in
the Certificate other than the Subscriber Public Key.
Certificate modification requests are processed as new Certificate requests when the validity period
is changed or the Subscriber Public Key is different.
4.8.1

Circumstances for Certificate Modification

If supported for the product, Certificate modification may be performed upon request of the
Subscriber, an authorized representative of Subscriber or by GlobalSign at its sole discretion.
4.8.2

Who May Request Certificate Modification

Requests for modification must be submitted by the Subscriber of the Certificate or their authorized
representative.
4.8.3

Processing Certificate Modification Requests

To process a modification request, GlobalSign verifies the request with Subscriber or theirauthorized representative.
Certificate modification requests are processed as new Certificate requests.
4.8.4

Notification of New Certificate Issuance to Subscriber

As per 4.3.2
4.8.5

Conduct Constituting Acceptance of Modified Certificate

As per 4.4.1

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

58 of 98

GlobalSign Certification Practice Statement

4.8.6

Publication of the Modified Certificate by the CA

As per 4.4.2
4.8.7

Notification of Certificate Issuance by the CA to Other Entities

No stipulation

4.9

Certificate Revocation and Suspension

4.9.1

Circumstances for Revocation

Prior to performing a revocation GlobalSign will verify the authenticity of the revocation request.
GlobalSign may revoke any Certificate at its sole discretion.
Revocation of a Subscriber Certificate is performed within twenty-four (24) hours under thefollowing circumstances:
1. The Subscriber requests in writing (to GlobalSign which provided the Certificate) that theywish to revoke the Certificate.
2. The Subscriber notifies GlobalSign that the original Certificate request was not authorized
and does not retroactively grant authorization.
3. GlobalSign obtains reasonable evidence that the Subscriber's Private Key corresponding
to the Public Key in the Certificate suffered a Key Compromise.
4. GlobalSign is made aware of a demonstrated or proven method that can easily compute
the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debianweak key, see https://wiki.debian.org/SSLkeys);
5. GlobalSign obtains evidence that the validation of domain authorization or control for any
Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon.
6. GlobalSign obtains evidence that the validation of domain authorization or mailbox control
for any Mailbox Address in the Certificate should not be relied upon.
7. GlobalSign receives notice or otherwise becomes aware of unexpected termination of a
Subscriber's or Subject's agreement or business functions.
8. In case of PSD2 Certificates, GlobalSign receives an authenticated revocation request (orauthenticates a revocation request) that originated from the NCA which has authorized orregistered the payment service provider, and which includes a valid reason for revocation.
Valid reasons for revocation include when the authorization of the PSP has been revokedor any PSP role included in the Certificate has been revoked.
Revocation of a Subscriber’s Certificate should be performed within twenty-four (24) hours and is
performed within 5 days if one or more of the following occurs:
1. The Certificate no longer complies with the requirements for algorithm type and key size ofthe applicable CA/Browser Forum Requirements, as specified in Sections 6.1.5 and 6.1.6.
2. GlobalSign obtains evidence that the Certificate was misused.
3. GlobalSign receives notice or otherwise becomes aware that the Subscriber violated anyof its material obligations under the Subscriber Agreement or Terms of Use.
4. GlobalSign is made aware of any circumstance indicating that use of a Fully-Qualified
Domain Name 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, a
relevant licensing or services agreement between the Domain Name Registrant and theApplicant has terminated, or the Domain Name Registrant has failed to renew the DomainName).
5. GlobalSign is made aware of any circumstance indicating that use of an email address or
Fully-Qualified Domain Name in the Certificate is no longer legally permitted (e.g., a court
or arbitrator has revoked the right to use an email address or Domain Name, a relevant
licensing or services agreement between the Subscriber has terminated, or the accountholder has failed to maintain the active status of the email address or Domain Name);
6. GlobalSign receives notice or otherwise becomes aware of a material change in theinformation contained in the Certificate.
7. GlobalSign is made aware that the Certificate was not issued in accordance with theapplicable CA/Browser Forum Requirements or GlobalSign’s CP or CPS.
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

59 of 98

GlobalSign Certification Practice Statement

8. GlobalSign determines that any of the information appearing in the Certificate is inaccurate.
9. GlobalSign’s right to issue Certificates under the CA/Browser Forum Requirements expires
or is revoked or terminated, unless GlobalSign has made arrangements to continue
maintaining the CRL/OCSP Repository.
10. Revocation is required by GlobalSign’s CP and/or CPS.
11. GlobalSign is made aware of a demonstrated or proven method that exposes the
Subscriber’s Private Key to compromise or if there is clear evidence that the specificmethod used to generate the Private Key was flawed.
12. GlobalSign is made aware that a Wildcard Certificate has been used to authenticate afraudulently misleading subordinate Fully-Qualified Domain Name.
13. The technical content or format of the Certificate presents an unacceptable risk to
Application Software Suppliers or Relying Parties (e.g., the CA/B Forum might determinethat a deprecated cryptographic/signature algorithm or key size presents an unacceptablerisk and that such Certificates should be revoked and replaced by CAs within a given periodof time).
14. GlobalSign receives notice or otherwise becomes aware of any circumstance indicatingthat use of the email address in the Certificate is no longer legally permitted.
15. The CA Private Key used in issuing the Certificate is suspected to have been compromised.
16. GlobalSign ceases operations for any reason and has not arranged for another CA toprovide revocation support for the Certificate.
17. The Certificate was issued in violation of the then-current version of the Mozilla Root Store
Policy.
Revocation of a Subscriber Certificate may also be performed within a commercially reasonable
period of time under the following circumstances:
1. The Subscriber or organization administrator requests revocation of the Certificate througha customer account which controls the lifecycle of the Certificate.
2. The Subscriber requests revocation through an authenticated request to GlobalSign's
support team or GlobalSign’s Registration Authority.
3. GlobalSign receives notice or otherwise becomes aware that the Subscriber has been
added as a denied party or prohibited person to a blocklist or is operating from a prohibited
destination under the laws of GlobalSign's jurisdiction of operation.
4. The Subscriber was added as a denied party or is otherwise designated or subject toeconomic sanctions or other restrictions pursuant to applicable laws.
5. Overdue payment of applicable fees by the Subscriber.
6. Following the request for cancellation of a Certificate.
7. If a Certificate has been re-issued, GlobalSign may revoke the previously issued
Certificate.
8. Under certain licensing arrangements, GlobalSign may revoke Certificates following
expiration or termination of the license agreement.
9. GlobalSign determines the continued use of the Certificate is otherwise harmful to thebusiness of GlobalSign or third parties. When considering whether Certificate usage isharmful to GlobalSign’s or a third party’s business or reputation, GlobalSign will consider,among other things, the nature and number of complaints received, the identity of thecomplainant(s), relevant legislation in force, and responses to the alleged harmful use by
the Subscriber.
10. If Microsoft, in its sole discretion, identifies a certificate whose usage or attributes are
determined to be contrary to the objectives of the Trusted Root Program, Microsoft will
notify GlobalSign and request that it revoke the certificate. GlobalSign will either revoke thecertificate or request an exception from Microsoft within 24 hours of receiving Microsoft's
notice. Microsoft will review submitted material and inform GlobalSign of its final decision
to grant or deny the exception at its sole discretion. In the event that Microsoft does notgrant the exception, GlobalSign will revoke the certificate within 24 hours of the exception
being denied.
11. Death of a Subscriber.
Revocation of a Subordinate CA Certificate is performed within seven (7) days under the following
circumstances:

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

60 of 98

GlobalSign Certification Practice Statement

1. The Subordinate CA requests in writing to the GlobalSign entity which provided theSubordinate CA Certificate, or the authority detailed in Section 1.5.2 of this CPS, that
GlobalSign revoke the Certificate.
2. The Subscriber notifies GlobalSign that the original Certificate request was not authorized
and does not retroactively grant authorization.
3. GlobalSign obtains reasonable evidence that the Subordinate CA’s Private Key
corresponding to the Public Key in the Certificate suffered a Key Compromise or no longer
complies with the requirements for algorithm type and key size of the applicable
CA/Browser Forum Requirements as specified in Sections 6.1.5 and 6.1.6.
4. GlobalSign obtains evidence that the Certificate was misused.
5. GlobalSign is made aware that the Certificate was not issued in accordance with or that
the Subordinate CA has not complied with the applicable CA/Browser Forum Requirements
or applicable CP or CPS.
6. GlobalSign determines that any of the information appearing in the Certificate is inaccurate
or misleading.
7. GlobalSign or a Subordinate CA ceases operations for any reason and has not arranged
for another CA to provide revocation support for the Certificate.
8. GlobalSign’s or a Subordinate CA’s right to issue Certificates under the applicable
CA/Browser Forum Requirements expires or is revoked or terminated, unless the issuing
CA has made arrangements to continue maintaining the CRL/OCSP Repository.
9. Revocation is required by the Issuing CA’s CP and/or CPS.
10. The technical content or format of the Certificate presents an unacceptable risk to
Application Software Suppliers or Relying Parties (e.g., the CA/B Forum might determinethat a deprecated cryptographic/signature algorithm or key size presents an unacceptablerisk and that such Certificates should be revoked and replaced by CAs within a given periodof time).
If Subscriber requests revocation, the applicable revocation reason can be provided:• Unspecified: When the reason codes below do not apply to the revocation request, theSubscriber must not provide a reason code other than "unspecified".
• keyCompromise: When there is reason to believe that the Private Key of their Certificate
has been compromised, e.g. an unauthorized person has had access to the Private Keyof their Certificate.
• cessationOfOperation: When they no longer own all of the domain names in theCertificate or when they will no longer be using the Certificate because they are
discontinuing their website.
• affiliationChanged: When their organization's name or other organizational information in
the Certificate has changed.
• Superseded: When they request a new Certificate to replace their existing Certificate.
If the revocation reason is not specified by the Subscriber, the “unspecified” revocation reason isused.
For short-term Certificates issued through the GlobalSign Document Signing Service andQualified Signing Service, revocation by the Subscriber is not supported.
4.9.2

Who Can Request Revocation

GlobalSign, RA or Subscriber can initiate revocation. Only authenticated requests for revocation
are accepted. Authorization for revocation shall be accepted if the revocation request is received
from either the Subscriber or an affiliated organization named in the Certificate. Subscribers,
Relying Parties, Application Software Suppliers, and other third parties may submit Certificate
Problem Reports to notify GlobalSign of a suspected reasonable cause to revoke the Certificate.
Additionally, for Open Banking Certificates, revocation requests can originate from the NCA which
has authorized or registered the payment service provider. GlobalSign may also at its own
discretion revoke Certificates including Certificates that are issued to other cross signed CAs.
4.9.3

Procedure for Revocation Request

Due to the nature of revocation requests and the need for efficiency, GlobalSign provides
automated mechanisms for requesting and authenticating revocation requests. The primary
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

61 of 98

GlobalSign Certification Practice Statement

method is through the customer account used to issue the Certificate that is requested to be
revoked. Alternative out of band methods may be used, such as receipt of a fax/letter/phone call,the origins of which must be authenticated using shared secrets from the customer account.
Alternatively, where customer accounts are not provided, methods may be used which rely on ademonstration of control of one or more elements of the Subject DN of the Certificate. For S/MIME
Certificates, it could include demonstration of control of the email address. GlobalSign and its RAs
will record each request for revocation and authenticate the source, taking appropriate action to
revoke the Certificate if the request is authentic and approved.
Subscribers, Relying Parties, Application Software Suppliers, and other third parties may submit
Certificate Problem Report via report-abuse@globalsign.com. GlobalSign may or may not revokein response to this request. See section 4.9.5 for detail of actions performed by GlobalSign formaking this decision.
If revoked, the serial number of the Certificate and the date and time shall be added to theappropriate CRL. CRL reason codes may be included. CRLs are published according to this CPS.
4.9.4

Revocation Request Grace Period

For SSL and Code Signing Certificates, GlobalSign does not support a revocation request grace
period.
For all other Certificates, the revocation request grace period is the time available for a Subscriber
to take any necessary actions themselves to request revocation of a suspected Key Compromise,use of a weak key or discovery of inaccurate information within an issued Certificate. A risk analysis
shall be completed and recorded for any revocations that cannot be processed by either party for
any reason.
Subscribers have 48 hours to inform GlobalSign of a key compromise.
4.9.5

Time Within Which CA Must Process the Revocation Request

All revocation requests for end entity Certificates, both those generated automatically via user
accounts and those initiated by GlobalSign itself, must be processed within a maximum of 24 hours
of receipt.
GlobalSign maintains 24 x 7 ability to respond internally to a high-priority Certificate Problem Report
and, where appropriate, forward such a complaint to law enforcement authorities, and/or revoke a
Certificate that is the subject of such a complaint. GlobalSign will begin investigation procedures
for a suspected Key Compromise or misuse of a Certificate within 24 hours of receipt of the report.
GlobalSign decides whether revocation or other action is warranted based on at least the following
criteria:
•
•
•
•
4.9.6

The nature of the alleged problem.
The number of reports received about a particular Certificate or Subscriber.
The entity making the complaint; andRelevant legislation.
Revocation Checking Requirements for Relying Parties

Prior to relying upon a Certificate, Relying Parties must validate the suitability of the Certificate forthe intended purpose and ensure the Certificate is valid, otherwise all warranties become void.
Relying Parties will need to consult the CRL or OCSP information for each Certificate in the chain
as well as validating that the Certificate chain itself is complete. This may include the validation of
Authority Key Identifier (AKI) and Subject Key Identifier (SKI). For Qualified Certificates, validationof the certificate chain must be carried out successfully up to the GlobalSign trust anchor within the
EU or UK eIDAS trusted list.
Relying Parties should note that because CRLs are issued at set time frames there may be a period
directly after revocation and before next CRL generation where OCSP and CRL do not return the

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

62 of 98

GlobalSign Certification Practice Statement

same status. In cases where differences between CRL and OCSP occur, OCSP should bepresumed to be most accurate.
GlobalSign includes applicable URLs within the Certificate to aid Relying Parties in performing the
revocation checking process.
4.9.7

CRL Issuance Frequency

Each CRL includes a monotonically increasing sequence number for each CRL issued.
If GlobalSign decides or is required to terminate a CRL or revoke an Issuing CA, GlobalSign issues
and publishes at the corresponding CRL Distribution Point a last CRL with a nextUpdate field valueof “99991231235959Z”. GlobalSign does not issue a last CRL until all Certificates in the scope of
the CRL are either expired or revoked. The last CRL is made available until the expiry of the Issuing
CA certificate and the integrity of the CRL is preserved during this period.
For the status of Subscriber Certificates:
For CAs that publish a CRL, the CRL will be updated and re-issued at least once every seven days
(every 24 hours for Qualified Certificates), and the value of the nextUpdate field will not be morethan ten days beyond the value of the thisUpdate field.
For the status of Subordinate CA Certificates:
If the Subordinate CA contains a CDP, CRLs will be updated and re-issued at least (i) once every
3 months and (ii) within 24 hours after revoking a Subordinate CA Certificate, and the value of the
nextUpdate field will not be more than twelve months beyond the value of the thisUpdate field.
4.9.8

Maximum Latency for CRLs

CRLs are posted to the repository within a commercially reasonable time after generation.
4.9.9

On-Line Revocation/Status Checking Availability

Where GlobalSign supports OCSP responses in addition to CRLs, OCSP response times are
generally no longer than 10 seconds under normal network operating conditions.
GlobalSign OCSP responses conform to RFC6960 and/or RFC5019. OCSP responses are signedby an OCSP Responder whose Certificate is signed by the CA that issued the Certificate whose
revocation status is being checked. OCSP signing Certificate contains an extension of type id-pkixocsp-nocheck, as defined by RFC6960.
4.9.10 On-Line Revocation Checking Requirements
OCSP responders operated by GlobalSign support the HTTP GET method, as described in RFC
6960 and/or RFC 5019.
The validity interval of an OCSP response is the difference in time between the thisUpdate andnextUpdate field, inclusive. For purposes of computing differences, a difference of 3,600 seconds
shall be equal to one hour, and a difference of 86,400 seconds shall be equal to one day, ignoring
leap‐seconds.
For the status of Subscriber Certificates:
1. OCSP responses have a validity interval greater than or equal to eight hours.
2. OCSP responses have a validity interval less than or equal to ten days.
3. For OCSP responses with validity intervals less than sixteen hours, GlobalSign updates
the information provided via an Online Certificate Status Protocol prior to one-half of thevalidity period before the nextUpdate.
4. For OCSP responses with validity intervals greater than or equal to sixteen hours,
GlobalSign updates the information provided via an Online Certificate Status Protocol atleast eight hours prior to the nextUpdate, and no later than four days after the thisUpdate.
For the status of Subordinate CA Certificates:• GlobalSign updates information provided via an OCSP Responder (i) at least every twelve
months and (ii) within 24 hours after revoking a Subordinate CA Certificate.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

63 of 98

GlobalSign Certification Practice Statement

OCSP Responders that receive a request for status of a Certificate that has not been issued, shallnot respond with a "good" status for such Certificates.
OCSP Responders for CAs which are not Technically Constrained, in line with Section 7.1.5, will
not respond with a "good" status for such Certificates.
GlobalSign requires OCSP requests to contain the following data:• Protocol version• Service request• Target Certificate identifier
A Certificate serial number within an OCSP request is one of the following three options:
1. “assigned” if a Certificate with that serial number has been issued by the Issuing CA, using
any current or previous key associated with that CA subject; or
2. “reserved” if a Precertificate [RFC6962] with that serial number has been issued bya. the Issuing CA; or
b. a Precertificate Signing Certificate associated with the Issuing CA; or
3. “unused” if neither of the previous conditions are met
4.9.11 Other Forms of Revocation Advertisements Available
No stipulation.
4.9.12 Special Requirements Related to Key Compromise
GlobalSign and any of its Registration Authorities shall use commercially reasonable methods toinform Subscribers that their Private Key may have been Compromised. This includes cases where
new vulnerabilities have been discovered or where GlobalSign at its own discretion decides that
evidence suggests a possible Key Compromise has taken place. Where Key Compromise is not
disputed, GlobalSign shall revoke Issuing CA Certificates or Subscriber end entity Certificateswithin 24 hours and publish online CRLs within 30 minutes of creation and ARLs within 12 hours.
Parties may use the following methods to demonstrate key Compromise:• Submission of a CSR file, created and signed by the private key. The CSR file needs tocontain one of the following:o A specific string that GlobalSign has provided to the reporter.
ORo A string of text that clearly indicates compromise.
••

Providing references to vulnerability and/or security incident sources from which theCompromise is verifiable
Submission of binaries that contain a Compromised Private Key, including the method to
extract the Private Key

GlobalSign will analyze other requests and update the CPS accordingly if the new method ofsubmission is accepted.
4.9.13 Circumstances for Suspension
Certificate suspension is allowed in EPKI customers. Certificate suspension can be used when an
EPKI administrator wants to disable client Certificates temporarily. Such situations may
include temporary loss of Certificates and temporary leave of users from organization, etc. Unlike
certificate revocation which disables a Certificate permanently, Certificate suspension status canbe lifted by an EPKI administrator to reactivate the Certificate.
Certificate suspension is not supported for SSL, Code Signing, timestamping or Qualified
Certificates.
4.9.14 Who Can Request Suspension
EPKI administrators can request suspension and lifting of Certificate suspension through GCC.
GlobalSign does not process Certificate suspension which are not requested through GCC.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

64 of 98

GlobalSign Certification Practice Statement

4.9.15 Procedure for Suspension Request
EPKI administrators can request Certificate suspension in GCC. After the request is submitted in
GCC, such information is synchronized with RA and CA to process the suspension request.
Certificate suspension is listed in the CRL with reason code of “certificateHold.”
4.9.16 Limits on Suspension Period
Certificate suspension may last as long as the validity period of Certificate.

4.10 Certificate Status Services
4.10.1 Operational Characteristics
GlobalSign provides a Certificate status service either in the form of a CRL distribution point or an
OCSP responder or both in the Certificates. Revocation entries may be removed after expiry of theCertificate to promote more efficient CRL file size management, except for Code Signing
Certificates (only 10 years after expiry).
For other Certificate types, GlobalSign does not remove revocation entries on CRL or OCSP until
after the Expiry Date of the revoked Certificate.
GlobalSign sends email notification to subscribers in the month (typically 30 days and 7 days)
before expiry informing subscribers about upcoming expiration of their Certificates.
Except for the case of suspension, the revocation status will never be reverted.
If required by Root Programs or CA/B Forum requirements, GlobalSign may backdate revocationof Certificates with the revocationDate field, as an exception to the best practice described in RFC
5280 to use the invalidityDate field.
GlobalSign may backdate revocation for Code Signing Certificates. Where GlobalSign backdates
revocation for Code Signing, GlobalSign shall as an exception to best practice described in RFC
5280 follow the CSBR recommendation to use revocationDate instead of invalidityDate within its
CRL.
4.10.2Service Availability

GlobalSign operates and maintains its CRL and OCSP capability with resources sufficient toprovide a response time of ten seconds or less under normal operating conditions. GlobalSign
maintains an online 24x7 Repository that application software can use to automatically check thecurrent status of all unexpired Certificates issued by GlobalSign.
GlobalSign maintains a continuous 24x7 ability to respond internally to a high-priority Certificate
Problem Report, and where appropriate, forward such a complaint to law enforcement authorities,
and/or revoke a Certificate that is the subject of such a complaint.
Upon system failure, service or other factors which are not under the control of GlobalSign,
GlobalSign aims to ensure that this information service is not unavailable for longer than 48 hours.
4.10.3 Operational Features
No stipulation

4.11 End of Subscription
Subscribers may end their subscription to Certificate services by having their Certificate revoked or
naturally letting it expire.

4.12 Key Escrow and Recovery
4.12.1 Key Escrow and Recovery Policy and Practices
CA Private Keys are never escrowed. GlobalSign does not offer key escrow services to
Subscribers.
4.12.2 Session Key Encapsulation and Recovery Policy and Practices
No stipulation.
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

65 of 98

GlobalSign Certification Practice Statement

5.0 Facility, Management, and Operational Controls
GlobalSign’s Certificate Management Process includes:
1. Physical security and environmental controls.
2. System integrity controls, including configuration management, integrity maintenance oftrusted code, and malware detection/prevention.
3. Network security and firewall management, including port restrictions and IP addressfiltering.
4. User management, separate trusted-role assignments, education, awareness, andtraining; and5. logical access controls, activity logging, and inactivity time-outs to provide individual
accountability.
GlobalSign’s security program includes an annual Risk Assessment that:
1. Identifies foreseeable internal and external threats that could result in unauthorized access,disclosure, misuse, alteration, or destruction of any Certificate Data or Certificate
Management Processes.
2. Assesses the likelihood and potential damage of these threats, taking into consideration
the sensitivity of the Certificate Data and Certificate Management Processes; and3. Assesses the sufficiency of the policies, procedures, information systems, technology, andother arrangements that GlobalSign has in place to counter such threats.
Based on the Risk Assessment, GlobalSign develops, implements, and maintains a security planconsisting of security procedures, measures, and products designed to achieve the objectives set
forth above and to manage and control the risks identified during the Risk Assessment,commensurate with the sensitivity of the Certificate Data and Certificate Management Processes.
The security plan includes administrative, organizational, technical, and physical safeguards
appropriate to the sensitivity of the Certificate Data and Certificate Management Processes. The
security plan also takes into account available technology and the cost of implementing the specificmeasures and implements a reasonable level of security appropriate to the harm that might result
from a breach of security and the nature of the data to be protected.

5.1

Physical Controls

GlobalSign maintains physical and environmental security policies for systems used for Certificate
issuance and management which cover physical access control, natural disaster protection, fire
safety factors, failure of supporting utilities (e.g., power, telecommunications), structure collapse,
plumbing leaks, protection against theft, breaking & entering, and disaster recovery. Controls are
implemented to avoid loss, damage or compromise of assets and interruption to business activities
and theft of information and information processing facilities.
5.1.1

Site Location and Construction

GlobalSign’s CAs are located within a secure data center. The data center is a purpose-built facility
made of concrete and steel construction.
5.1.2

Physical Access

GlobalSign’s CAs are operated within a secure data center that provides on-premise security withbiometric scanners and card access systems. A 24x7 Closed Circuit TV (CCTV) monitoring system
as well as digital recording is provided. Qualified security guards secure the physical premises andonly security-cleared and authorized personnel are allowed onto the premises.
5.1.3

Power and Air Conditioning

GlobalSign’s CAs are operated within a secure data center that is equipped with redundant powerand cooling system. UPS and failover to power generator are in place in the unlikely event of power
outage.
5.1.4

Water Exposures

GlobalSign’s CAs are protected against water. It is located above ground and on a higher floor withraised flooring. In addition, a water detection alarm system is in place, and on-site data center
operations staff are ready to respond to any unlikely water exposure.
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

66 of 98

GlobalSign Certification Practice Statement

5.1.5

Fire Prevention and Protection

GlobalSign’s CAs operate within a secure data center that is equipped with a fire detection andsuppression system.
5.1.6

Media Storage

Storage of backup media is off-site, physically secured and protected from fire and water damage.
5.1.7

Waste Disposal

GlobalSign ensures that all media used for the storage of information is declassified or destroyed
in a generally accepted manner before being released for disposal.
5.1.8

Off-Site Backup

As stipulated in section 5.5.

5.2

Procedural Controls

5.2.1

Trusted Roles

GlobalSign ensures that all operators and administrators, including Validation Specialists, areacting in the capacity of a trusted role. Trusted roles are such that no conflict of interest is possible,
and the roles are distributed such that no single person can circumvent the security of the CA
system.
Trusted roles include but are not limited to the following:
•
•
•
•
•
•
•
5.2.2

Developer: Responsible for development of CA systems.
Security Officer/Head of Information Security: Overall responsibility for administering
the implementation of the CA's security practices.
Validation Specialists: Responsible for validating the authenticity and integrity of data to
be included within Certificates via a suitable RA system and approve thegeneration/revocation/suspension of Certificates.
Infra System Engineer: Authorized to install, configure, and maintain the CA systems
used for Certificate lifecycle management.
Infra Operator: Responsible for operating the CA systems on a day-to-day basis.
Authorized to perform system backup / recovery, viewing / maintenance of CA systemarchives and audit logs.
Auditor: Authorized to view archives and audit logs.
CA activation data holder: Authorized person that holds CA activation data that isnecessary for CA hardware security module operation.
Number of Persons Required per Task

The CA Private Keys are backed up, stored, and recovered only by personnel in trusted roles using,at least, dual control in a physically secured environment.
5.2.3

Identification and Authentication for Each Role

Before appointing a person to a trusted role, GlobalSign performs a background check. Each roledescribed above is identified and authenticated in a manner to guarantee that the right person has
the right role to support the CA.
5.2.4

Roles Requiring Separation of Duties

GlobalSign enforces role separation either by the CA equipment (logically) or procedurally or a
combination of both means.
Individual CA personnel are specifically assigned to the roles defined in Section 5.2.1 above.
Roles requiring a separation of duties include:• Those performing approval of the generation, revocation, and suspension of Certificates.
(Validation Specialists)• Those performing installation, configuration, and maintenance of the CA systems. (Infra
system engineer)
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

67 of 98

GlobalSign Certification Practice Statement

•
•
•
•

5.3
5.3.1

Those with overall responsibility for administering the implementation of the CA’s security
practices. (Security Officer)
Those performing duties related to cryptographic key life cycle management (e.g., key
component custodians). (CA activation data holders)Those performing CA systems development. (Developers)Those performing CA systems auditing (Infra Operator, Auditor)

Personnel Controls
Qualifications, Experience, and Clearance Requirements

Prior to the engagement of any person in the Certificate Management Process, whether as an
employee, agent, or an independent contractor, GlobalSign verifies the identity and trustworthinessof such person.
GlobalSign employs personnel that possesses the expert knowledge, experience, andqualifications necessary for the offered services, as appropriate to the job function.
GlobalSign personnel fulfil the requirement through expert knowledge, experience andqualifications with formal training and education, actual experience, or a combination of the two.
Trusted roles and responsibilities, as specified in Section 5.2.1 are documented in job descriptions.
GlobalSign personnel (both temporary and permanent) have job descriptions defined from theviewpoint of separation of duties and least privilege, determining position sensitivity based on theduties and access levels, background screening and employee training and awareness. GlobalSign
personnel are formally appointed to trusted roles.
5.3.2

Background Check Procedures

All GlobalSign personnel in trusted roles are free from conflict of interests that might prejudice theimpartiality of the CA operations. GlobalSign does not appoint to a trusted role any person who is
known to have a conviction for a serious crime or another offence if such conviction affects his/hersuitability for the position. Personnel do not have access to the trusted functions until any necessary
checks are completed and results analyzed, provided such checks are permitted by the jurisdictionin which the person will be employed. All persons filling trusted roles shall be selected on the basisof loyalty, trustworthiness, and integrity, and shall be subject to background investigation, wherepermitted by law.
Any use of information revealed by background checks by GlobalSign shall be in compliance withapplicable laws of the jurisdiction where the person is employed.
5.3.3

Training Requirements

GlobalSign provides all personnel performing information verification duties with skills-training thatcovers basic Public Key Infrastructure knowledge, authentication and vetting policies andprocedures (including the CA’s Certificate Policy and/or Certification Practice Statement), common
threats to the information verification process (including phishing and other social engineering
tactics), and the CA/Browser Forum Requirements.
GlobalSign maintains records of such training and ensures that personnel entrusted with Validation
Specialist duties maintain a skill level that enables them to perform such duties satisfactorily.
GlobalSign documents that each Validation Specialist possesses the skills required by a task before
allowing the Validation Specialist to perform that task.
GlobalSign requires all Validation Specialists to pass an examination provided by the CA on theinformation verification requirements outlined in the CA/Browser Forum Requirements.
5.3.4

Retraining Frequency and Requirements

All personnel in Trusted Roles maintain skill levels consistent with GlobalSign’s yearly training andperformance programs with relevance to their trusted role.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

68 of 98

GlobalSign Certification Practice Statement

Any significant change to the operations has a training (awareness) plan, and the execution of suchplan is documented.
GlobalSign provides information security and privacy training at least once a year to all employees.
5.3.5

Job Rotation Frequency and Sequence

GlobalSign ensures that any change in the staff will not affect the operational effectiveness of theservice or the security of the system.
5.3.6

Sanctions for Unauthorized Actions

Appropriate disciplinary sanctions are applied to personnel violating provisions and policies within
the CP, this CPS or CA related operational procedures.
5.3.7

Independent Contractor Requirements

Delegated Third Party and contractor personnel employed for GlobalSign operations are subject tothe same process, procedures, assessment, security control and training as permanent CA
personnel.
5.3.8

Documentation Supplied to Personnel

GlobalSign makes available to its personnel this CPS, any corresponding CP, and any relevant
statutes, policies, or contracts. Other technical, operational, and administrative documents (e.g.,administrator manuals, user manuals, etc.) are provided in order for the trusted personnel toperform their duties.
Documentation is maintained identifying all personnel who received training and the level of training
completed.

5.4

Audit Logging Procedures

5.4.1

Types of Events Recorded

GlobalSign records events related to the security of their Certificate Systems, Certificate
Management Systems and Root CA Systems. GlobalSign records events related to its actions
taken to process a certificate request and to issue a Certificate, including all information generated
and documentation received in connection with the certificate request; the time and date; and thepersonnel involved.
GlobalSign makes these records available to its Qualified Auditor as proof of the CA’s compliancewith these Requirements.
GlobalSign records at least the following events:
1. CA certificate and key lifecycle events, including:
i.
ii.
iii.
iv.
v.
vi.
vii.

Key generation, backup, storage, recovery, archival, and destruction;
Certificate requests, renewal, and re-key requests, and revocation;
Approval and rejection of certificate requests;
Cryptographic device lifecycle management events;
Generation of Certificate Revocation Lists;
Signing of OCSP Responses; andIntroduction of new Certificate Profiles and retirement of existing Certificate
Profiles.

2. Subscriber Certificate lifecycle management events, including:
i.
ii.
iii.
iv.
v.
vi.

Certificate requests, renewal, and re-key requests, and revocation;
All verification activities stipulated in this Certification Practice Statement;
Approval and rejection of certificate requests;
Issuance of Certificates;
Generation of Certificate Revocation Lists; andSigning of OCSP Responses.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

69 of 98

GlobalSign Certification Practice Statement

3. Security events, including:
i.
ii.
iii.
iv.
v.
vi.
vii.

Successful and unsuccessful PKI system access attempts;
PKI and security system actions performed;
Security profile changes;
Installation, update and removal of software on a Certificate System;
System crashes, hardware failures, and other anomalies;
Firewall and router activities; andEntries to and exits from the CA facility.

Log records must include the following elements:
1. Date and time of event;2. Identity of the person making the journal record; and3. Description of the event.
5.4.2

Frequency of Processing Log

Audit logs are reviewed on an as needed basis.
5.4.3

Retention Period for Audit Log

GlobalSign and each Delegated Third Party retain the applicable audit logs for at least the retention
period defined by the WebTrust and/or eIDAS or UK eIDAS requirements for the Certificate type.
The retention period is at least:• 10 years for Subscriber Certificates; or• 7 years after the CA Certificate based on the logs ceases to be valid.
Unless specified otherwise in an agreement with GlobalSign.
5.4.4

Protection of Audit Log

The events are logged in a way that they cannot be deleted or destroyed (except for transfer tolong term media) for any period of time that they are retained.
The records of events are protected to prevent alteration and detect tampering and to ensure that
only trusted roles can perform operations, without modifying integrity, authenticity, andconfidentiality of the data.
The records of events are date stamped in a secure manner that guarantees, from the date ofcreation of the record to the end of the archive period, that there is a trusted link between the eventand the time of its realization.
5.4.5

Audit Log Backup Procedures

Audit logs are backed-up in a secure location (for example, a fireproof safe), under the control of atrusted role and separated from their component source generation. Audit log backup is protectedto the same degree as the originals.
5.4.6

Audit Collection System

Audit processes are initiated at system start up and finish only at system shutdown. The audit
collection system ensures the integrity and availability of the data collected. If necessary, the audit
collection system protects data confidentiality. In the case of a problem occurring during the processof the audit collection GlobalSign determines whether to suspend GlobalSign operations until the
problem is resolved.
5.4.7

Notification to Event-Causing Subject

No stipulation.
5.4.8

Vulnerability Assessments

GlobalSign performs annual risk assessments that:

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

70 of 98

GlobalSign Certification Practice Statement

1. Identifies foreseeable internal and external threats that could result in unauthorized access,disclosure, misuse, alteration, or destruction of any Certificate Data or Certificate
Management Process.
2. Assesses the likelihood and potential damage of these threats, taking into consideration
the sensitivity of the Certificate Data and Certificate Management Processes; and3. Assesses the sufficiency of the policies, procedures, information systems, technology, andother arrangements that GlobalSign has in place to counter such threats.
GlobalSign also performs regular vulnerability assessment and penetration testing covering all
GlobalSign assets related to Certificate issuance, products, and services. Assessments focus oninternal and external threats that could result in unauthorized access, tampering, modification,
alteration, or destruction of the Certificate issuance process.

5.5

Records Archival

5.5.1

Types of Records Archived

GlobalSign and each Delegated Third Party archive all audit logs as set forth in Section 5.4.1 and:1. Documentation related to the security of their Certificate Systems, Certificate Management
Systems, Root CA Systems, and Delegated Third Party Systems; and2. Documentation related to their verification, issuance, and revocation of certificate requests
and Certificates.
5.5.2

Retention Period for Archive

GlobalSign and each Delegated Third Party retain audit logs (as set forth in Section 5.4.1) andrecords (as set forth in Section 5.5.1) for at least the retention period defined by the WebTrust
and/or eIDAS or UK eIDAS requirements for the Certificate type.
The retention period is at least:• 10 years for Subscriber Certificates; or• 7 years after the CA Certificate based on the logs ceases to be valid.
Unless specified otherwise in an agreement with GlobalSign.
5.5.3

Protection of Archive

Archives are created in such a way that they cannot be deleted or destroyed (except for transfer tolong term media) within the period for which they are required to be held. Archive protection ensuresthat only trusted roles can perform operations without modifying integrity, authenticity, andconfidentiality of the data. If the original media cannot retain the data for the required period, amechanism to periodically transfer archived data to new media will be defined by the archive site.
5.5.4

Archive Backup Procedures

Online backups are duplicated on a regular basis, and each backup is stored in a location which isdifferent from the original online system. One backup is stored in a fire rated media safe. An offline
backup is taken at the end of any key ceremony (with the exception of any encrypted material whichis stored separately in line with key ceremony procedures) and stored in an off-site location within
30 days of the ceremony.
5.5.5

Requirements for Timestamping of Records

If a timestamping service is used to date the records, then it must comply with the requirements
defined in Section 6.8. Irrespective of timestamping methods, all logs must have data indicating thetime at which the event occurred.
5.5.6

Archive Collection System (Internal or External)

The archive collection system complies with the security requirements in Section 5.
5.5.7

Procedures to Obtain and Verify Archive Information

No stipulation.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

71 of 98

GlobalSign Certification Practice Statement

5.6

Key Changeover

GlobalSign may periodically changeover key material for Issuing CAs in accordance with Section
6.3.2. Certificate Subject information may also be modified, and Certificate profiles may be alteredto adhere to best practices. Private Keys used to sign previous Subscriber Certificates aremaintained until such time as all Subscriber Certificates have expired.

5.7
5.7.1

Compromise and Disaster Recovery
Incident and Compromise Handling Procedures

GlobalSign has an Incident Response Plan and a Disaster Recovery Plan. GlobalSign documents
business continuity and disaster recovery procedures designed to notify and reasonably protect
Application Software Suppliers, Subscribers, and Relying Parties in the event of a disaster, security
compromise, or business failure.
GlobalSign does not disclose business continuity plans to Subscribers, Relying Parties, or to
Application Software Suppliers, but will provide business continuity plan and security plans to
GlobalSign’s CA auditors upon request.
GlobalSign annually tests, reviews, and updates these procedures. The business continuity plan
includes:1. The conditions for activating the plan.
2. Emergency procedures.
3. Fallback procedures.
4. Resumption procedures.
5. A maintenance schedule for the plan.
6. Awareness and education requirements.
7. The responsibilities of the individuals.
8. Recovery time objective (RTO).
9. Regular testing of contingency plans.
10. GlobalSign’s plan to maintain or restore the CA’s business operations in a timely manner
following interruption to or failure of critical business processes.
11. A requirement to store critical cryptographic materials (i.e., secure cryptographic device
and activation materials) at an alternate location.
12. What constitutes an acceptable system outage and recovery time.
13. How frequently backup copies of essential business information and software are taken.
14. The distance of recovery facilities to the CA’s main site; and15. Procedures for securing its facility to the extent possible during the period of time following
a disaster and prior to restoring a secure environment either at the original or a remote site.
5.7.2

Computing Resources, Software, and/or Data Are Corrupted

If any equipment is damaged or rendered inoperative but the Private Keys are not destroyed, theoperation should be re-established as quickly as possible, giving priority to the ability to generate
Certificate status information according to GlobalSign’s disaster recovery plan.
5.7.3

Entity Private Key Compromise Procedures

In the event a GlobalSign CA Private Key is Compromised, lost, destroyed, or suspected to be
Compromised:
GlobalSign, after investigation of the problem, shall decide if the GlobalSign Certificate should be
revoked. If so, then:• All the Subscribers who have been issued a Certificate will be notified at the earliest
feasible opportunity; and• A new GlobalSign Key Pair shall be generated, or an alternative existing CA hierarchy shallbe used to create new Subscriber Certificates.
5.7.4

Availability of revocation status

Revocation status information will be provided and maintained at a publicly accessible location incase of CA key compromise, including, if applicable, transferring Certificate status information
services to another GMO Internet Group entity.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

72 of 98

GlobalSign Certification Practice Statement

5.7.5

Business Continuity Capabilities After a Disaster

The disaster recovery plan deals with the business continuity as described in Section 5.7.1.
Certificate status information systems should be deployed so as to provide 24 hours per day, 365
days per year availability.

5.8

CA or RA Termination

When it is necessary to terminate an Issuing CA or RA activities, the impact of the termination will
be minimized as much as possible in light of the prevailing circumstances and is subject to theapplicable Issuing CA and/or Registration Authority Agreements. GlobalSign’s issuing CAs specify
the procedures they will follow when terminating all or a portion of their Digital Certificate issuanceand management operations. The procedures must, at a minimum:• ensure that any disruption caused by the termination of an Issuing CA is minimized asmuch as possible.
• ensure that archived records of the Issuing CA are retained.
• ensure that prompt notification of termination is provided to Subscribers, Authorized
Relying Parties, Application Software Providers, and other relevant stakeholders in
GlobalSign certificate lifecycles.
• ensure Certificate status information services are provided and maintained for theapplicable period after termination, including, if applicable, transferring Certificate status
information services to another GMO Internet Group entity.
• ensure that a process for revoking all Digital Certificates issued by an Issuing CA at thetime of termination is maintained.
• notify all auditors, including the eIDAS/UK eIDAS Conformity Assessment Bodies; and• notify the Belgian eIDAS supervisory body (FPS Economy, SMEs, Self-employed andEnergy - Quality and Safety)• notify the United Kingdom UK eIDAS supervisory body (Information Commissioner’s
Office)• notify other relevant Government and Certification bodies under applicable laws andrelated regulations.
5.8.1

Successor Issuing Certification Authority

To the extent that it is practical and reasonable, the successor Issuing CA should assume the samerights, obligations, and duties as the terminating Issuing CA. The successor Issuing CA should
issue new Keys and Digital Certificates to all Subscribers whose Keys and Digital Certificates wererevoked by the terminating Issuing CA due to its termination, subject to the individual service
provider or User making an application for a new Digital Certificate, and satisfying the initial
registration and Identification and Authentication requirements, including the execution of a newservice provider or Certificate Holder Agreement.

6.0 Technical Security Controls
6.1

Key Pair Generation and Installation

6.1.1
6.1.1.1

Key Pair Generation
CA Key Pair Generation

For Root CA Key Pairs, GlobalSign performs the following controls.
1. prepares and follows a Key Generation Script,
2. has a Qualified Auditor witness the Root CA Key Pair generation process or record a videoof the entire Root CA Key Pair generation process, and3. has a Qualified Auditor issue a report opining that GlobalSign followed its key ceremony
script during its Key and Certificate generation process and the controls used to ensure theintegrity and confidentiality of the Key Pair.
In other CA Key Pairs, GlobalSign performs following controls:
1. Generates the keys in a physically secured environment as described in Section 5.1 and5.2.2. of Certificate Policy and/or Certification Practice Statement.
2. Generates the CA keys using personnel in trusted roles under the principles of multiple
person control and split knowledge.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

73 of 98

GlobalSign Certification Practice Statement

3. Generate the CA keys within cryptographic modules meeting the applicable technical andbusiness requirements as disclosed in the CA’s Certificate Policy and/or Certification
Practice Statement.
4. Log its CA key generation activities; and5. Maintain effective controls to provide reasonable assurance that the Private Key was
generated and protected in conformance with the procedures described in its Certificate
Policy and/or Certification Practice Statement and (if applicable) its Key Generation Script.
6.1.1.2

Subscriber Key Pair Generation

For Subscriber keys generated by GlobalSign, Key generation is performed in accordance with the
CA/Browser Forum requirements, on a secure cryptographic device that meets FIPS 140-2 (orequivalent) using key generation algorithm and key size as specified in Section 6.1.5 and 6.1.6.
GlobalSign also rejects a certificate request if it has a known weak Private Key.
Keys used for Code Signing Certificates must be generated on a Hardware Crypto Module with aunit design form factor certified as conforming to at least FIPS 140‐2 Level 2 or Common Criteria
EAL 4+.
For Qualified Certificates where the Private Key is generated by GlobalSign or a third party on
behalf of a Subject, the Private Key shall be generated and stored securely whilst held by
GlobalSign or the third party. If the device is managed by a third party on behalf of the Subject,
GlobalSign shall verify that this third party is meeting the appropriate requirements in terms of
qualification.
For Qualified Certificates issued in accordance with QCP-n or QCP-l policy, a secure cryptographic
device is optional.
For Qualified Certificates where the Private Key related to the certified Public Key resides in a
QSCD, Subscriber keys are generated and stored within a recognized Qualified Signature Creation
Device (QSCD). QSCD certification status is monitored, and appropriate measures, including
revocation, will be taken if the certification status of a QSCD changes.
6.1.2

Private Key Delivery to Subscriber

GlobalSign does not generate Private Keys for publicly trusted SSL or Code Signing Certificates.
GlobalSign CAs that create Private Keys on behalf of Subscribers do so only when sufficient
security is maintained within the key generation process and any onward issuance process to the
Subscriber.
For non-publicly trusted SSL Certificates, this is achieved through the use of PKCS#12 (.pfx) files
containing Private Keys and Certificates encrypted by at least sixteen (16) character password. At
least eight (8) characters are system generated and provided to the Subscriber during theenrolment process and the Subscriber specifies at least eight (8) characters. For S/MIME
Certificates, this is again achieved through the use of PCKS#12 (.pfx) files containing Private Keys
and Certificates encrypted by a minimum seventeen (17) alpha-numeric character Subscriberselected password.
For Qualified Certificates, Private Keys may be managed by GlobalSign or a third party on behalfof a Subject. If a Private Key is managed on behalf of a Subject, GlobalSign shall ensure that the
Subject has sole control (or if the Subject is a legal person, "control") over its private key. For keys
managed by a third party, GlobalSign shall confirm that the third party is a Qualified Trust Service
Provider and ensures sole control.
For Qualified Certificates where the Private Key resides on a QSCD, if GlobalSign or a third party
manages the QSCD for the Subject, the Private Key shall not be used for signing except within a
QSCD. The Subject’s Private Key pair should be used only for electronic signatures or seals
respectively.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

74 of 98

GlobalSign Certification Practice Statement

For Qualified Certificates, GlobalSign only generates Private Keys if GlobalSign manages thePrivate Key on behalf of the Subscriber
GlobalSign ensures the integrity of any Public/Private Keys and the randomness of the key material
through a suitable RNG or PRNG. If GlobalSign detects or suspects that the Private Key has beencommunicated to an unauthorized person or an organization not affiliated with the Subscriber, then
GlobalSign revokes all Certificates that include the Public Key corresponding to the communicatedPrivate Key.
6.1.3

Public Key Delivery to Certificate Issuer

GlobalSign CAs only accept Public Keys from RAs that have been protected during transit andhave had the authenticity and integrity of their origin from the RA suitably verified.
6.1.4

CA Public Key Delivery to Relying Parties

GlobalSign ensures that its Public Keys are delivered to Relying Parties in such a way as to prevent
substitution attacks. Commercial web browsers and platform operators are encouraged to embed
Root Certificate Public Keys into their root stores and operating systems. Issuing CA Public Keys
are delivered by the Subscriber in the form of a chain of Certificates or via a Repository operated
by GlobalSign and referenced within the profile of the issued Certificate through AIA (Authority
Information Access).
6.1.5

Key Sizes

GlobalSign follows NIST Special Publication 800-133 Revision 2 (2020) - Recommendation for
Cryptographic Key Generation - for recommended timelines and best practices in the choice of Key
Pairs for Root CAs, Issuing CAs and end entity Certificates delivered to Subscribers.
GlobalSign selects from the following Key Sizes/Hashes for Root Certificates, Issuing CA
Certificates, and end entity Certificates as well as CRL/OCSP Certificate status responders. These
choices align with the CA/Browser Forum Requirements.
Certificates must meet the following requirements for algorithm type and key size.
Root CA Certificates
Validity period beginning on or before
31 Dec 2010

Validity period beginning after 31 Dec
2010

Digest algorithm

SHA-1, SHA-256, SHA-384 or SHA512

SHA-256, SHA-384 or SHA-512

Minimum RSA
modulus size (bits)

20485

2048

ECC curve

NIST P-256, P-384, or P-521

NIST P-256, P-384, or P-521

Subordinate Certificates
Validity period beginning on or before
31 Dec 2010 and ending on or before
31 Dec 2013

Validity period beginning after 31 Dec
2010 or ending after 31 Dec 2013

Digest algorithm

SHA-1, SHA-256, SHA-384 or SHA512

SHA-16, SHA-256, SHA-384 or SHA512

Minimum
RSA
modulus size (bits)

1024

2048

ECC curve

NIST P-256, P-384, or P-521

NIST P-256, P-384, or P-521

Subscriber Certificates5

RSA key modulus size in bits must be divisible by 8. A Root CA Certificate issued prior to 31 Dec. 2010
with an RSA key size less than 2048 bits may still serve as a trust anchor for Subscriber Certificates issuedin accordance with these Requirements.
6

SHA-1 may be used for IntranetSSL Subordinate CA Certificates, but they are not chained to publicly
trusted roots.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

75 of 98

GlobalSign Certification Practice Statement

Digest algorithm

SHA-17, SHA-256, SHA-384 or SHA- 512

Minimum RSA
modulus size (bits)

2048

ECC curve

NIST P-256, P-384, or P-521

RSASSA-PSS8

As of July 1, 2017, the minimum key size for new Root CA Certificates which issue Subordinate
CAs for AATL is RSA 3072-bit or ECC NIST P-384.
As of January 1, 2021, the minimum key size for new Root and Subordinate CA Certificates whichissue Code Signing and Timestamping Certificates is RSA 3072-bit or ECC NIST P-256
As of June 1, 2021, the minimum key size for new Code Signing and Timestamping Subscriber
Certificates for CodeSign is RSA 3072-bit or ECC NIST P-256.
6.1.6

Public Key Parameters Generation and Quality Checking

GlobalSign generates Key Pairs in accordance with FIPS 186 and uses reasonable techniques tovalidate the suitability of Public Keys presented by Subscribers. Known weak keys are tested forand rejected at the point of submission. GlobalSign follows the applicable CA/Browser Forum
Requirements on key pair generation and quality checking.
6.1.7

Key Usage Purposes (as per X.509 v3 Key Usage Field)

GlobalSign sets key usage of Certificates depending on their proposed field of application via thev3 Key Usage Field for X.509 v3 (see Section 7.1).
Private Keys corresponding to Root Certificates are not used to sign Certificates except in thefollowing cases:
1. Self-signed Certificates to represent the Root CA itself.
2. Certificates for Subordinate CAs and Cross Certificates.
3. Certificates for OCSP Response verification.

6.2
6.2.1

Private Key Protection and Cryptographic Module Engineering Controls
Cryptographic Module Standards and Controls

GlobalSign protects its CA Private Keys in a system or device that has been validated as meetingat least FIPS 140-2 level 3, FIPS 140-3 level 3, or an appropriate Common Criteria Protection
Profile or Security Target, EAL 4 (or higher), which includes requirements to protect the Private Key
and other assets against known threats.
GlobalSign encrypts its Private Key with an algorithm and key‐length that, according to the state of
the art, are capable of withstanding cryptanalytic attacks for the residual life of the encrypted key
or key part.
For Certificates where specific Subscriber Private Key protection requirements apply, GlobalSign
will contractually obligate the Subscriber to use such a system or provide a suitable mechanism toguarantee protection.
6.2.2

Private Key (n out of m) Multi-Person Control

GlobalSign activates Private Keys for cryptographic operations with multi-person control (using CA
activation data) performing duties associated with their trusted roles. The trusted roles permitted toparticipate in this Private Key multi-person controls are strongly authenticated (i.e., token with PINcode).
7

SHA-1 may be used for IntranetSSL Subscriber CA Certificates, but they are not chained to publicly
trusted roots.
8

RSASSA-PSS may be used with RSA keys for PersonalSign Certificates in accordance with the criteria
defined in Section 7.1.3.8 RSASSA-PSS may be used with RSA keys for PersonalSign Certificates inaccordance with the criteria defined in Section 7.1.3.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

76 of 98

GlobalSign Certification Practice Statement

6.2.3

Private Key Escrow

GlobalSign does not escrow Private Keys for any reason.
6.2.4

Private Key Backup

GlobalSign backs up CA Private Keys under the same multi-person control as the original Private
Key.
GlobalSign only performs backup of Subscriber Private Keys for Qualified Certificates where thePrivate Key resides on a QSCD managed by GlobalSign on behalf of the subject. The backup
mechanism replicates the Private Keys with the same security controls as the primary location.
6.2.5

Private Key Archival

GlobalSign does not archive private keys.
6.2.6

Private Key Transfer into or from a Cryptographic Module

GlobalSign CA Private Keys are generated, activated, and stored in Hardware Security Modules.
When Private Keys are outside of a Hardware Security Module (either for storage or transfer), they
are encrypted. Private Keys never exist in plain text outside of a cryptographic module.
If GlobalSign becomes aware that a CA’s Private Key has been communicated to an unauthorized
person or an organization not affiliated with the CA, then GlobalSign will revoke all Certificates that
include the Public Key corresponding to the communicated Private Key.
6.2.7

Private Key Storage on Cryptographic Module

GlobalSign stores CA Private Keys on a device meeting the requirements of Section 6.2.1.
6.2.8

Method of Activating Private Key

GlobalSign activates CA Private Keys in accordance with the instructions and documentation
provided by the manufacturer of the hardware security module. Subscribers are responsible forprotecting Private Keys in accordance with the obligations that are presented in the form of a
Subscriber Agreement or Terms of Use.
6.2.9

Method of Deactivating Private Key

GlobalSign deactivates CA Private Keys in accordance with the instructions and documentation
provided by the manufacturer of the hardware security module.
6.2.10 Method of Destroying Private Key
GlobalSign destroys CA Private Keys in accordance with the instructions and documentation
provided by the manufacturer of the hardware security module.
6.2.11 Cryptographic Module Rating
See Section 6.2.1

6.3
6.3.1

Other Aspects of Key Pair Management
Public Key Archival

GlobalSign archives Public Keys from Certificates.
6.3.2

Certificate Operational Periods and Key Pair Usage Periods

Certificates have a maximum Validity Period of:Type
Root Certificates9
TPM Root Certificates
Publicly Trusted Sub-CAs/Issuer CAs
PersonalSign Certificates
Code Signing Certificates

Key Pair Usage Period
No stipulation
30 years
No stipulation
No stipulation
No stipulation

Max Validity Period
28 years
41 years
18 years
39 months
39 months

9 2048-bit keys generated prior to 2003 using RSA may be used for 25 years due to limited usage due to key

size restrictions within hardware, root stores and operating systems.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

77 of 98

GlobalSign Certification Practice Statement

EV Code Signing Certificates
S/MIME strict and multipurpose Certificates
S/MIME legacy Certificates
AATL End Entity Certificates
Qualified Certificate for Electronic Signatures and Seals
DV SSL Certificates
AlphaSSL Certificates
OV SSL Certificates
EV SSL Certificates
Qualified Website Authentication Certificates
Intranet SSL
Timestamping Certificates
NAESB Certificates
Private Key Archival\Key Recovery Agent Certificates

No stipulation
No stipulation
No stipulation
No stipulation
No stipulation
No stipulation
No stipulation
No stipulation
No stipulation
No stipulation
No stipulation
15 months
2 years
No stipulation

39 months
825 days1185 days
39 months
39 months
398 days
398 days
398 days
398 days
398 days
5 years
11 years
2 years
5 years

For the purpose of calculations, a day is measured as 86,400 seconds. Any amount of time greaterthan this, including fractional seconds and/or leap seconds, shall represent an additional day. For
this reason, Subscriber Certificates should NOT be issued for the maximum permissible time bydefault, in order to account for such adjustments.
Effective April 1, 2022, the maximum validity period of end entity certificates with id-kpemailProtection EKU is 1185 days.
The Key Pair usage period can be up to the Certificate Validity Period.
Certificates signed by a specific CA must expire before or at the end of that CA Certificate Validity
period.
GlobalSign complies with the CA/Browser Forum Requirements with respect to the maximum
Validity Period.
In the event that a Subscriber’s Certificate has a reduced validity period, subsequent re-issues may
be used to regain that lost validity period. Certificates

6.4

Activation Data

6.4.1

Activation Data Generation and Installation

Generation and use of GlobalSign activation data used to activate GlobalSign CA Private Keys are
made during a key ceremony (Refer to Section 6.1.1). Activation data is either generated
automatically by the appropriate HSM or in such a way that meets the same needs. It is thendelivered to a holder of a share of the key who is a person in a trusted role. The delivery method
maintains the confidentiality and the integrity of the activation data.
6.4.2

Activation Data Protection

Issuing CA activation data is protected from disclosure through a combination of cryptographic andphysical access control mechanisms. GlobalSign activation data is stored on smart cards.
6.4.3

Other Aspects of Activation Data

GlobalSign activation data may only be held by GlobalSign personnel in trusted roles.

6.5

Computer Security Controls

6.5.1

Specific Computer Security Technical Requirements

The following computer security functions are provided by the operating system, or through a
combination of operating system, software, and physical safeguards. The GlobalSign PKI
components must include the following functions:
•
•
•
•
•

Require authenticated logins for trusted role.
Provide discretionary access control with least privilege.
Provide security audit capability (protected in integrity).
Prohibit object re-use.
Require use of strong password policy.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

78 of 98

GlobalSign Certification Practice Statement

•
•
•
•
•
•

Require use of cryptography for session communication.
Require trusted path for identification and authentication.
Provide means for malicious code protection.
Provide means to maintain software and firmware integrity
Provide domain isolation and partitioning for different systems and processes; andProvide self-protection for the operating system.

For accounts capable of directly causing certificate issuance, GlobalSign enforces multifactor
authentication.
6.5.2

Computer Security Rating

No Stipulation

6.6

Lifecycle Technical Controls

6.6.1

System Development Controls

The system development controls for GlobalSign are as follows:
•
•

•
•
•

•

6.6.2

Use software that has been designed and developed under a formal, documented
development methodology.
All hardware will be inspected during commissioning process to ensure conformity tosupply, and no evidence of tampering found. Hardware and software procured arepurchased in a fashion to reduce the likelihood that any particular component was
tampered with (e.g., by ensuring the equipment was randomly selected at time ofpurchase).
Hardware and software are developed in a controlled environment, and the development
processes are defined and documented. This requirement does not apply to commercial
off-the-shelf hardware or software.
The hardware and software are dedicated to performing CA activities. There are no otherapplications, hardware devices, network connections, or component software installed
which are not part of the CA operation.
Proper care is taken to prevent malicious software from being loaded onto the equipment.
Only applications required to perform the CA operations are installed on the equipment andare obtained from sources authorized by local policy. GlobalSign hardware and softwareare scanned for malicious code on first use and periodically thereafter; andHardware and software updates are purchased or developed in the same manner as
original equipment and are installed by trusted and approved personnel in a definedmanner.
Security Management Controls

The configuration of GlobalSign systems as well as any modifications and upgrades are
documented and controlled by GlobalSign management. There is a mechanism for detecting
unauthorized modification to GlobalSign software or configuration. A formal configuration
management methodology is used for installation and on-going maintenance of GlobalSign
systems. GlobalSign software, when first loaded, is checked as being that supplied from the vendor,
with no modifications, and is the version intended for use.
6.6.3

Lifecycle Security Controls

GlobalSign maintains a maintenance scheme to ensure the level of trust of software and hardwarethat are evaluated and certified.

6.7

Network Security Controls

GlobalSign PKI components implement appropriate security measures to ensure they are guarded
against denial of service and intrusion attacks. Such measures include the use of security guards,
firewalls, and filtering routers. Unused network ports and services are turned off. Any boundary
control devices used to protect the network on which PKI equipment are hosted deny all but thenecessary services to the PKI equipment even if those services are enabled for other devices on
the network.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

79 of 98

GlobalSign Certification Practice Statement

6.8

Timestamping

All GlobalSign components are regularly synchronized with a reliable time service. GlobalSign uses
one GPS source and three non-authenticated NTP source clocks to establish the correct time for:••••

Initial validity time of a CA Certificate.
Revocation of a CA Certificate.
Posting of CRL updates; andIssuance of Subscriber end entity Certificates.

Electronic or manual procedures may be used to maintain system time. Clock adjustments areauditable events.
6.8.1

PDF Signing Timestamping Services

All Digital Signatures created by PDF Signing Certificates have the ability to include a trusted
timestamp issued from an RFC 3161 compliant Time Stamp Authority (TSA) server chained to a
GlobalSign Root Certificate. The TSA Certificate shall be located in a FIPS 140-2 level 3 or higher
HSM.
6.8.2

Code Signing and EV Code Signing Timestamping Services

All Digital Signatures created by Code Signing and Extended Validation Code Signing Certificateshave the ability to include a trusted timestamp issued from an RFC 3161 compliant Time Stamp
Authority (TSA) server chained to a GlobalSign Root Certificate. The TSA certificate shall belocated in a FIPS 140-2 level 3 or higher HSM.

7.0 Certificate, CRL, and OCSP Profiles
7.1

Certificate Profile

7.1.1

Version Number(s)GlobalSign issues Certificates in compliance with X.509 Version 3.
7.1.2

Certificate Extensions

GlobalSign issues Certificates in compliance with RFC 5280 and the applicable CA/Browser Forum
Requirements except where mentioned in this document.
Criticality also follows best practice to prevent unnecessary risks to Relying Parties when applied
to name constraints.
Subordinate CA and end entity Certificates include an Extended Key Usage extension containing
KeyPurposeId(s) describing the intended usage(s) of the certificate. The KeyPurposeId
anyExtendedKeyUsage is not included in publicly trusted end entity Certificates.
7.1.3

Algorithm Object Identifiers

GlobalSign issues Certificates with algorithms indicated by the following OIDs:
SHA1WithRSAEncryption{iso(1) member-body(2) us(840) rsadsi (113549) pkcs(1) pkcs-1(1) 5}*
SHA256WithRSAEncryption {iso(1) member-body(2) us(840) rsadsi (113549) pkcs(1) pkcs-1(1) 11}
SHA384WithRSAEncryption {iso(1) member-body(2) us(840) rsadsi (113549) pkcs(1) pkcs-1(1) 12}
SHA512WithRSAEncryption {iso(1) member-body(2) us(840) rsadsi (113549) pkcs(1) pkcs-1(1) 13}
ECDSAWithSHA256ECDSAWithSHA384
ECDSAWithSHA512RSASSA-PSS{iso(1) member‐body(2) us(840) ansi‐X9‐62 (10045) signatures(4) ecdsa‐with‐SHA2(3) 2}{iso(1) member‐body(2) us(840) ansi‐X9‐62 (10045) signatures(4) ecdsa‐with‐SHA2(3) 3}{iso(1) member‐body(2) us(840) ansi‐X9‐62 (10045) signatures(4) ecdsa‐with‐SHA2(3) 4}{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) rsassa-pss(10)}*Not used for signing publicly trusted end entity Certificates

GlobalSign uses signature algorithms and encodings in line with the applicable CA/Browser Forum
Requirements section 7.1.3.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

80 of 98

GlobalSign Certification Practice Statement

7.1.4

Name Forms

GlobalSign issues Certificates with name forms compliant to RFC 5280 and section 7.1.4 of theapplicable CA/Browser Forum Requirements.
S/MIME Certificates may include a user principal name (UPN) in the otherName entry within thesubjectAltName extension.
OCSP Responder Certificates may include a subject serialNumber attribute to fulfil DN uniquenessrequirements.
7.1.5

CertificatesName Constraints

GlobalSign may issue Subordinate CA Certificates with name constraints and mark as critical whereapplicable. When name constraints are not set on a Subordinate CA, such CA must be subject for
full audit specified in section 8.0 of this document.
GlobalSign name constrains using the following methods:• If the certificate includes the id-kp-serverAuth extended key usage, then the certificate must
be name constrained with constraints on dNSName, iPAddress and DirectoryName as
described in section 7.1.2.5.2 Baseline Requirements for TLS.
• If the certificate includes the id-kp-emailProtection extended key usage, for eachrfc822Name in permittedSubtrees, each rfc822Name shall contain either a FQDN or a
U+002E FULL STOP (“.”) character followed by a FQDN. The rfc822Name shall not containan email address. GlobalSign shall confirm that the Applicant has registered the FQDN
contained in the rfc822Name or has been authorized by the domain registrant to act on theregistrant’s behalf in line with the verification practices of Section 3.2.2.3 of the Baseline
Requirements for S/MIME.
• GlobalSign may also include name constraints on Certificates with the id-kpemailProtection extended key usage with constraints on DirectoryName as described in
section 7.1.5 of the Baseline Requirements for S/MIME.
7.1.6

Certificate Policy Object Identifier

GlobalSign applies the following requirements:
Certificate type

SourceSectionTLS

Baseline Requirements

7.1.6

EV TLSEV Guidelines

9.3.2

Code Signing and EV Code Signing

Baseline Requirements for Code Signing

7.1.6

S/MIME

Baseline Requirements for S/MIME

7.1.6

Note: As of September 1, 2023, all S/MIME Certificates in scope of the Baseline Requirements for
S/MIME must include an S/MIME BR policy identifier to assert compliance with the Baseline
Requirements for S/MIME. Prior to September 1, 2023, an S/MIME BR policy identifier may be
included.
7.1.7

Usage of Policy Constraints Extension

No stipulation
7.1.8

Policy Qualifiers Syntax and Semantics

GlobalSign issues Certificates with a policy qualifier and may include suitable text to aid Relying
Parties in determining applicability.
7.1.9

Processing Semantics for the Critical Certificate Policies Extension

No stipulation

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

81 of 98

GlobalSign Certification Practice Statement

7.1.10 Serial Numbers
Each Issuing CA must issue Certificates that include a unique (within the context of the Issuer
Subject DN and CA certificate serial number) non-sequential Certificate serial number greater thanzero (0) containing at least 64 bits of output from a CSPRNG.
As an exception to RFC5280 in TLS Certificates, a TLS precertificate and Certificate share thesame serialNumber value.
7.1.11 Special Provisions for Qualified Certificates
Qualified Certificates are configured to meet the applicable profile requirements of ETSI EN 319
412 and ETSI TS 119 495.
7.1.11.1 Qualified Certificates for Electronic Signatures
Qualified Certificates for Electronic Signatures contain following qcStatements:••

id-etsi-qcs-QcCompliance
id-etsi-qct-esign

If the Private Key related to the certified Public Key resides in a QSCD “id-etsi-qcs-QcSSCD” isincluded.
Qualified Certificates for Electronic Signatures which are issued under UK eIDAS include “id-etsiqcs-QcCClegislation” with value set as GB
7.1.11.2 Qualified Certificates for Electronic Seals
Qualified Certificates for Electronic Seals contain following qcStatements:••

id-etsi-qcs-QcCompliance
id-etsi-qct-eseal

If the Private Key related to the certified Public Key resides in a QSCD “id-etsi-qcs-QcSSCD” isincluded.
Qualified Certificates for Electronic Seals which are issued for Open Banking include “id-etsi-psd2qcStatement”.
Qualified Certificates for Electronic Seals which are issued under UK eIDAS include “id-etsi-qcsQcCClegislation” with value set as GB
7.1.11.3 Qualified Web Authentication Certificates
Qualified Web Authentication Certificates contain the following qualified statements:••

id-etsi-qcs-QcCompliance
id-etsi-qct-web

Qualified Web Authentication Certificates which are issued for Open Banking include “id-etsi-psd2qcStatement”.
Qualified Web Authentication Certificates which are issued under UK eIDAS include “id-etsi-qcsQcCClegislation” with value set as GB

7.2

CRL Profile

7.2.1

Version Number(s)GlobalSign issues Version 2 CRLs in compliance with RFC 5280. CRLs have the following fields:••

IssuerEffective date

The Subject DN of the issuing CA
Date and Time

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

82 of 98

GlobalSign Certification Practice Statement

•
•
•
•
•
7.2.2

Next update
Signature Algorithm
Signature Hash Algorithm
Serial Number(s)Revocation Date

Date and Timesha256RSA etc. (Depending upon product)sha256 etc. (Depending upon product)
List of revoked serial numbers
Date of Revocation

CRL and CRL Entry Extensions

CRLs have the following extensions:••

CRL Number
Authority Key Identifier

Following extensions are supported:• ReasonCode

Monotonically increasing serial number for each CRL
AKI of the issuing CA for chaining/validation requirements

Identifies the reason for the Certificate revocation.

The extension is present for a CRL entry for a Root CA or Subordinate CA Certificate, including
Cross Certificates. Supported values are keyCompromise (1), affiliationChanged (3), superseded(4), cessationOfOperation (5), privilegeWithdrawn (9).
The extension may be present for a CRL entry for a Subscriber end entity Certificate. Supported
values are keyCompromise (1), affiliationChanged (3), superseded (4), cessationOfOperation (5),certificateHold (6), privilegeWithdrawn (9).
The value certificateHold (6) is not supported for SSL, Code Signing or S/MIME BR Certificates.

7.3

OCSP Profile

GlobalSign operates an Online Certificate Status Profile (OCSP) responder in compliance with RFC
6960 and RFC 5019 and highlights this within the AIA extension via an OCSP responder URL.
7.3.1

Version Number(s)GlobalSign issues Version 1 OCSP responses with following fields:
•
•
•
•
•
•
•

Responder ID
Produced Time
Certificate Status
ThisUpdate/NextUpdate
Signature Algorithm
Signature
Certificates

SHA-1 Hash of responder’s Public Key
The time at which this response was signed
Certificate status referenced (good/revoked/unknown)
Recommended validity interval for the response
SHA256 RSA etc. (depending upon product)
Signature value generated by the responder
The OCSP Responder’s Certificate

An OCSP request must contain the following data:• Protocol version• Service request• Target Certificate identifier
Following fields are supported:• revocationReason

Identifies the reason for the Certificate revocation.

This field is present for OCSP responses for a Root CA or Subordinate CA Certificate, including
Cross Certificates, and may be present for a Subscriber end entity Certificate, if the Certificate isrevoked. The CRLReason indicated contains a value permitted for CRLs, as specified in Section
7.2.2.
7.3.2

OCSP Extensions

The singleExtensions of an OCSP response does not contain the reasonCode (OID 2.5.29.21) CRL
entry extension.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

83 of 98

GlobalSign Certification Practice Statement

8.0 Compliance Audit and Other Assessments
The procedures within this CPS are designed to comply with the requirements listed in Section 1.0
and encompass all relevant portions of currently applicable PKI standards for the various vertical
PKI industries in which GlobalSign operates.

8.1

Frequency and Circumstances of Assessment

GlobalSign maintains its compliance with the WebTrust/eIDAS/UK eIDAS standards identified in
Section 1.0 via a Qualified Auditor on an annual (WebTrust), bi-annual (eIDAS/UK eIDAS) andcontiguous basis.

8.2

Identity/Qualifications of Assessor

The audit of GlobalSign is performed by a “Qualified Auditor” that possesses the following
qualifications and skills:
•
•
•
•
•
•

Independence from the subject of the audit.
The ability to conduct an audit that addresses the criteria specified in an Eligible Audit as
stipulated in section 8.0 of this document.
Employs individuals who have proficiency in examining Public Key Infrastructuretechnology, information security tools and techniques, information technology and security
auditing, and the third-party attestation function.
Certified, accredited, licensed, or otherwise assessed as meeting the qualification
requirements of auditors under the audit scheme.
Bound by law, government regulation, or professional code of ethics; andExcept in the case of an internal government auditing agency, maintains Professional
Liability/Errors & Omissions insurance with policy limits of at least one million ($1,000,000)
US dollars in coverage.

For eIDAS, the audit is performed by a conformity assessment body accredited by a European
Union member state national accreditation body on the basis of EN ISO/IEC 17065 as profiled by
ETSI EN 319 403 and in particular against the requirements defined in the eIDAS Regulation (EU)No 910/2014.
For UK eIDAS, the audit is performed by a conformity assessment body accredited on the basis of
EN ISO/IEC 17065 as profiled by ETSI EN 319 403 and in particular against the requirements
defined in the UK eIDAS Regulation (eIDAS (UK Legislation) and The Electronic Identification andTrust Services for Electronic Transactions Regulations 2016).

8.3

Assessor’s Relationship to Assessed Entity

GlobalSign has selected an auditor/assessor who is completely independent from GlobalSign.

8.4

Topics Covered by Assessment

The audit meets the requirements of the audit schemes highlighted in Section 1.0 under which theassessment is being made. These requirements may vary as audit schemes are updated.

8.5

Actions Taken as a Result of Deficiency

GlobalSign, including cross-signed Issuing CAs that are not technically constrained, follow thesame process if presented with a material non-compliance by auditors and create a suitablecorrective action plan to remove the deficiency. Corrective action plans which directly affect policy
and procedure as dictated by the CP and CPS are referred to the GlobalSign policy authority.

8.6

Communications of Results

Results of the audit are reported to the Policy Authority for analysis and resolution of any deficiency
through a subsequent corrective action plan. The results could also be made available to any otherappropriate entities that may be entitled to a copy of the results by law, regulation, or agreement.
Copies of GlobalSign’s WebTrust for CAs audit reports can be found at:https://www.globalsign.com/en/repository/

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

84 of 98

GlobalSign Certification Practice Statement

8.7

Self-Audit

GlobalSign monitors its adherence to Certificate Policy, Certification Practice Statement and otherexternal requirements specified in the “Acknowledgements” section and strictly control its service
quality by performing self-audits on at least a quarterly basis against randomly selected samplesof at least 3 percent (6% for EV SSL Certificate and EV Code Signing Certificates) of the Certificatesissued.
8.8

Review of delegated parties

Except for Delegated Third Parties, Enterprise RAs, and Technically Constrained Subordinate CAsthat undergo an annual audit that meets the criteria specified in Section 8.4, GlobalSign will ensure
the practices and procedures of delegated parties are in compliance with the applicable
CA/Browesr Forum Requirements and the relevant CP and/or CPS. GlobalSign documents theobligations of delegated parties and performs monitoring on at least an annual basis of thedelegated parties' adherence with those obligations.

9.0

Other Business and Legal Matters

9.1

Fees

9.1.1

Certificate Issuance or Renewal Fees

GlobalSign charges fees for Certificate issuance and renewal. GlobalSign does not charge forreissuance. Fees and any associated terms and conditions are made clear to Applicants both by
the enrollment process through a web interface or in the sales and marketing materials on
GlobalSign’s various language specific web sites.
9.1.2

Certificate Access Fees

GlobalSign may charge for access to any database which stores issued Certificates.
9.1.3

Revocation or Status Information Access Fees

GlobalSign may charge additional fees to Subscribers who have a large Relying Party communityand choose not to use OCSP stapling or other similar techniques to reduce the load on the
GlobalSign’s Certificate status infrastructure.
9.1.4

Fees for Other Services

GlobalSign may charge for other additional services such as timestamping.
9.1.5

Refund Policy

For customers who have a direct relationship with GlobalSign and Certificates ordered directly from
GlobalSign, if a Subscriber is not completely satisfied with the issued Certificate, the Subscriber
may request a refund within 7 days of the Certificate being issued. Any refunds will be net of any
fees incurred by GlobalSign.

9.2
9.2.1

Financial Responsibility
Insurance Coverage

GlobalSign NV/SA maintains commercial general liability insurance with policy limits of at least two
million US dollars ($2,000,000) in coverage and Errors and Omissions / Professional Liability
insurance with a policy limit of at least five million US dollars ($5,000,000) in coverage. GlobalSign's
insurance policies include coverage for (1) claims for damages arising out of an act, error, oromission, unintentional breach of contract, or neglect in issuing or maintaining EV Certificates, and(2) claims for damages arising out of infringement of the proprietary rights of any third party(excluding copyright, patent, and trademark infringement), invasion of privacy, and advertising
injury. Insurance is carried through companies rated no less than A- as to Policy Holder's Rating in
the current edition of Best’s Insurance Guide (or with an association of companies, each of themembers of which are so rated).
9.2.2

Other Assets

No stipulation

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

85 of 98

GlobalSign Certification Practice Statement

9.2.3

Insurance or Warranty Coverage for End Entities

GlobalSign offers a Warranty Policy to Subscribers published on GlobalSign’s web site athttps://www.globalsign.com/en/company/corporate-policies.

9.3

Confidentiality of Business Information

9.3.1

Scope of Confidential Information

The following items are classified as being confidential information and therefore are subject toreasonable care and attention by GlobalSign staff including Validation Specialists andadministrators:
•
•
•
•
•
9.3.2

Personal Information as detailed in Section 9.4.
Audit logs from CA and RA systems.
Activation data used to active CA Private Keys as detailed in Section 6.4.
Internal GlobalSign business process documentation including Disaster Recovery Plans(DRP) and Business Continuity Plans (BCP); andAudit Reports from an independent auditor as detailed in Section 8.0.
Information Not Within the Scope of Confidential Information

Any information not defined as confidential within this CPS shall be deemed public. Certificate
status information and Certificates themselves are deemed public.
9.3.3

Responsibility to Protect Confidential Information

GlobalSign protects confidential information through training and enforcement with employees,
agents, and contractors.

9.4
9.4.1

Privacy of Personal Information
Privacy Plan

GlobalSign protects personal information in accordance with a Privacy Policy published on
GlobalSign’s web site at https://www.globalsign.com/repository.
9.4.2

Information Treated as Private

GlobalSign treats all personal information about an Individual that is not publicly available in thecontents of a Certificate as private information. This includes information that links a Pseudonym
to the real identity of the Subject Individual and applies both to those Applicants who are successful
in being issued a Certificate and those who are unsuccessful and rejected.
GlobalSign periodically trains all RA and vetting staff as well as anyone who has access to theinformation about due care and attention that must be applied.
9.4.3

Information Not Deemed Private

Certificate status information and any Certificate content is deemed not private.
9.4.4

Responsibility to Protect Private Information

GlobalSign is responsible for securely storing private information in accordance with a published
Privacy Policy document and may store information received in either paper or digital form.
GlobalSign protects private information using appropriate safeguards and a reasonable degree ofcare and requires the same from any service providers who handle private information on behalf of
the GlobalSign or an RA.
9.4.5

Notice and Consent to Use Private Information

Personal information obtained from Applicants during the application and enrollment process isdeemed private and permission is required from the Applicant to allow the use of such information.
GlobalSign includes any required consents in the Subscriber Agreement, including any permission
required for additional information to be obtained from third parties that may be applicable to thevalidation process for the product or service being offered by GlobalSign. GlobalSign requires thesame from any service providers who handle private information on behalf of the GlobalSign or an
RA.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

86 of 98

GlobalSign Certification Practice Statement

9.4.6

Disclosure Pursuant to Judicial or Administrative Process

GlobalSign may disclose private information where required to do so by law or regulation, without
notice to Applicants or Subscribers.
9.4.7

Other Information Disclosure Circumstances

No Stipulation.

9.5

Intellectual Property Rights

GlobalSign does not knowingly violate the intellectual property rights of third parties. Public andPrivate Keys remain the property of Subscribers who legitimately hold them. GlobalSign retains
ownership of Certificates; however, it grants permission to reproduce and distribute Certificates ona non-exclusive, royalty free basis, provided that they are reproduced and distributed in full.
GlobalSign and the GlobalSign logo are the registered trademarks of GMO GlobalSign K.K.

9.6

Representations and Warranties

9.6.1

CA Representations and Warranties

GlobalSign uses this CPS and applicable Subscriber Agreements to convey legal conditions ofusage of issued Certificates to Subscribers and Relying Parties.
By issuing a Certificate, GlobalSign makes the warranties listed herein to the following Certificate
Beneficiaries:
1. The Subscriber that is a party to the Subscriber Agreement or Terms of Use for the
Certificate;
2. All Application Software Suppliers with whom the Root CA has entered into a contract forinclusion of its Root CA Certificate in software distributed by such Application Software
Supplier; and3. All Relying Parties who reasonably rely on a Valid Certificate.
GlobalSign represents and warrants to Certificate Beneficiaries, during the period when theCertificate is valid, Issuing CA has complied with its Certificate Policy and/or Certification PracticeStatement in issuing and managing the Certificate:
9.6.1.1

General representations and warranties

For SSL, EV SSL, SMIME, Code Signing and EV Code Signing Certificates, GlobalSign represents
and warrants to Certificate Beneficiaries, during the period when the Certificate is valid, GlobalSign
has complied with its Certificate Policy and/or Certification Practice Statement in issuing andmanaging the Certificate and:•••Right to Use Domain Name or IP Address: For SSL Certificates, that, at the time ofissuance, GlobalSign (i) implemented a procedure for verifying that the Applicant either
had the right to use, or had control of, the Domain Name(s) and IP address(es) listed in
the Certificate’s Subject field and subjectAltName extension (or, only in the case of
Domain Names, was delegated such right or control by someone who had such right touse or control); (ii) followed the procedure when issuing the Certificate; and (iii) accurately
described the procedure in GlobalSign’s Certificate Policy and/or Certification PracticeStatement (see Section 3.2).
Right to Use Mailbox Address: For SMIME Certificates, that, at the time of issuance,
GlobalSign (i) implemented a procedure for verifying that the Applicant either had theright to use, or had control of, the Mailbox Addresses listed in the Certificate's subject
field and subjectAltName extension (or was delegated such right or control by someone
who had such right to use or control); (ii) followed the procedure when issuing theCertificate; and iii. accurately described the procedure in GlobalSign's CP and/or CPS(see Section 3.2).
Authorization for Certificate: That, at the time of issuance, GlobalSign (i) operated aprocedure for verifying that the Subject authorized the issuance of the Certificate and that
the Applicant Representative is authorized to request the Certificate on behalf of the
Subject; (ii) followed the procedure when issuing the Certificate; and (iii) accurately

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

87 of 98

GlobalSign Certification Practice Statement

•

•

•

•

•
9.6.1.2

described the procedure in GlobalSign’s Certificate Policy and/or Certification PracticeStatement (see Section 3.2.5);
Accuracy of Information: That, at the time of issuance, GlobalSign (i) operated aprocedure for verifying all of the information contained in the Certificate (with the exceptionof the subject:organizationalUnitName and subject:serialNumber (non-EV Certificates)
attribute) was true and accurate; (ii) followed the procedure when issuing the Certificate;and (iii) accurately described the procedure in GlobalSign’s Certificate Policy and/or
Certification Practice Statement (see Sections 3.2.2, 3.2.3, 3.2.4);
Identity of Applicant: That, if the Certificate contains Subject Identity Information,
GlobalSign (i) operated a procedure to verify the identity of the Applicant in accordancewith Section 3.2 and Section 7 of the applicable CA/Browser Forum Requirements; (ii)followed the procedure when issuing and managing the Certificate; and (iii) accurately
described the procedure in GlobalSign’s Certificate Policy and/or Certification PracticeStatement (see Sections 3.2.3, 3.2.3, 3.2.4);
Subscriber Agreement: That, if GlobalSign and Subscriber are not Affiliates, theSubscriber and CA are parties to a legally valid and enforceable Subscriber Agreementthat satisfies the applicable CA/Browser Forum Requirements or, if GlobalSign and
Subscriber are Affiliates, the Applicant Representative acknowledged and accepted theTerms of Use (see Section 4.1);
Status: That GlobalSign maintains a 24 x 7 publicly accessible Repository with current
information regarding the status of Certificates as valid or revoked for the period requiredby the applicable CA/Browser Forum Requirements; andRevocation: That GlobalSign will revoke the Certificate for any of the reasons specified
in the applicable CA/Browser Forum Requirements (see Section 4.9.1).
Representations and warranties for Code Signing Certificates

For Code Signing Certificates, in addition to the representations and warranties specified in section
9.6.1.1, GlobalSign represents and warrants to Certificate Beneficiaries, during the period when
the Certificate is valid:•Compliance: GlobalSign and any Signing Service has complied with the Baseline
Requirements for Code Signing and the applicable Certificate Policy and Certification
Practice Statement in issuing each Code Signing Certificate and operating its PKI or
Signing Service;•

Legal Existence: For EV Code Signing Certificates, GlobalSign has confirmed with the
Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation orRegistration that, as of the date the EV Code Signing Certificate was issued, the Subjectof the EV Code Signing Certificate legally exists as a valid organization or entity in the
Jurisdiction of Incorporation or Registration;•

Identity of Subscriber: At the time of issuance, GlobalSign or Signing Service represents
that it (i) operated a procedure for verifying the identity of the Subscriber that at least meetsthe requirements in Section 3.2 of this document, (ii) followed the procedure when issuingor managing the Certificate, and (iii) accurately described the same procedure in
GlobalSIgn's Certificate Policy or Certification Practice Statement;•

Key Protection: GlobalSign represents that it provided the Subscriber at the time ofissuance with documentation on how to securely store and prevent the misuse of Private
Keys associated with Code Signing Certificates, or in the case of a Signing Service,
securely stored and prevented the misuse of Private Keys associated with Code Signing
Certificates; and•Subscriber Agreement: GlobalSign and Signing Service represent that GlobalSign or
Signing Service entered into a legally valid and enforceable Subscriber Agreement with theApplicant that satisfies these Requirements or, if they are affiliated, the Applicant
Representative has acknowledged and accepted the Terms of Use.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

88 of 98

GlobalSign Certification Practice Statement

9.6.1.3

Representations and warranties for EV SSL and EV Code Signing Certificates

For EV SSL and EV Code Signing Certificates, in addition to the representations and warranties
specified in section 9.6.1.1, GlobalSign represents and warrants to Certificate Beneficiaries, during
the period when the Certificate is valid:
•

•

•

•

•

9.6.1.4

Legal Existence: GlobalSign has confirmed with the Incorporating or Registration Agency
in the Subject’s Jurisdiction of Incorporation or Registration that, as of the date theCertificate was issued, the Subject named in the Certificate legally exists as a validorganization or entity in the Jurisdiction of Incorporation or Registration;
Identity: GlobalSign has confirmed that, as of the date the Certificate was issued, the legalname of the Subject named in the Certificate matches the name on the official government
records of the Incorporating or Registration Agency in the Subject’s Jurisdiction ofIncorporation or Registration, and if an assumed name is also included, that the assumed
name is properly registered by the Subject in the jurisdiction of its Place of Business;
Right to Use Domain Name: For EV SSL Certificates, GlobalSign has taken all steps
reasonably necessary to verify that, as of the date the Certificate was issued, the Subject
named in the Certificate has the right to use all the Domain Name(s) listed in the Certificate;
Authorization for EV Certificate: GlobalSign has taken all steps reasonably necessary toverify that the Subject named in the Certificate has authorized the issuance of theCertificate; andSubscriber Agreement: The Subject named in the Certificate has entered into a legallyvalid and enforceable Subscriber Agreement with GlobalSign that satisfies therequirements of these Guidelines or, if they are affiliated, the Applicant Representative has
acknowledged and accepted the Terms of Use.
Representations and warranties for NAESB Certificates

For NAESB Certificates, in addition to the representations and warranties specified in section
9.6.1.1, GlobalSign represents and warrants to Certificate Beneficiaries, during the period when
the Certificate is valid:• GlobalSign has issued, and will manage, the Certificate in accordance with the NAESBWEQ PKI Standard;• GlobalSign has complied with all requirements in the NAESB WEQ PKI Standards whenidentifying the Subscriber and issuing the Certificate;• There are no misrepresentations of fact in the Certificate actually known to or reasonably
knowable by GlobalSign and GlobalSign has verified information in the Certificate;• Information provided by the Applicant for inclusion in the Certificate has been accuratelytranscribed to the Certificate; and• The Certificate meets the material requirements of the NAESB WEQ PKI standards.
9.6.2

RA Representations and Warranties

RAs warrant that:
•
•
•
9.6.3

Issuance processes are in compliance with this CPS and the relevant CP.
All information provided to GlobalSign does not contain any misleading or false information;andAll translated material provided by the RA is accurate.
Subscriber Representations and Warranties

GlobalSign requires, as part of the Subscriber Agreement or Terms of Use, that the Applicant makethe commitments and warranties in this section for the benefit of GlobalSign and the Certificate
Beneficiaries.
Prior to the issuance of a Certificate, GlobalSign obtains, for the express benefit of GlobalSign and
the Certificate Beneficiaries, either the Applicant's:
1. Agreement to the Subscriber Agreement with GlobalSign; or
2. Acknowledgement of the Terms of Use.
GlobalSign CPS (Certification Practice Statement)
Version: 10.1

89 of 98

GlobalSign Certification Practice Statement

GlobalSign implements a process to ensure that each Subscriber Agreement or Terms of Use islegally enforceable against the Applicant. In either case, the Agreement applies to the Certificate
to be issued pursuant to the Certificate request.
A separate agreement may be used for each Certificate request, or a single agreement may be
used to cover multiple future Certificate requests and the resulting Certificates, so long as each
Certificate that GlobalSign issues to the Applicant is clearly covered by that Subscriber Agreement
or Terms of Use.
The Subscriber Agreement or Terms of Use contains provisions imposing on the Applicant itself (ormade by the Applicant on behalf of its principal or agent under a subcontractor or hosting service
relationship) the following obligations and warranties:
Subscribers and/or Applicants warrant that:
•

•

•

•

•

•

•

Accuracy of Information: Subscriber will provide accurate and complete information at
all times to GlobalSign, both in the Certificate request and as otherwise requested by
GlobalSign in connection with issuance of a Certificate;Protection of Private Key: Applicant shall take all reasonable measures to maintain solecontrol of, keep confidential, and properly protect at all times the Private Key to be includedin the requested Certificate(s) and any associated activation data or device, e.g., password
or token; For Code Signing Certificates, Subscriber shall maintain sole control of, keep
confidential, and properly protect, at all times in accordance with Section 6.2.7.4 of theBaseline Requirements for Code Signing, the Private Key that corresponds to the Public
Key to be included in the requested Certificate(s) (and any associated activation data or
device, e.g. password or token). Subscriber represents that it will generate and operate
any device storing private keys in a secure manner. Subscriber shall use passwords thatare randomly generated with at least 16 characters containing uppercase letters, lowercase
letters, numbers, and symbols to transport private keys.
Private Key Reuse: For Code Signing Certificates, Subscriber shall not apply for a CodeSigning Certificate if the Public Key in the Certificate is or will be used with a non-CodeSigning Certificate;
Acceptance of Certificate: Subscriber shall not to use the Certificate until after the
Applicant, or an agent of Applicant, has reviewed and verified the Certificate contents for
accuracy.
Use of Certificate: For TLS Certificates, Subscriber shall install the Certificate only on
servers that are accessible at the subjectAltName(s) listed in the Certificate, and use theCertificate solely in compliance with all applicable laws and solely in accordance with the
Subscriber Agreement or Terms of Use. For S/MIME Certificates, Subscriber shall use theCertificate only on Mailbox Addresses listed in the Certificate, and to use the Certificate
solely in compliance with all applicable laws and solely in accordance with the Subscriber
Agreement or Terms of Use. For Code Signing Certificates, Subscriber shall use theCertificate and associated Private Key only for authorized and legal purposes, including
not using the Certificate to sign Suspect Code and to use the Certificate and Private Key
solely in compliance with all applicable laws and solely in accordance with the Subscriber
Agreement or Terms of Use;
Prevention of Misuse: For Code Signing Certificates, Subscriber shall provide adequate
network and other security controls to protect against misuse of the Private Key and that
GlobalSign will revoke the Certificate without requiring prior notification if there isunauthorized access to the Private Keys;
Reporting and Revocation: Subscriber accepts the obligation and warranty to (a)promptly request revocation of the certificate, and cease using it and its associated Private
Key, if there is any actual or suspected misuse or compromise of the Subscriber’s Private
Key associated with the Public Key included in the Certificate; and (b) promptly request
revocation of the Certificate, and cease using it, if any information in the Certificate is or
becomes incorrect or inaccurate; or (c) there is evidence that the Certificate was used tosign Suspect Code;GlobalSign CPS (Certification Practice Statement)
Version: 10.1

90 of 98

GlobalSign Certification Practice Statement

•

•
•
•

9.6.3.1

Sharing of Information: For Code Signing Certificates, Subscriber acknowledges andaccepts that, if: (a) the Certificate or the Applicant is identified as a source of Suspect Code,(b) the authority to request the Certificate cannot be verified, or (c) the Certificate is revoked
for reasons other than Subscriber request (e.g. as a result of private key compromise,
discovery of malware, etc.), then GlobalSign is authorized to share information about the
Applicant, signed application, Certificate, and surrounding circumstances with other CAs
or industry groups, including the CA/Browser Forum;
Termination of Use of Certificate: Subscriber shall promptly cease use of Private Key
associated with the Public Key in the Certificate upon revocation of that Certificate; andResponsiveness: Subscriber shall respond to GlobalSign’s instructions concerning
Compromise or Certificate misuse within forty-eight (48) hours; andAcknowledgment and Acceptance: Applicant acknowledges and accepts that
GlobalSign is entitled to revoke the Certificate immediately if the Applicant violates theterms of the Subscriber Agreement or Terms of Use or if revocation is required by
GlobalSign's CP and/or CPS, or by the applicable CA/Browser Forum Requirements.
North American Energy Standards Board (NAESB) Subscribers

End entities participating in the Business Practice Standard WEQ-012 v3.0 using Certificates for
WEQ-012 applications shall be required to be registered in the NAESB EIR and furnish proof thatthey are an entity authorized to engage in the wholesale electricity industry. Entities ororganizations that may require access to applications using authentication specified under the
NAESB WEQ PKI Standards, but do not qualify as a wholesale electricity market participant (e.g.,
regulatory agencies, universities, consulting firms, etc.) must register.
Registered end entities and the user community they represent shall be required to meet all end
entity obligations in the NAESB WEQ PKI Standards.
Each Subscriber organization acknowledges their understanding of the following obligations of the
NAESB WEQ PKI Standards through GlobalSign as follows:
Each end entity organization shall certify to their certification entity that they have reviewed andacknowledge the following NAESB WEQ PKI Standards.
A. End entity acknowledges the electric industry’s need for secure private electronic
communications that facilitate the following purposes:••••

Privacy: The assurance to an entity that no one can read a particular piece of data except
the receiver(s) explicitly intended.
Authentication: The assurance to one entity that another entity is who he/she/it claims tobe.
Integrity: The assurance to an entity that data has not been altered (intentionally orunintentionally) between “there” and “here,” or between “then” and “now”; andNon-Repudiation/contentCommitment: A party cannot deny having engaged in thetransaction or having sent the electronic message.

End entity acknowledges the industry’s endorsement of Public Key cryptography which utilizes
Certificates to bind a person’s or computer system’s Public Key to its entity and to support
symmetric encryption key exchange.
B. End entity has evaluated each of its selected Certification Authority’s Certification PracticeStatement in light of those industry standards as identified by the Certification Authority.
When applicable, end entities shall be obligated to register their legal business identification andsecure an “Entity Code” that will be published in the NAESB EIR and used in all Subscriber
applications submitted by, and Certificates issued to, that end entity.
End entities shall also be required to comply with the following requirements:

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

91 of 98

GlobalSign Certification Practice Statement

•
•
•
•
•

•
9.6.4

Protect their Private Keys from access by other parties.
When applicable, identify, through the NAESB EIR, the specific entity they have selected
GlobalSign to use as their Authorized Certification Authority.
Execute all agreements and contracts with GlobalSign as required by GlobalSign’s
Certification Practice Statement necessary for GlobalSign to issue Certificates to the end
entity for use in securing electronic communications.
Comply with all obligations required and stipulated by GlobalSign in this CPS, e.g.,
Certificate application procedures, Applicant identity proofing/verification, and Certificate
management practices.
Confirm that it has a PKI Certificate management program, has trained all affected
employees in that program, and has established controls to ensure compliance with that
program. This program shall include, but is not limited to:o Certificate Private Key security and handling policy(ies)o Certificate revocation policy(ies)
Identify the type of Subscriber (I.e., individual, role, device, or application) and provide
complete and accurate information for each Certificate request.
Relying Party Representations and Warranties

Prior to relying on a Certificate, Relying Parties must accept the Relying Party Agreement and act
in accordance with the Relying Party Agreement and this CPS.
A party relying on a Certificate warrants to:
•
•
•
•
•
•

Have the technical capability to use Certificates.
Receive notice of the Issuing CA and associated conditions for Relying Parties.
Validate an Issuing CA’s Certificate by using Certificate status information (e.g., a CRL or
OCSP) published by the Issuing CA in accordance with the proper Certificate pathvalidation procedure.
Trust an Issuing CA’s Certificate only if all information featured on such Certificate can beverified via such a validation procedure as being correct and up to date.
Rely on an Issuing CA’s Certificate, only as it may be reasonable under the circumstances;andNotify the appropriate RA immediately, if the Relying Party becomes aware of or suspects
that a Private Key has been Compromised.

The obligations of the Relying Party, if it is to reasonably rely on a Certificate, are to:•••

Verify the validity or revocation of the CA Certificate using current revocation status
information as indicated to the Relying Party.
Take account of any limitations on the usage of the Certificate indicated to the Relying
Party either in the Certificate or this CPS; andTake any other precautions prescribed in the Issuing CA’s Certificate as well as any otherpolicies or terms and conditions made available in the application context a Certificate
might be used.

Relying Parties must at all times establish that it is reasonable to rely on a Certificate under thecircumstances taking into account circumstances such as the specific application context a
Certificate is used in.
9.6.4.1

North American Energy Standards Board (NAESB) Relying Parties

Relying Party obligations shall be specified within the context of each NAESB requirement that
employs these NAESB WEQ PKI Standards, in addition to the following:••••

the Certificate was issued by GlobalSign, a registered Authorized Certification Authority.
the entire Certificate validation/trust chain to GlobalSign for NAESB issuing Authorized
Certification Authority Root Certificate is intact and valid.
the Certificate is valid and has not been revoked; andthe Certificate was issued under one of the NAESB assurance level object identifiers.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

92 of 98

GlobalSign Certification Practice Statement

9.6.4.2

Relying Parties for Qualified Certificates

For Qualified Certificates under the payment services Directive (EU) 2015/2366 or Open Banking,a Relying Party must take into account the legislation applicable to Relying Party and the Certificate
Subject. At least the following information included in the Certificate must be considered by a
Relying Party:••

Competent Authority
Payment service provider or financial institution

For Qualified Certificates which include the LRA OID 1.3.6.1.4.1.4146.1.45.1, affiliation of thenatural person with the organization as indicated in the certificate must be considered.
9.6.5

Representations and Warranties of Other Participants

No stipulation.

9.7

Disclaimers of Warranties

EXCEPT TO THE EXTENT PROHIBITED BY LAW OR AS OTHERWISE PROVIDED HEREIN,
GLOBALSIGN DISCLAIMS ALL WARRANTIES INCLUDING ANY WARRANTY OF
MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.

9.8

Limitations of Liability

TO THE EXTENT GLOBALSIGN HAS ISSUED AND MANAGED THE CERTIFICATE IN
ACCORDANCE WITH THE CA/BROWSER FORUM REQUIREMENTS AND THIS CPS,GLOBALSIGN SHALL NOT BE LIABLE TO THE SUBSCRIBER, RELYING PARTY OR ANY
THIRD PARTIES FOR ANY LOSSES SUFFERED AS A RESULT OF USE OR RELIANCE ON
SUCH CERTIFICATE. OTHERWISE, GLOBALSIGN’S LIABILITY TO THE SUBSCRIBER,RELYING PARTY OR ANY THIRD PARTIES FOR ANY SUCH LOSSES SHALL IN NO EVENT
EXCEED ONE THOUSAND DOLLARS ($1,000) PER CERTIFICATE; PROVIDED HOWEVER
THAT THE LIMITATION SHALL BE TWO THOUSAND DOLLARS ($2,000) PER CERTIFICATEFOR AN EV CERTIFICATE OR AN EV CODE SIGNING CERTIFICATE.
THIS LIABILITY CAP LIMITS DAMAGES RECOVERABLE OUTSIDE OF THE CONTEXT OF THE
GLOBALSIGN WARRANTY POLICY. AMOUNTS PAID UNDER THE WARRANTY POLICY ARE
SUBJECT TO THEIR OWN LIABILITY CAPS.
IN NO EVENT SHALL GLOBALSIGN BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL,
OR CONSEQUENTIAL DAMAGES, OR FOR ANY LOSS OF PROFITS, LOSS OF DATA OR
OTHER INDIRECT, INCIDENTAL, CONSEQUENTIAL DAMAGES ARISING FROM OR IN
CONNECTION WITH THE USE, DELIVERY, RELIANCE UPON, LICENSE, PERFORMANCE OR
NON-PERFORMANCE OF CERTIFICATES, DIGITAL SIGNATURES OR ANY OTHER
TRANSACTIONS OR SERVICES OFFERED OR CONTEMPLATED BY THIS CPS.
THE FOREGOING SHALL NOT LIMIT GLOBALSIGN'S LIABILITY WITH RESPECT TOQUALIFIED CERTIFCATES IN ACCORDANCE WITH ARTICLE 13 OF THE EIDAS OR UK EIDASREGULATIONS.

9.9
9.9.1

Indemnities
Indemnification by GlobalSign

GlobalSign shall defend, indemnify and hold harmless each Application Software Supplier against
any claim, damage, or loss suffered by the Application Software Supplier related to an Extended
Validation SSL Certificate or Extended Validation Code Signing Certificate issued by GlobalSign,
regardless of the cause of action or legal theory involved, except where the claim, damage, or loss
suffered by the Application Software Supplier was directly caused by the Application Software
Supplier’s software displaying either (1) a valid and trustworthy EV Certificate as not valid ortrustworthy or (2) displaying as trustworthy (i) a Certificate that has expired or (ii) a revoked
Certificate where the revocation status is available online but the Application Software Supplier’s
software failed to check or ignored the status.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

93 of 98

GlobalSign Certification Practice Statement

9.9.2

Indemnification by Subscribers

To the extent permitted by law, each Subscriber shall indemnify GlobalSign, its partners, and theirrespective directors, officers, employees, agents, and contractors against any loss, damage, or
expense, including reasonable attorney’s fees, related to (i) any misrepresentation or omission ofmaterial fact by Subscriber, regardless of whether the misrepresentation or omission was
intentional or unintentional; (ii) Subscriber’s breach of the Subscriber Agreement, this CPS, or
applicable law; (iii) the Compromise or unauthorized use of a Certificate or Private Key caused by
the Subscriber’s negligence; or (iv) Subscriber’s misuse of the Certificate or Private Key.
9.9.3

Indemnification by Relying Parties

To the extent permitted by law, each Relying Party shall indemnify GlobalSign, its partners, andany cross-signed entities, and their respective directors, officers, employees, agents, andcontractors against any loss, damage, or expense, including reasonable attorney’s fees, related to
the Relying Party’s (i) breach of the Relying Party Agreement, this CPS, or applicable law; (ii)unreasonable reliance on a Certificate; or (iii) failure to check the Certificate’s status prior to use.

9.10 Term and Termination
9.10.1 Term
This CPS remains in force until such time as communicated otherwise by GlobalSign on its web
site or Repository.
9.10.2 Termination
Notified changes are appropriately marked by an indicated version. Changes become effective
immediately upon publication.
9.10.3 Effect of Termination and Survival
GlobalSign will communicate the conditions and effect of this CPS termination via the appropriate
Repository.

9.11 Individual Notices and Communications with Participants
GlobalSign accepts notices related to this CPS by means of digitally signed messages or in paper
form. Upon receipt of a valid, digitally signed acknowledgment of receipt from GlobalSign thesender of the notice deems its communication effective. The sender must receive suchacknowledgment within twenty (20) business days, or else written notice must then be sent in paper
form through a courier service that confirms delivery or via certified or registered mail, postage
prepaid, return receipt requested, addressed to the sender. Individuals communications made to
GlobalSign must be addressed to: legal@globalsign.com or by post to GlobalSign in the addressprovided in Section 1.5.2.

9.12 Amendments
9.12.1 Procedure for Amendment
This CPS is reviewed at least every 365 days and may be reviewed more frequently. All changes
are reviewed and approved by the GlobalSign CA Governance Policy Authority before insertion.
Changes to this CPS are indicated by appropriate numbering.
9.12.2 Notification Mechanism and Period
GlobalSign will post appropriate notice on its web sites of any major or significant changes to thisCPS as well as any appropriate period by when the revised CPS is deemed to be accepted.
9.12.3 Circumstances Under Which OID Must be Changed
No stipulation

9.13 Dispute Resolution Provisions
Before resorting to any dispute resolution mechanism including adjudication or any type ofalternative dispute resolution (including without exception mini-trial, arbitration, binding expert’s
advice, co-operation monitoring and normal expert’s advice) complaining parties agree to notify
GlobalSign of the dispute to seek dispute resolution.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

94 of 98

GlobalSign Certification Practice Statement

Upon receipt of a dispute notice, GlobalSign convenes a dispute committee that advises GlobalSign
management on how to proceed with the dispute. The dispute committee convenes within twenty(20) business days from receipt of a dispute notice. The dispute committee is composed of acounsel, a data protection officer, a member of GlobalSign operational management and a security
officer. The counsel or data protection officer chair the meeting. In its resolutions the disputecommittee proposes a settlement to the GlobalSign executive management. The GlobalSign
executive management may subsequently communicate the proposed settlement to thecomplaining party.
If the dispute is not resolved within twenty (20) business days after initial notice pursuant to CPS,
parties submit the dispute to arbitration, in accordance with art. 1676-1723 of the Belgian Judicial
Code.
There will be three (3) arbitrators of whom each party proposes one while both parties of the disputechoose the third arbitrator. The place of the arbitration is Leuven, Belgium and the arbitrators
determine all associated costs.

9.14 Governing Law
This CPS is governed, construed, and interpreted in accordance with the laws of Belgium. This
choice of law is made to ensure uniform interpretation of this CPS, regardless of the place ofresidence or place of use of GlobalSign Certificates or other products and services. The law of
Belgium applies also to all GlobalSign commercial or contractual relationships in which this CPS
may apply or quoted implicitly or explicitly in relation to GlobalSign products and services where
GlobalSign acts as a provider, supplier, beneficiary receiver or otherwise.
Each party, including GlobalSign partners, Subscribers and Relying Parties, irrevocably submit to
the jurisdiction of the district courts of Leuven, Belgium.

9.15 Compliance with Applicable Law
GlobalSign complies with applicable laws of Belgium. Export of certain types of software used incertain GlobalSign public Certificate management products and services may require the approvalof appropriate public or private authorities. Parties (including GlobalSign, Subscribers and Relying
Parties) agree to comply with applicable export laws and regulations as pertaining in Belgium.

9.16 Miscellaneous Provisions
9.16.1 Entire Agreement
GlobalSign will contractually obligate every RA involved with Certificate issuance to comply withthis CPS and all applicable industry guidelines. No third party may rely on or bring action to enforce
any such agreement.
9.16.2 Assignment
Entities operating under this CPS cannot assign their rights or obligations without the prior writtenconsent of GlobalSign.
9.16.3 Severability
If any provision of this CPS, including limitation of liability clauses, is found to be invalid or
unenforceable, the remainder of this CPS will be interpreted in such manner as to affect the original
intention of the parties.
Each provision of this CPS that provides for a limitation of liability, is intended to be severable andindependent of any other provision and is to be enforced as such.
9.16.4 Enforcement (Attorney’s Fees and Waiver of Rights)
GlobalSign may seek indemnification and attorneys’ fees from a party for damages, losses andexpenses related to that party’s conduct. GlobalSign’s failure to enforce a provision of this CPS
does not waive GlobalSign’s right to enforce the same provisions later or right to enforce any otherprovisions of this CPS. To be effective any waivers must be in writing and signed by GlobalSign.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

95 of 98

GlobalSign Certification Practice Statement

9.16.5 Force Majeure
GlobalSign shall not be liable for any losses, costs, expenses, liabilities, damages, or claims arisingout of or related to delays in performance or from failure to perform its obligations if such failure ordelay is due to circumstances beyond GlobalSign’s reasonable control, including without limitation,acts of any governmental body, war, insurrection, sabotage, embargo, fire, flood, strike or other,interruption of or delay in transportation, unavailability of, interruption or delay intelecommunications or third party services.

9.17 Other Provisions
No stipulation.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

96 of 98

GlobalSign Certification Practice Statement

10.0 Appendix A
10.1 S/MIME BR Certificates10.1.1 Enterprise RA Requirements
For S/MIME BR Certificates, if company verifies Certificate requests for Subjects within its own
organization, company acts as an Enterprise RA and the following requirements apply:ComplianceEnterprise RA must comply with the provisions of the GlobalSign CP, CPS and Baseline
Requirements for S/MIME that are applicable to the Enterprise RA.
Information Security
Enterprise RA shall apply information security best practices, using trustworthy systems andproducts that are protected against modification and ensure the technical security and reliability ofthe processes supported by them.
Qualifications
Prior to the engagement of any person in the Certificate Management Process, whether as an
employee, agent, or an independent contractor, Enterprise RA shall verify the identity andtrustworthiness of such person.
Monitoring
GlobalSign has the right to perform monitoring on at least an annual basis of Enterprise RA’s
adherence with the obligations of this Agreement and the CPS.
Retention
Enterprise RA shall retain, for at least two (2) years:
All archived documentation relating to the verification, issuance, and revocation of Certificate
requests and Certificates after the later occurrence of:
1. such records and documentation were last relied upon in the verification, issuance, or
revocation of Certificate requests and Certificates; or
2. the expiration of the Subscriber Certificates relying upon such records and documentation.
10.1.1.1 Sponsor validated
For Certificates including Individual (Natural Person) attributes in conjunction with the Organization:
Individual information
Enterprise RA shall provide the subject:commonName value in the Certificate request, which mustbe either the Subject’s Personal Name or Pseudonym.
1. A Personal Name shall be a meaningful representation of the Subject’s name as verified
in the identifying documentation or Enterprise RA records. Names consisting of multiple
words are permitted. Given names joined with a hyphen are considered as one single given
name. Subjects with more than one given name may choose one or several of their given
names in any sequence. Subjects may choose the order of their given name(s) andsurname in accordance with national preference.
2. A Pseudonym shall be an identifier selected by the Enterprise RA which uniquely identifies
the Subject of the Certificate within the Organization included in thesubject:organizationName attribute.
Collection and retention
Enterprise RA shall collect, validate, and retain evidence of the following identity attributes for the
Individual:
1. Given name(s) and surname(s), which shall be current names;
2. Pseudonym (if used);
3. Title (if used); and4. Further information as needed to uniquely identify the Applicant.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

97 of 98

GlobalSign Certification Practice Statement

The attributes shall be collected, validated and evidenced based on records (e.g. Active Directory)
maintained by Enterprise RA.
Enterprise RA may reuse existing evidence to validate Individual identity if the evidence has beenobtained no more than 825 days prior to issuing the Certificate.

GlobalSign CPS (Certification Practice Statement)
Version: 10.1

98 of 98