Cybertrust Japan iTrust SSL/TLS Server Certificate Policy/ Certification Practice Statement Version 3.1 Cybertrust Japan Co., Ltd. March 13, 2026 **■ Copyright and distribution conditions of this document** This document is available under Attribution-NoDerivs (CC-BY-ND) 4.0 (or later version) of the Creative Commons license. © 2019 Cybertrust Japan Co., Ltd. Version 3.1 Creation/revision date: March 13, 2026 This document can be copied and distributed in whole or in part free of charge if the following conditions are satisfied. - Display the copyright notice, Version, and revision date on the top of pages of a whole or a part of this copies. - Set forth that full text can be obtained at https://www.cybertrust.ne.jp/ssl/repository/ if only a part of this document is distributed. - Specify the citation source appropriately when using part of this document as excerpts and citations in other documents. - Cybertrust Japan shall not be liable for any dispute or damage related to copying and distribution of this CP/CPS. - In addition, Cybertrust Japan prohibits alteration and modification in any case. For inquiries about the copyright and distribution conditions of this document, please contact us as described in 1.5.2 “Contact person” of this document. ------------------- # Revision History
Version Date Reason for Revision
1.0 September 27, 2019 Formulation of initial version
1.1 April 20, 2020
  • Modify the title name of each sections to adjust to RFC 3647.

  • ”1.1 Overview” Clarify types of requirements Cybertrust is compliant with.

  • Clarify the description of ”1.3.2 Registration Authority".

  • Add description on GDPR to “9.4.2 Information Treated as Private”.

  • Add definitions of terms in “Appendix A List of Definitions”.

  • Minor modifications on phraseology and fix of typos.

1.2 April 1, 2021
  • Modify the description listed in "5.4.1 Types of events recorded" for the clarification.

1.3 May 13, 2022
  • Modify the description listed in "5.4.1 Types of events recorded" for the clarification.

  • Minor modifications on phraseology.

1.4 September 5, 2022
  • Modify the description listed in "5.4.8 Vulnerability Assessments" for the clarification.

  • Modify "8.5 Actions Taken as a Result of Deficiency "

  • Add descriptions in Section "9.16.3 Severability"

1.5 August 4, 2023
  • Modify the relavent stipulation to compliant with Baseline Requirements for the Issuance and Management of Publicly‐Trusted S/MIME Certificates

1.6 August 31, 2023
  • Add descriptions in "6.7 Network Security Controls"

  • Modify the description listed in "9.12.1 Procedure for Amendment" for the clarification.

  • Minor modifications on phraseology

1.7 December 18,2023
  • Modify the certificate profile in "1.1 Overview"

1.8 January 25, 2024
  • Modify the name of requirement in "1.1 Overview"

  • Modify the URL listed in "2.2 Publication of Certification Information"

  • Modify the name of requirement in “Appendix A List of Definitions”

  • Minor modifications on phraseology

1.9 June 28, 2024
  • Move "1.3.3 Issuing Authorities" to "1.3.1.1 Issuing Authorities"

  • Modify description listed in "1.3.3 Subscribers"

  • Clarify “1.3.5 Other Participants”

  • Modify description listed in "2.4 Access controls on repositories"

  • Add “5.4.1.1 Router and firewall activities logs”

  • Add subsection to “7.1 Certificate profile”, “7.2 CRL profile”,”7.3 OCSP profile”,”9.1 Fees” and “9.2 Financial responsibility”

  • Minor modifications on phraseology

1.10 September 13, 2024
  • Add descriptions in “5.4.1 Types of events recorded”

  • Add descriptions in “6.5.1 Specific computer security technical requirements”

  • Add definitions in "Appendix A List of Definitions"

  • Minor modifications on phraseology

1.11 December 23, 2024
  • To address "Organization-validated Strict Generation of Baseline Requirements for the Issuance and Management of Publicly‐Trusted S/MIME Certificates", added CA and subscriber certificate profiles and modified the related stipulation

1.12 June 1, 2025
  • Amendments made due to the change of product name

2.0 July 15, 2025
  • Integrated CPS(Cybertrust Japan Certification Practice Statement, this document) and CP(Cybertrust Japan iTrust SSL/TLS Server Certificate Policy), and revised as this CP/CPS(Cybertrust Japan iTrust SSL/TLS Server Certificate Policy/ Certification Practice Statement)

2.1 September 17, 2025
  • Add descriptions in Section "6.7 Network security controls"

2.2 October 31, 2025
  • Corrected the conditions under which a CAA record lookup is considered a failure in “3.2.2.8 CAA Records”

  • Added the values permitted for issuance from the CA to “4.2.1 Performing identification and authentication functions”

  • Added " 5.7.1.1 Incident Response and Disaster Recovery Plans" and " 5.7.1.2 Mass Revocation Plans" to " 5.7.1 Incident and compromise handling procedures"

  • Other minor modifications

3.0 December 22, 2025
  • Integrated the “Cybertrust Japan iTrust EV SSL/TLS Server Certificate Policy/ Certification Practice Statement” into this CP/CPS (Cybertrust Japan iTrust SSL/TLS Server Certificate Policy/ Certification Practice Statement)

  • Added a statement in "1.1 Overview" that the English version of this CP/CPS takes precedence

  • Added statements regarding DNSSEC validation after March 2026 to “3.2.2.4 Validation of Domain Authorization or Control” and “3.2.2.8 CAA Records”

  • Added a statement regarding the shortened reuse period of validation results after March 15, 2026, to “4.2.1 Performing identification and authentication functions”

  • Added a statement regarding the shortened validity period of subscriber certificates on or after March 15, 2026 to “6.3.2 Certificate operational periods and key pair usage periods”

  • Other minor modifications

3.1 March 13, 2026
  • Modified the reuse period for validation results in “3.2.2.5 Authentication for an IP Address” due to the shortening of the requirements

  • Modified “4.2.1 Performing identification and authentication functions” for clarification

  • Added domain names that end in an IP Reverse Zone Suffix as non-issuable domains in “4.2.2 Approval or rejection of certificate applications”

  • Modified “4.9.1.1 Reasons for Revoking a Subscriber Certificate” for clarification

  • Modified “6.3.2 Certificate operational periods and key pair usage periods” for clarification

  • Other minor modifications

----------- # Contents - [Revision History](#revision-history) - [Contents](#contents) - [1. INTRODUCTION](#1-introduction) - [1.1 Overview](#11-overview) - [1.2 Document name and identification](#12-document-name-and-identification) - [1.3 PKI participants](#13-pki-participants) - [1.3.1 Certification authorities](#131-certification-authorities) - [1.3.1.1 Issuing Authorities](#1311-issuing-authorities) - [1.3.2 Registration authorities](#132-registration-authorities) - [1.3.3 Subscribers](#133-subscribers) - [1.3.4 Relying parties](#134-relying-parties) - [1.3.5 Other participants](#135-other-participants) - [1.4 Certificate usage](#14-certificate-usage) - [1.4.1 Appropriate certificate uses](#141-appropriate-certificate-uses) - [1.4.2 Prohibited certificate uses](#142-prohibited-certificate-uses) - [1.5 Policy administration](#15-policy-administration) - [1.5.1 Organization administering the document](#151-organization-administering-the-document) - [1.5.2 Contact person](#152-contact-person) - [1.5.3 Person determining CP/CPS suitability for the policy](#153-person-determining-cpcps-suitability-for-the-policy) - [1.5.4 CP/CPS approval procedures](#154-cpcps-approval-procedures) - [1.6 Definitions and acronyms](#16-definitions-and-acronyms) - [2. PUBLICATION AND REPOSITORY RESPONSIBILITIES](#2-publication-and-repository-responsibilities) - [2.1 Repositories](#21-repositories) - [2.2 Publication of certification information](#22-publication-of-certification-information) - [2.3 Time or frequency of publication](#23-time-or-frequency-of-publication) - [2.4 Access controls on repositories](#24-access-controls-on-repositories) - [3. IDENTIFICATION AND AUTHENTICATION](#3-identification-and-authentication) - [3.1 Naming](#31-naming) - [3.1.1 Types of names](#311-types-of-names) - [3.1.2 Need for names to be meaningful](#312-need-for-names-to-be-meaningful) - [3.1.3 Anonymity or pseudonymity of subscribers](#313-anonymity-or-pseudonymity-of-subscribers) - [3.1.4 Rules for interpreting various name forms](#314-rules-for-interpreting-various-name-forms) - [3.1.5 Uniqueness of names](#315-uniqueness-of-names) - [3.1.6 Recognition, authentication, and role of trademarks](#316-recognition-authentication-and-role-of-trademarks) - [3.2 Initial identity validation](#32-initial-identity-validation) - [3.2.1 Method to prove possession of private key](#321-method-to-prove-possession-of-private-key) - [3.2.2 Authentication of organization identity](#322-authentication-of-organization-identity) - [3.2.2.1 Identity](#3221-identity) - [3.2.2.2 DBA/Tradename](#3222-dbatradename) - [3.2.2.3 Verification of Country](#3223-verification-of-country) - [3.2.2.4 Validation of Domain Authorization or Control](#3224-validation-of-domain-authorization-or-control) - [3.2.2.4.1 Validating the Applicant as a Domain Contact](#32241-validating-the-applicant-as-a-domain-contact) - [3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact](#32242-email-fax-sms-or-postal-mail-to-domain-contact) - [3.2.2.4.3 Phone Contact with Domain Contact](#32243-phone-contact-with-domain-contact) - [3.2.2.4.4 Constructed Email to Domain Contact](#32244-constructed-email-to-domain-contact) - [3.2.2.4.5 Domain Authorization Document](#32245-domain-authorization-document) - [3.2.2.4.6 Agreed‐Upon Change to Website](#32246-agreedupon-change-to-website) - [3.2.2.4.7 DNS Change](#32247-dns-change) - [3.2.2.4.8 IP Address](#32248-ip-address) - [3.2.2.4.9 Test Certificate](#32249-test-certificate) - [3.2.2.4.10 TLS Using a Random Value](#322410-tls-using-a-random-value) - [3.2.2.4.11 Any Other Method](#322411-any-other-method) - [3.2.2.4.12 Validating Applicant as a Domain Contact](#322412-validating-applicant-as-a-domain-contact) - [3.2.2.4.13 Email to DNS CAA Contact](#322413-email-to-dns-caa-contact) - [3.2.2.4.14 Email to DNS TXT Contact](#322414-email-to-dns-txt-contact) - [3.2.2.4.15 Phone Contact with Domain Contact](#322415-phone-contact-with-domain-contact) - [3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact](#322416-phone-contact-with-dns-txt-record-phone-contact) - [3.2.2.4.17 Phone Contact with DNS CAA Phone Contact](#322417-phone-contact-with-dns-caa-phone-contact) - [3.2.2.4.18 Agreed‐Upon Change to Website v2](#322418-agreedupon-change-to-website-v2) - [3.2.2.4.19 Agreed‐Upon Change to Website - ACME](#322419-agreedupon-change-to-website---acme) - [3.2.2.4.20 TLS Using ALPN](#322420-tls-using-alpn) - [3.2.2.4.21 DNS Labeled with Account ID - ACME](#322421-dns-labeled-with-account-id---acme) - [3.2.2.5 Authentication for an IP Address](#3225-authentication-for-an-ip-address) - [3.2.2.5.1 Agreed‐Upon Change to Website](#32251-agreedupon-change-to-website) - [3.2.2.5.2 Email, Fax, SMS, or Postal Mail to IP Address Contact](#32252-email-fax-sms-or-postal-mail-to-ip-address-contact) - [3.2.2.5.3 Reverse Address Lookup](#32253-reverse-address-lookup) - [3.2.2.5.4 Any Other Method](#32254-any-other-method) - [3.2.2.5.5 Phone Contact with IP Address Contact](#32255-phone-contact-with-ip-address-contact) - [3.2.2.5.6 ACME “http-01” method for IP Addresses](#32256-acme-http-01-method-for-ip-addresses) - [3.2.2.5.7 ACME “tls-alpn-01” method for IP Addresses](#32257-acme-tls-alpn-01-method-for-ip-addresses) - [3.2.2.6 Wildcard Domain Validation](#3226-wildcard-domain-validation) - [3.2.2.7 Data Source Accuracy](#3227-data-source-accuracy) - [3.2.2.8 CAA Records](#3228-caa-records) - [3.2.2.9 Multi-Perspective Issuance Corroboration](#3229-multi-perspective-issuance-corroboration) - [3.2.3 Authentication of individual identity](#323-authentication-of-individual-identity) - [3.2.4 Non-verified subscriber information](#324-non-verified-subscriber-information) - [3.2.5 Validation of authority](#325-validation-of-authority) - [3.2.6 Criteria for interoperation](#326-criteria-for-interoperation) - [3.3 Identification and authentication for re-key requests](#33-identification-and-authentication-for-re-key-requests) - [3.3.1 Identification and authentication for routine re-key](#331-identification-and-authentication-for-routine-re-key) - [3.3.2 Identification and authentication for re-key after revocation](#332-identification-and-authentication-for-re-key-after-revocation) - [3.4 Identification and authentication for revocation request](#34-identification-and-authentication-for-revocation-request) - [4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS](#4-certificate-life-cycle-operational-requirements) - [4.1 Certificate Application](#41-certificate-application) - [4.1.1 Who can submit a certificate application](#411-who-can-submit-a-certificate-application) - [4.1.2 Enrollment process and responsibilities](#412-enrollment-process-and-responsibilities) - [4.2 Certificate application processing](#42-certificate-application-processing) - [4.2.1 Performing identification and authentication functions](#421-performing-identification-and-authentication-functions) - [4.2.2 Approval or rejection of certificate applications](#422-approval-or-rejection-of-certificate-applications) - [4.2.3 Time to process certificate applications](#423-time-to-process-certificate-applications) - [4.3 Certificate issuance](#43-certificate-issuance) - [4.3.1 CA actions during certificate issuance](#431-ca-actions-during-certificate-issuance) - [4.3.2 Notification to subscriber by the CA of issuance of certificate](#432-notification-to-subscriber-by-the-ca-of-issuance-of-certificate) - [4.4 Certificate acceptance](#44-certificate-acceptance) - [4.4.1 Conduct constituting certificate acceptance](#441-conduct-constituting-certificate-acceptance) - [4.4.2 Publication of the certificate by the CA](#442-publication-of-the-certificate-by-the-ca) - [4.4.3 Notification of certificate issuance by the CA to other entities](#443-notification-of-certificate-issuance-by-the-ca-to-other-entities) - [4.5 Key pair and certificate usage](#45-key-pair-and-certificate-usage) - [4.5.1 Subscriber private key and certificate usage](#451-subscriber-private-key-and-certificate-usage) - [4.5.2 Relying party public key and certificate usage](#452-relying-party-public-key-and-certificate-usage) - [4.6 Certificate renewal](#46-certificate-renewal) - [4.6.1 Circumstance for certificate renewal](#461-circumstance-for-certificate-renewal) - [4.6.2 Who may request renewal](#462-who-may-request-renewal) - [4.6.3 Processing certificate renewal requests](#463-processing-certificate-renewal-requests) - [4.6.4 Notification of new certificate issuance to subscriber](#464-notification-of-new-certificate-issuance-to-subscriber) - [4.6.5 Conduct constituting acceptance of a renewal certificate](#465-conduct-constituting-acceptance-of-a-renewal-certificate) - [4.6.6 Publication of the renewal certificate by the CA](#466-publication-of-the-renewal-certificate-by-the-ca) - [4.6.7 Notification of certificate issuance by the CA to other entities](#467-notification-of-certificate-issuance-by-the-ca-to-other-entities) - [4.7 Certificate re-key](#47-certificate-re-key) - [4.7.1 Circumstance for certificate re-key](#471-circumstance-for-certificate-re-key) - [4.7.2 Who may request certification of a new public key](#472-who-may-request-certification-of-a-new-public-key) - [4.7.3 Processing certificate re-keying requests](#473-processing-certificate-re-keying-requests) - [4.7.4 Notification of new certificate issuance to subscriber](#474-notification-of-new-certificate-issuance-to-subscriber) - [4.7.5 Conduct constituting acceptance of a re-keyed certificate](#475-conduct-constituting-acceptance-of-a-re-keyed-certificate) - [4.7.6 Publication of the re-keyed certificate by the CA](#476-publication-of-the-re-keyed-certificate-by-the-ca) - [4.7.7 Notification of certificate issuance by the CA to other entities](#477-notification-of-certificate-issuance-by-the-ca-to-other-entities) - [4.8 Certificate modification](#48-certificate-modification) - [4.8.1 Circumstance for certificate modification](#481-circumstance-for-certificate-modification) - [4.8.2 Who may request certificate modification](#482-who-may-request-certificate-modification) - [4.8.3 Processing certificate modification requests](#483-processing-certificate-modification-requests) - [4.8.4 Notification of new certificate issuance to subscriber](#484-notification-of-new-certificate-issuance-to-subscriber) - [4.8.5 Conduct constituting acceptance of modified certificate](#485-conduct-constituting-acceptance-of-modified-certificate) - [4.8.6 Publication of the modified certificate by the CA](#486-publication-of-the-modified-certificate-by-the-ca) - [4.8.7 Notification of certificate issuance by the CA to other entities](#487-notification-of-certificate-issuance-by-the-ca-to-other-entities) - [4.9 Certificate revocation and suspension](#49-certificate-revocation-and-suspension) - [4.9.1 Circumstances for revocation](#491-circumstances-for-revocation) - [4.9.1.1 Reasons for Revoking a Subscriber Certificate](#4911-reasons-for-revoking-a-subscriber-certificate) - [4.9.2 Who can request revocation](#492-who-can-request-revocation) - [4.9.3 Procedure for revocation request](#493-procedure-for-revocation-request) - [4.9.4 Revocation request grace period](#494-revocation-request-grace-period) - [4.9.5 Time within which CA must process the revocation request](#495-time-within-which-ca-must-process-the-revocation-request) - [4.9.6 Revocation checking requirement for relying parties](#496-revocation-checking-requirement-for-relying-parties) - [4.9.7 CRL issuance frequency (if applicable)](#497-crl-issuance-frequency-if-applicable) - [4.9.8 Maximum latency for CRLs (if applicable)](#498-maximum-latency-for-crls-if-applicable) - [4.9.9 On-line revocation/status checking availability](#499-on-line-revocationstatus-checking-availability) - [4.9.10 On-line revocation checking requirements](#4910-on-line-revocation-checking-requirements) - [4.9.11 Other forms of revocation advertisements available](#4911-other-forms-of-revocation-advertisements-available) - [4.9.12 Special requirements re key compromise](#4912-special-requirements-re-key-compromise) - [4.9.13 Circumstances for suspension](#4913-circumstances-for-suspension) - [4.9.14 Who can request suspension](#4914-who-can-request-suspension) - [4.9.15 Procedure for suspension request](#4915-procedure-for-suspension-request) - [4.9.16 Limits on suspension period](#4916-limits-on-suspension-period) - [4.10 Certificate status services](#410-certificate-status-services) - [4.10.1 Operational characteristics](#4101-operational-characteristics) - [4.10.2 Service availability](#4102-service-availability) - [4.10.3 Optional features](#4103-optional-features) - [4.11 End of subscription](#411-end-of-subscription) - [4.12 Key escrow and recovery](#412-key-escrow-and-recovery) - [4.12.1 Key escrow and recovery policy and practices](#4121-key-escrow-and-recovery-policy-and-practices) - [4.12.2 Session key encapsulation and recovery policy and practices](#4122-session-key-encapsulation-and-recovery-policy-and-practices) - [5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS](#5-facility-management-and-operational-controls) - [5.1 Physical controls](#51-physical-controls) - [5.1.1 Site location and construction](#511-site-location-and-construction) - [5.1.2 Physical access](#512-physical-access) - [5.1.3 Power and air conditioning](#513-power-and-air-conditioning) - [5.1.4 Water exposures](#514-water-exposures) - [5.1.5 Fire prevention and protection](#515-fire-prevention-and-protection) - [5.1.6 Media storage](#516-media-storage) - [5.1.7 Waste disposal](#517-waste-disposal) - [5.1.8 Off-site backup](#518-off-site-backup) - [5.1.9 Anti-earthquake measures](#519-anti-earthquake-measures) - [5.2 Procedural controls](#52-procedural-controls) - [5.2.1 Trusted roles](#521-trusted-roles) - [5.2.1.1 Certification Authority Supervisor](#5211-certification-authority-supervisor) - [5.2.1.2 Issuing Authority Manager](#5212-issuing-authority-manager) - [5.2.1.3 Issuing Authority System Administrator](#5213-issuing-authority-system-administrator) - [5.2.1.4 Issuing Authority Operator](#5214-issuing-authority-operator) - [5.2.1.5 Registration Authority Manager](#5215-registration-authority-manager) - [5.2.1.6 Registration Authority Operator Manager](#5216-registration-authority-operator-manager) - [5.2.1.7 Registration Authority Operator](#5217-registration-authority-operator) - [5.2.2 Number of persons required per task](#522-number-of-persons-required-per-task) - [5.2.3 Identification and authentication for each role](#523-identification-and-authentication-for-each-role) - [5.2.4 Roles requiring separation of duties](#524-roles-requiring-separation-of-duties) - [5.3 Personnel controls](#53-personnel-controls) - [5.3.1 Qualifications, experience, and clearance requirements](#531-qualifications-experience-and-clearance-requirements) - [5.3.2 Background check procedures](#532-background-check-procedures) - [5.3.3 Training requirements](#533-training-requirements) - [5.3.4 Retraining frequency and requirements](#534-retraining-frequency-and-requirements) - [5.3.5 Job rotation frequency and sequence](#535-job-rotation-frequency-and-sequence) - [5.3.6 Sanctions for unauthorized actions](#536-sanctions-for-unauthorized-actions) - [5.3.7 Independent contractor requirements](#537-independent-contractor-requirements) - [5.3.8 Documentation supplied to personnel](#538-documentation-supplied-to-personnel) - [5.4 Audit logging procedures](#54-audit-logging-procedures) - [5.4.1 Types of events recorded](#541-types-of-events-recorded) - [5.4.1.1 Router and firewall activities logs](#5411-router-and-firewall-activities-logs) - [5.4.2 Frequency of processing log](#542-frequency-of-processing-log) - [5.4.3 Retention period for audit log](#543-retention-period-for-audit-log) - [5.4.4 Protection of audit log](#544-protection-of-audit-log) - [5.4.5 Audit log backup procedures](#545-audit-log-backup-procedures) - [5.4.6 Audit collection system (internal vs. external)](#546-audit-collection-system-internal-vs-external) - [5.4.7 Notification to event-causing subject](#547-notification-to-event-causing-subject) - [5.4.8 Vulnerability assessments](#548-vulnerability-assessments) - [5.5 Records archival](#55-records-archival) - [5.5.1 Types of records archived](#551-types-of-records-archived) - [5.5.2 Retention period for archive](#552-retention-period-for-archive) - [5.5.3 Protection of archive](#553-protection-of-archive) - [5.5.4 Archive backup procedures](#554-archive-backup-procedures) - [5.5.5 Requirements for time-stamping of records](#555-requirements-for-time-stamping-of-records) - [5.5.6 Archive collection system (internal or external)](#556-archive-collection-system-internal-or-external) - [5.5.7 Procedures to obtain and verify archive information](#557-procedures-to-obtain-and-verify-archive-information) - [5.6 Key changeover](#56-key-changeover) - [5.7 Compromise and disaster recovery](#57-compromise-and-disaster-recovery) - [5.7.1 Incident and compromise handling procedures](#571-incident-and-compromise-handling-procedures) - [5.7.1.1 Incident Response and Disaster Recovery Plans](#5711-incident-response-and-disaster-recovery-plans) - [5.7.1.2 Mass Revocation Plans](#5712-mass-revocation-plans) - [5.7.2 Computing resources, software, and/or data are corrupted](#572-computing-resources-software-andor-data-are-corrupted) - [5.7.3 Entity private key compromise procedures](#573-entity-private-key-compromise-procedures) - [5.7.4 Business continuity capabilities after a disaster](#574-business-continuity-capabilities-after-a-disaster) - [5.8 CA or RA termination](#58-ca-or-ra-termination) - [6. TECHNICAL SECURITY CONTROLS](#6-technical-security-controls) - [6.1 Key pair generation and installation](#61-key-pair-generation-and-installation) - [6.1.1 Key pair generation](#611-key-pair-generation) - [6.1.2 Private key delivery to subscriber](#612-private-key-delivery-to-subscriber) - [6.1.3 Public key delivery to certificate issuer](#613-public-key-delivery-to-certificate-issuer) - [6.1.4 CA public key delivery to relying parties](#614-ca-public-key-delivery-to-relying-parties) - [6.1.5 Key sizes](#615-key-sizes) - [6.1.6 Public key parameters generation and quality checking](#616-public-key-parameters-generation-and-quality-checking) - [6.1.7 Key usage purposes (as per X.509 v3 key usage field)](#617-key-usage-purposes-as-per-x509-v3-key-usage-field) - [6.2 Private Key Protection and Cryptographic Module Engineering Controls](#62-private-key-protection-and-cryptographic-module-engineering-controls) - [6.2.1 Cryptographic module standards and controls](#621-cryptographic-module-standards-and-controls) - [6.2.2 Private key (n out of m) multi-person control](#622-private-key-n-out-of-m-multi-person-control) - [6.2.3 Private key escrow](#623-private-key-escrow) - [6.2.4 Private key backup](#624-private-key-backup) - [6.2.5 Private key archival](#625-private-key-archival) - [6.2.6 Private key transfer into or from a cryptographic module](#626-private-key-transfer-into-or-from-a-cryptographic-module) - [6.2.7 Private key storage on cryptographic module](#627-private-key-storage-on-cryptographic-module) - [6.2.8 Method of activating private key](#628-method-of-activating-private-key) - [6.2.9 Method of deactivating private key](#629-method-of-deactivating-private-key) - [6.2.10 Method of destroying private key](#6210-method-of-destroying-private-key) - [6.2.11 Cryptographic Module Rating](#6211-cryptographic-module-rating) - [6.3 Other aspects of key pair management](#63-other-aspects-of-key-pair-management) - [6.3.1 Public key archival](#631-public-key-archival) - [6.3.2 Certificate operational periods and key pair usage periods](#632-certificate-operational-periods-and-key-pair-usage-periods) - [6.4 Activation data](#64-activation-data) - [6.4.1 Activation data generation and installation](#641-activation-data-generation-and-installation) - [6.4.2 Activation data protection](#642-activation-data-protection) - [6.4.3 Other aspects of activation data](#643-other-aspects-of-activation-data) - [6.5 Computer security controls](#65-computer-security-controls) - [6.5.1 Specific computer security technical requirements](#651-specific-computer-security-technical-requirements) - [6.5.2 Computer security rating](#652-computer-security-rating) - [6.6 Life cycle technical controls](#66-life-cycle-technical-controls) - [6.6.1 System development controls](#661-system-development-controls) - [6.6.2 Security management controls](#662-security-management-controls) - [6.6.3 Life cycle security controls](#663-life-cycle-security-controls) - [6.7 Network security controls](#67-network-security-controls) - [6.8 Time-stamping](#68-time-stamping) - [7. CERTIFICATE, CRL, AND OCSP PROFILES](#7-certificate-crl-and-ocsp-profiles) - [7.1 Certificate profile](#71-certificate-profile) - [7.1.1 Version number(s)](#711-version-numbers) - [7.1.2 Certificate extensions](#712-certificate-extensions) - [7.1.3 Algorithm object identifiers](#713-algorithm-object-identifiers) - [7.1.3.1 SubjectPublicKeyInfo](#7131-subjectpublickeyinfo) - [7.1.3.2 signatureAlgorithm](#7132-signaturealgorithm) - [7.1.4 Name forms](#714-name-forms) - [7.1.5 Name constraints](#715-name-constraints) - [7.1.6 Certificate policy object identifier](#716-certificate-policy-object-identifier) - [7.1.7 Usage of Policy Constraints extension](#717-usage-of-policy-constraints-extension) - [7.1.8 Policy qualifiers syntax and semantics](#718-policy-qualifiers-syntax-and-semantics) - [7.1.9 Processing semantics for the critical Certificate Policies extension](#719-processing-semantics-for-the-critical-certificate-policies-extension) - [7.2 CRL profile](#72-crl-profile) - [7.2.1 Version number(s)](#721-version-numbers) - [7.2.2 CRL and CRL entry extensions](#722-crl-and-crl-entry-extensions) - [7.3 OCSP profile](#73-ocsp-profile) - [7.3.1 Version number(s)](#731-version-numbers) - [7.3.2 OCSP extensions](#732-ocsp-extensions) - [8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS](#8-compliance-audit-and-other-assessments) - [8.1 Frequency or circumstances of assessment](#81-frequency-or-circumstances-of-assessment) - [8.2 Identity/qualifications of assessor](#82-identityqualifications-of-assessor) - [8.3 Assessor's relationship to assessed entity](#83-assessors-relationship-to-assessed-entity) - [8.4 Topics covered by assessment](#84-topics-covered-by-assessment) - [8.5 Actions taken as a result of deficiency](#85-actions-taken-as-a-result-of-deficiency) - [8.6 Communication of results](#86-communication-of-results) - [8.7 Self audit](#87-self-audit) - [9. OTHER BUSINESS AND LEGAL MATTERS](#9-other-business-and-legal-matters) - [9.1 Fees](#91-fees) - [9.1.1 Certificate issuance or renewal fees](#911-certificate-issuance-or-renewal-fees) - [9.1.2 Certificate access fees](#912-certificate-access-fees) - [9.1.3 Revocation or status information access fees](#913-revocation-or-status-information-access-fees) - [9.1.4 Fees for other services](#914-fees-for-other-services) - [9.1.5 Refund policy](#915-refund-policy) - [9.2 Financial responsibility](#92-financial-responsibility) - [9.2.1 Insurance coverage](#921-insurance-coverage) - [9.2.2 Other assets](#922-other-assets) - [9.2.3 Insurance or warranty coverage for end-entities](#923-insurance-or-warranty-coverage-for-end-entities) - [9.3 Confidentiality of business information](#93-confidentiality-of-business-information) - [9.3.1 Scope of confidential information](#931-scope-of-confidential-information) - [9.3.2 Information not within the scope of confidential information](#932-information-not-within-the-scope-of-confidential-information) - [9.3.3 Responsibility to protect confidential information](#933-responsibility-to-protect-confidential-information) - [9.4 Privacy of personal information](#94-privacy-of-personal-information) - [9.4.1 Privacy plan](#941-privacy-plan) - [9.4.2 Information treated as private](#942-information-treated-as-private) - [9.4.3 Information not deemed private](#943-information-not-deemed-private) - [9.4.4 Responsibility to protect private information](#944-responsibility-to-protect-private-information) - [9.4.5 Notice and consent to use private information](#945-notice-and-consent-to-use-private-information) - [9.4.6 Disclosure pursuant to judicial or administrative process](#946-disclosure-pursuant-to-judicial-or-administrative-process) - [9.4.7 Other information disclosure circumstances](#947-other-information-disclosure-circumstances) - [9.5 Intellectual property rights](#95-intellectual-property-rights) - [9.6 Representations and warranties](#96-representations-and-warranties) - [9.6.1 CA representations and warranties](#961-ca-representations-and-warranties) - [9.6.2 RA representations and warranties](#962-ra-representations-and-warranties) - [9.6.3 Subscriber representations and warranties](#963-subscriber-representations-and-warranties) - [9.6.4 Relying party representations and warranties](#964-relying-party-representations-and-warranties) - [9.6.5 Representations and warranties of other participants](#965-representations-and-warranties-of-other-participants) - [9.7 Disclaimers of warranties](#97-disclaimers-of-warranties) - [9.8 Limitations of liability](#98-limitations-of-liability) - [9.9 Indemnities](#99-indemnities) - [9.9.1 Indemnification by Subscribers and Relying Parties](#991-indemnification-by-subscribers-and-relying-parties) - [9.9.2 Indemnification by Cybertrust](#992-indemnification-by-cybertrust) - [9.10 Term and termination](#910-term-and-termination) - [9.10.1 Term](#9101-term) - [9.10.2 Termination](#9102-termination) - [9.10.3 Effect of termination and survival](#9103-effect-of-termination-and-survival) - [9.11 Individual notices and communications with participants](#911-individual-notices-and-communications-with-participants) - [9.12 Amendments](#912-amendments) - [9.12.1 Procedure for amendment](#9121-procedure-for-amendment) - [9.12.2 Notification mechanism and period](#9122-notification-mechanism-and-period) - [9.12.3 Circumstances under which OID must be changed](#9123-circumstances-under-which-oid-must-be-changed) - [9.13 Dispute resolution provisions](#913-dispute-resolution-provisions) - [9.14 Governing law](#914-governing-law) - [9.15 Compliance with applicable law](#915-compliance-with-applicable-law) - [9.16 Miscellaneous provisions](#916-miscellaneous-provisions) - [9.16.1 Entire agreement](#9161-entire-agreement) - [9.16.2 Assignment](#9162-assignment) - [9.16.3 Severability](#9163-severability) - [9.16.4 Enforcement (attorneys’ fees and waiver of rights)](#9164-enforcement-attorneys-fees-and-waiver-of-rights) - [9.16.5 Force Majeure](#9165-force-majeure) - [9.17 Other provisions](#917-other-provisions) - [Appendix A: List of Definitions](#appendix-a-list-of-definitions) - [Appendix B: Profile of Certificate](#appendix-b-profile-of-certificate) ------------------ # 1. INTRODUCTION ## 1.1 Overview Cybertrust Japan Co., Ltd. ("Cybertrust") issues publicly trusted “iTrust EV SSL/TLS Server Certificates”, which is an Extended Validation Certificate("EV Certificate") used for the authentication of servers and network devices in SSL/TLS communications, and “iTrust SSL/TLS Server Certificate”, which is an Organizational Validation Certificate("OV Certificate") used for the authentication of servers and network devices in SSL/TLS communications to its subscribers. (hereinafter, unless otherwise stipulated herein, the “EV Certificate” and the “OV Certificate” are collectively referred to as the “certificates.”) Certificates are issued by the following certification authorities operated by Cybertrust("Certification Authority") and the table below details each certification authority. Certification Authority has been certified by the Root CA operated by SECOM Trust Systems CO.,LTD. (“SECOM Trust Systems”). | Name of Certification Authority | Cybertrust Japan SureServer EV CA G3 | |:---|:---| | Serial Number of Certification Authority Certificate | 22b9b1a12d91f181ad7a7b6dbeb38ea7 | | Validity Period of Certification Authority Certificate | December 13, 2023 to May 29, 2029 | | Signature System | SHA2 with RSA | | Key Size of Certification Authority | 2048 bit | | Fingerprint (SHA1) | 8c16167a04ba4992918eb6c4444147c0ff842d93 | | Fingerprint (SHA256) | b723273a3506c6bed85f083da562734be09f2c47ade47317831d63aa8be278a5 | | Certificates to be Issued | EV Certificate (iTrust EV SSL/TLS Server Certificate) | | Root CA | Security Communication RootCA2 | | Name of Certification Authority | Cybertrust Japan SureServer EV CA G3 | |:---|:---| | Serial Number of Certification Authority Certificate | 22b9b16488bce695fc | | Validity Period of Certification Authority Certificate | September 27, 2019 to May 29, 2029 | | Signature System | SHA2 with RSA | | Key Size of Certification Authority | 2048 bit | | Fingerprint (SHA1) | a88503f53fa02d0b2c4d1437bcd1bd6aa111539d | | Fingerprint (SHA256) | fece9ada7aa49d4fea9eff123542095a880c004fd6933f9364b02b2e3574ea38 | | Certificates to be Issued | EV Certificate (iTrust EV SSL/TLS Server Certificate) | | Root CA | Security Communication RootCA2 | | Name of Certification Authority | Cybertrust Japan SureServer CA G4 | |:---|:---| | Serial Number of Certification Authority Certificate | 22b9b1a074641857f7a01332db42b9ec | | Validity Period of Certification Authority Certificate | December 13, 2023 to May 29, 2029 | | Signature System | SHA2 with RSA | | Key Size of Certification Authority | 2048 bit | | Fingerprint (SHA1) | 0eb4300ea577104a84b0b86dc450147d97f975a9 | | Fingerprint (SHA256) | 8346922cb8730bb6ae71ab03bfc42462f4160423d9079be64385621ac5877672 | | Certificates to be Issued | OV Certificate (iTrust SSL/TLS Server Certificate) | | Root CA | Security Communication RootCA2 | | Name of Certification Authority | Cybertrust Japan SureServer CA G4 | |:---|:---| | Serial Number of Certification Authority Certificate | 22b9b1630cecb43c2e | | Validity Period of Certification Authority Certificate | September 27, 2019 to May 29, 2029 | | Signature System | SHA2 with RSA | | Key Size of Certification Authority | 2048 bit | | Fingerprint (SHA1) | f695c5b4037ae8eae51ea943a4f54d750e0da609 | | Fingerprint (SHA256) | 0207056d172c80bdfb6dc45be9e5808846078d1e6eef1b6ed70259ab332a64c1 | | Certificates to be Issued | OV Certificate (iTrust SSL/TLS Server Certificate) | | Root CA | Security Communication RootCA2 | Cybertrust is compliant with the following requirements, laws, and ordinances in order to operate the Certification Authority. 1. Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates provided by CA/Browser Forum (“BR”) 2. Guidelines For The Issuance And Management Of Extended Validation Certificates provided by CA/Browser Forum (“EV Guidelines”) 3. Network and Certificate System Security Requirements 4. Cybertrust Japan iTrust SSL/TLS Server Certificate Policy/Certification Practice Statement (This document and hereafter called “this CP/CPS.”) 5. A contract with the root CA, SECOM Trust Systems 6. The latest requirements imposed on certificate authorities by the Application Software Suppliers in which the root CA certificate is included - Program Requirements - Microsoft Trusted Root Program - Mozilla Root Store Policy - Apple Root Certificate Program - Chrome Root Program Policy - CCADB Policy 7. Laws of Japan that are applicable to the operations to be performed by the Certification Authority established in Japan. The Certification Authority complies with the latest versions of the requirements listed above published by CA/Browser Forum at https://www.cabforum.org and by the Application Software Supplier in which the certificate of the root certificate authority is registered. If there is any discrepancy between this CP/CPS and the Guidelines, the Guidelines shall prevail. This CP/CPS prescribes the requirements for operating the Certification Authority as well as the various requirements thereto issuing certificates. The requirements include obligations of the Certification Authority, obligations of subscribers, and obligations of relying parties. This CP/CPS will be published in both English and Japanese, but if there is any discrepancy between the English and Japanese versions of the same version, the English version will take precedence. Upon specifying the various requirements in this CP/CPS, Cybertrust shall adopt the RFC 3647 "Certificate Policy and Certification Practices Framework" set forth by the IETF PKIX Working Group. RFC 3647 is an international guideline that sets forth the framework for the CP or CPS. In each provision of this CP/CPS, which is established based on the framework of RFC3647, matters that the Certification Authority does not perform are described as "Not applicable." and no requirements related to that section are described as "No Stipulation." ## 1.2 Document name and identification The formal name of this CP/CPS shall be the Cybertrust Japan iTrust SSL/TLS Server Certificate Policy/Certification Practice Statement. A specific object ID (OID) is assigned to this CP/CPS. | Document Name | OID | |:--:|:--:| | Cybertrust Japan iTrust SSL/TLS Server Certificate Policy/Certification Practice Statement | 1.2.392.00200081.1.27.1 | ## 1.3 PKI participants Cybertrust Japan Policy Authority (“CTJ PA”) determines policies, such as this CP/CPS and appoints Certification Authority Supervisors. The following describes the parties related to the certificates issued by the Certification Authority. Each party shall observe the obligations set forth in this CP/CPS. ### 1.3.1 Certification authorities The Certification Authority set forth in the “1.1 Overview" of this CP/CPS. The Certification Authority consists of a Registration Authority and an Issuing Authority. The Certification Authority is managed by the Certification Authority Supervisor set forth in the "5.2.1 Trusted roles" of this CP/CPS. #### 1.3.1.1 Issuing Authorities The Issuing Authority is operated by Cybertrust and issues or revokes certificates of subscribers based on instructions from the Registration Authority. It also controls the private key of the Certification Authority based on this CP/CPS. ### 1.3.2 Registration authorities The Registration Authority is operated by Cybertrust , accepts applications for certificates from subscribers, and screens the applications based on this CP/CPS. Based on the screening results, the Registration Authority instructs the Issuing Authority to issue, revoke the certificates of subscribers, or dismiss the applications. The Certification Authority does not delegate any RA operations including domain control validation to any of third parties. ### 1.3.3 Subscribers A subscriber is an organization or sole proprietor that applies for a certificate with the Certification Authority based on this CP/CPS and uses the certificate based on this CP/CPS, and the subscriber agreement. A person who is responsible for applying for a subscriber's certificate is referred to as an “application supervisor” (For the EV Certificate, an application supervisor is authorized as roles for both of "Certificate Approver" and "Contract Signer" defined in EV Guidelines.). A subscriber must appoint an application supervisor among persons affiliated with the subscriber. Persons affiliated with the subscriber who may apply for a certificate with the Certification Authority shall be limited to the application supervisor, or a person in charge of application who is authorized by the application supervisor to submit an application (For the EV Certificate, a person in charge of application corresponds to the roles of "Certificate requester" defined in EV Guidelines.). The person in charge of application may be appointed among persons inside or outside the subscriber. When the person in charge of application is to be appointed from the outside, the person in charge of application may be an individual or an organization. The person in charge of application appointed among persons outside the subscriber may be defined as the "Applicant's Agent" in the Subscriber Agreement, etc. When the Certification Authority applies for and use the certificate for its own use, the Certification Authority also acts as a subscriber. ### 1.3.4 Relying parties A relying party is an organization or an individual that verifies the validity of the certificates of the Certification Authority and subscribers and relies on the certificates of the Certification Authority and subscribers based on their own judgment. ### 1.3.5 Other participants Other parties include the Root Certificate Authority that issue the Certificate Authority Certificates, application software suppliers, and auditors. ## 1.4 Certificate usage ### 1.4.1 Appropriate certificate uses The certificates stipulated in this CP/CPS are the certificates for SSL/TLS communications. The certificate indicates that the subscriber is an existing organization and that the Certification Authority certifies that the subscriber has the right to use the Fully-Qualified Domain Name ("FQDN"). It also achieves SSL/TLS encrypted communications between the server device to which the FQDN is assigned and the client devices of the relying parties. Upon issuing a certificate, the Registration Authority shall screen the following matters based on this CP/CPS: 1. In the case of the EV Certificate - legal and physical existence of subscribers; - existence of the subscriber's business (provided, however, that this shall be implemented when 3 years have not elapsed from the establishment of the subscriber, and its physical existence cannot be verified in the screening); - a subscriber has the right to use the FQDN included in the certificate; - name, title and authority of an application supervisor; - acceptance of the Subscriber Agreement; - approval of the application supervisor for the person in charge of application to submit an application; and - high-risk status. (Specifying an application with higher possibility for phishing or other abuses or an article under an embargo and appropriate additional screening shall be processed.) 2. In the case of the OV Certificate - legal or physical existence of subscribers; - a subscriber has the right to use the FQDN included in the certificate; - authority of the application supervisor - acceptance of the Subscriber Agreement; - approval of the application supervisor for the person in charge of application to submit an application; and - high-risk status. (specifying an application with higher possibility for phishing and appropriate additional screening shall be processed.) ### 1.4.2 Prohibited certificate uses The use of certificates for any purpose other than as set forth in "1.4.1 Appropriate certificate uses" of this CP/CPS is prohibited. ## 1.5 Policy administration ### 1.5.1 Organization administering the document This CP/CPS and the subscriber agreement are administered by Cybertrust, which operates the Certification Authority. ### 1.5.2 Contact person Cybertrust accepts inquiries related to the services provided by it and this CP/CPS at the following contact.
Contact Information

General contact in Cybertrust Japan Co., Ltd.

Address: 13F SE Sapporo Bldg., 1-1-2 Kita 7-jo Nishi, Kita-ku, Sapporo-shi 060-0807

Tel: 0120-957-975 or +81-11-708-5283

Business Days: Monday to Friday (excluding National Holidays, and the designated days addressed on Cybertrust’s website including Year-End and New Year)

Business Hours: 9:00 to 18:00

Inquiries and complaints: As indicated below

Description Address
  • Inquiries regarding the application process for issuance and technical inquiries

  • Other inquiries regarding this CP/CPS, etc.

  • Capable of response from 9:00 to 18:00 on business days.

OV Certificate:

ss-apply@cybertrust.ne.jp

EV Certificate:

evc-apply@cybertrust.ne.jp

  • Inquiries regarding revocation requests and application process

  • Inquiries regarding problems with certificates or upon discovery of fraudulent certificates

  • Communication of other complaints

  • Capable of response for 24 x7.

evc-report@cybertrust.ne.jp
### 1.5.3 Person determining CP/CPS suitability for the policy Certificates of the Certification Authority are issued by the Root CA operated by SECOM Trust Systems. This CP/CPS must suit the requirements by the Root CA, and the suitability is evaluated by CTJ PA and SECOM Trust Systems. ### 1.5.4 CP/CPS approval procedures The suitability described in "1.5.3 Person determining CP/CPS suitability for the policy" of this CP/CPS shall go through an external audit, and then be approved by CTJ PA and SECOM Trust Systems. ## 1.6 Definitions and acronyms As prescribed in Appendix A of this CP/CPS. ------------------------------------------------- # 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES ## 2.1 Repositories Repositories of the Certification Authority are controlled by Cybertrust. ## 2.2 Publication of certification information Cybertrust publishes the following information in repositories which are available 24 hours a day, 365 days a year. 1. Publish the following information at https://www.cybertrust.ne.jp/ssl/repository/index.html. - this CP/CPS - subscriber agreement for the certificate - other terms and conditions regarding the services of the Certification Authority (the "Related Rules") 2. Publish CRL information issued by the Certification Authority as follows. | Name of Certification Authority | URL | |:---|:---| | Cybertrust Japan SureServer EV CA G3 | http://crl.cybertrust.ne.jp/SureServer/evcag3/cdp.crl | | Cybertrust Japan SureServer CA G4 | http://crl.cybertrust.ne.jp/SureServer/ovcag4/cdp.crl | 3. Publish Certificates issued by the Certification Authority as follows. | Name of Certification Authority | URL | |:---|:---| | Cybertrust Japan SureServer EV CA G3 | http://crl.cybertrust.ne.jp/SureServer/evcag3/evcag3.crt | | Cybertrust Japan SureServer CA G4 | http://crl.cybertrust.ne.jp/SureServer/ovcag4/ovcag4.crt | ## 2.3 Time or frequency of publication The timing and frequency of publication regarding the information to be published by Cybertrust shall be as follows. This does not apply where repository maintenance or the like is required. 1. This CP/CPS, the subscriber agreement for the certificate, and other terms and conditions shall be published each time they are amended. 2. The CRL shall be renewed based on the cycle prescribed in "4.9.7 CRL issuance frequency (if applicable)" of this CP/CPS for the certificate and then published. 3. The certificates of the Certification Authority shall be published at least during the effective period. ## 2.4 Access controls on repositories Cybertrust shall publish the repository in a read-only manner. --------------------------------------- # 3. IDENTIFICATION AND AUTHENTICATION ## 3.1 Naming ### 3.1.1 Types of names Certificate Distinguished Names and Subject Alternative Names comply with the requirements addressed in section "1.1 Overview" of this CP/CPS. Subscribers are identified based on the X.500 Distinguished Name ("DN") in the certificate. ### 3.1.2 Need for names to be meaningful The name included in the DN of the certificate shall have the meaning of the subsequent paragraph. EV Certificate (iTrust EV SSL/TLS Server Certificate) | DN Item | Meaning | |:-----------------------------------|:-----------------------------------| | Common Name | Complete host name of server or network device to use the certificate (FQDN). | | Organization | Name of the organization of the subscriber. | | Locality | Address of business location (locality). | | State or Province | Address of business location (state or province). | | Country | Address of business location (country). | | Business Category | Information for identifying form of organization set forth in the EV Guidelines.
Private
Organization
Government Entity
(The Certification Authority does not issue a certificate to Business Entity or Non-Commercial Entity.) | | Serial Number | For private organizations, indicate the corporate registration number.
For government entities, indicate "The Subject is Government Entity" | | Jurisdiction of Incorporation State or Province | Jurisdiction of Incorporation State or Province. | | Jurisdiction of Incorporation Locality | Jurisdiction of Incorporation Locality. | | Jurisdiction of Incorporation Country | Jurisdiction of Incorporation Country. | OV Certificate (iTrust SSL/TLS Server Certificate) | DN Item | Meaning | |:---|:---| | Common Name | Complete host name of server or network device to use the certificate (FQDN or IP address). | | Organization | Name of the organization or sole proprietor of the subscriber. | | Locality | Address of business location or sole proprietor (locality). | | State or Province | Address of business location or sole proprietor (state or province). | | Country | Address of business location or sole proprietor (country). | ### 3.1.3 Anonymity or pseudonymity of subscribers This Certification Authority does not accept any certificate request by anonymity or pseudonymity of a subscriber. ### 3.1.4 Rules for interpreting various name forms Rules for interpreting the DN form of certificates issued by the Certification Authority shall be pursuant to X.500. ### 3.1.5 Uniqueness of names The certificates issued by the Certification Authority can uniquely identify a subscriber based on the DN. ### 3.1.6 Recognition, authentication, and role of trademarks The Certification Authority does not authenticate the copyrights, trade secrets, trademark rights, utility model rights, patent rights and other intellectual property rights (including, but not limited to, rights for obtaining patents and other intellectual properties; simply "Intellectual Property Rights") upon issuing a Subscriber’s certificate. ## 3.2 Initial identity validation The Certification Authority shall verify the information of applicant’s establishment/registration jurisdiction contained in subject:jurisdictionLocalityName (OID: 1.3.6.1.4.1.311.60.2.1.1), subject:jurisdictionStateOrProvinceName (OID: 1.3.6.1.4.1.311.60.2.1.2), and subject:jurisdictionCountryName (OID: 1.3.6.1.4.1.311.60.2.1.3) with the data published by the relevant corporation establishment/registration agency before the certificate issuance. If the applicant is a private organization, the registration number to be included in Subject:serialNumber (OID: 2.5.4.5) which is assigned to the applicant organization by the corporation establishment/registration agency or the date of the corporation establishment/registration shall be confirmed with the data source published by the relevant corporation establishment/registration agency. If the applicant is a government entity, Subject:serialNumber (OID: 2.5.4.5) shall include the characters of “The Subject is Government Entity”. The list of corporate establishment/registration agency databases used by the Certification Authority to confirm the establishment of jurisdiction/registration jurisdiction will be published at https://www.cybertrust.ne.jp/ssl/repository/Jurisdiction.pdf. ### 3.2.1 Method to prove possession of private key A certificate issuance request ("CSR") which constitutes a part of the application information from a subscriber includes a digital signature encrypted with a public key and a private key corresponding to the public key. The Certification Authority verifies the digital signature by using the public key included in the CSR and thereby validates that the digital signature was signed using the Subscriber’s private key and determines that the subscriber is in possession of the private key. ### 3.2.2 Authentication of organization identity All DNS queries conducted in the course of satisfying the requirements of “3.2.2.4 Validation of Domain Authorization or Control”,”3.2.2.5 Authentication for an IP Address”, and “3.2.2.8 CAA Records” of this CP/CPS MUST be made from the Certification Authority to authoritative nameservers, i.e. without the use of recursive resolvers operated outside the Certification Authority's audit scope. #### 3.2.2.1 Identity The Certification Authority shall verify the matters set forth in "1.4.1 Appropriate certificate uses" of this CP/CPS. In the case of the EV Certificate, upon verifying the subscriber, the Certification Authority shall verify the applicant’s legal existence, identity, and physical existence based on Section 3.2.2.2, 3.2.2.4, and Appendix D-1: Japan of EV Guidelines. Additionally, the Certification Authority shall verify the applicant's operational existence based on Section 3.2.2.6 of the EV Guidelines. In the case of OV Certificate, upon verifying the subscriber, the Certification Authority shall use public documents and data, the documents and data provided by a third party that is deemed reliable by the Certification Authority, and the documents and data provided by the subscriber, as well as make inquiries to an appropriate individual affiliated with the subscriber or an organization that constitutes the subscriber. The subscriber shall be visited for screening as required. However, when there are documents or data that were received from the subscriber or documents or data that were independently obtained by the Certification Authority during the period that was posted on the website by Cybertrust or the period notified to the subscriber, and such documents or data have been screened by the Certification Authority and are valid, the Certification Authority shall not request the resubmission of such documents or data. Details regarding the verification procedures to be requested to subscribers shall be posted on Cybertrust's website or notified individually to the subscribers or the person in charge of application. The certification Authority does not issue a certificate to a natural person. #### 3.2.2.2 DBA/Tradename The Certification Authority does not allow DBA/Tradename to be included in the EV Certificate. When the organization name to be included in the OV Certificate is DBA/Tradename, this Certification Authority shall confirm the name by using public documents and data or the documents and data provided by a third party that is deemed reliable by the Certification Authority, based on Section 3.2.2.2 of the BR. #### 3.2.2.3 Verification of Country This Certification Authority confirms the Country included in the Subscriber’s certificate based on "3.2.2.1 Identity” of this CP/CPS. #### 3.2.2.4 Validation of Domain Authorization or Control This Certification Authority shall validate, prior to issuance, the Subscriber’s authorization or control of the FQDN or domain name in accordance with the applicable guidelines ( Section 3.2.2.7 of the EV Guidelines and/or Section 3.2.2.4 of the BR. On or after March 15, 2026, the Certification Authority MUST perform DNSSEC validation back to the IANA DNSSEC root trust anchor on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective in accordance with Section 3.2.2.4 of the BR, and MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control. DNSSEC validation back to the IANA DNSSEC root trust anchor MAY be performed on all DNS queries associated with the validation of domain authorization or control by Remote Network Perspectives used for Multi-Perspective Issuance Corroboration. The Certification Authority validates each Fully‐Qualified Domain Name (FQDN) listed in the Certificate using at least one of the methods listed below. This Certification Authority does not issue a certificate for a FQDN contains ".onion" as the rightmost label. This Certification Authority SHALL maintain a record of which domain validation method, including relevant BR version number, was used to validate every domain. In the case of the EV Certificate, in addition to the above, when a domain name that contains mixed characters and an existing high-risk domain name are compared visually and similarity is observed, the Certificate request is determined to be high-risk. To ensure that the subscriber is not a high-risk target organization, additional authentication and verification that are reasonably appropriate shall be conducted. Note: FQDNs may be listed in Certificates using dNSNames in the subjectAltName extension or in Subordinate Certification Authority Certificates via dNSNames in permitted Subtrees within the Name Constraints extension. ##### 3.2.2.4.1 Validating the Applicant as a Domain Contact This Certification Authority does not use this method. ##### 3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact This Certification Authority does not use this method. ##### 3.2.2.4.3 Phone Contact with Domain Contact This Certification Authority does not use this method. ##### 3.2.2.4.4 Constructed Email to Domain Contact The Certification Authority send emails to one or more email addresses of 'admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster' as the local part, followed by the at sign ("@") and the Authorization Domain Name. The emails contain a Random Value. The Subscriber’s authorization or control of the FQDN is examined by receiving a response containing the Random Value. If the Authorization Domain Name used in the email address is the Authorization Domain Name for multiple FQDNs, each email MAY confirm the authorization or control of the multiple FQDNs. The Random Value SHALL be unique in each email. The email MAY be re‐sent in its entirety, including the reuse of the Random Value, provided that the email’s entire contents and recipient SHALL remain unchanged. The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. Note: Once the FQDN has been validated using this method, the Certification Authority MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This rule also applies to the application for a wildcard domain name. ##### 3.2.2.4.5 Domain Authorization Document This Certification Authority does not use this method. ##### 3.2.2.4.6 Agreed‐Upon Change to Website This Certification Authority does not use this method. ##### 3.2.2.4.7 DNS Change This Certification Authority SHALL examine the Subscriber's authorization or control of the FQDN by confirming the presence of a Random Value or Request Token for either in a DNS CNAME, TXT or CAA record for either an Authorization Domain Name or an Authorization Domain Name that is prefixed with a label that begins with an underscore character. If a Random Value is used, this Certification Authority SHALL provide a Random Value unique to the Certificate request and SHALL not use the Random Value after 30 days or the time frame permitted for reuse of validated information relevant to the Certificate (such as in Section 4.2.1 of the BR or Section 3.2.2.14.3 of the EV Guidelines ) if the Subscriber submitted a Certificate request. The Certification Authority using this method MUST implement Multi-Perspective Issuance Corroboration in accordance with section 3.2.2.9 of the BR. To corroborate validation results as Multi-Perspective Issuance Corroboration, a remote Network Perspective MUST retrieve the same Random Value as the Primary Network Perspective. This certification authority does not adopt Request Token. Note: Once the FQDN has been validated using this method, the Certification Authority MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This rule also applies to an application for a wildcard domain name. ##### 3.2.2.4.8 IP Address This Certification Authority does not use this method. ##### 3.2.2.4.9 Test Certificate This Certification Authority does not use this method. ##### 3.2.2.4.10 TLS Using a Random Value This Certification Authority does not use this method. ##### 3.2.2.4.11 Any Other Method This Certification Authority does not use this method. ##### 3.2.2.4.12 Validating Applicant as a Domain Contact This Certification Authority does not use this method. ##### 3.2.2.4.13 Email to DNS CAA Contact This Certification Authority SHALL examine the Subscriber's authorization or control of the FQDN by sending a Random Value via email to the email address that can be verified as the DNS CAA Email Contact and then receiving a confirming response containing the Random Value. The relevant CAA Resource Record Set MUST be found using the search algorithm defined in RFC 8659. Each email MAY confirm control of multiple FQDNs, provided that each email address is a DNS CAA Email Contact for each Authorization Domain Name being validated. The same email MAY be sent to multiple recipients as long as all recipients are DNS CAA Email Contacts for each Authorization Domain Name being validated. The Random Value SHALL be unique in each email. The email MAY be re‐sent in its entirety, including the re‐use of the Random Value, provided that the email’s entire contents and recipient SHALL remain unchanged. The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The Certification Authority using this method MUST implement Multi-Perspective Issuance Corroboration in accordance with section 3.2.2.9 of the BR. To corroborate validation results as Multi-Perspective Issuance Corroboration, a remote Network Perspective MUST retrieve the selected email address contact used for domain validation observed by the Primary Network Perspective. Note: Once the FQDN has been validated using this method, the Certification Authority MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This rule also applies to an application for a wildcard domain name. ##### 3.2.2.4.14 Email to DNS TXT Contact This Certification Authority SHALL examine the Subscriber's authorization or control of the FQDN by sending a Random Value via email to the email address contact in the DNS TXT record (DNS TXT Record Email Contact) and then receiving a confirming response containing the Random Value. Each email MAY confirm control of multiple FQDNs, provided that each email address is a DNS TXT Record Email Contact for each Authorization Domain Name being validated. The same email MAY be sent to multiple recipients as long as all recipients are DNS TXT Record Email Contacts for each Authorization Domain Name being validated. The Random Value SHALL be unique in each email. The email MAY be re‐sent in its entirety, including the re‐use of the Random Value, provided that the email’s entire contents and recipient SHALL remain unchanged. The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The Certification Authority using this method MUST implement Multi-Perspective Issuance Corroboration in accordance with section 3.2.2.9 of the BR. To corroborate validation results as Multi-Perspective Issuance Corroboration, a remote Network Perspective MUST retrieve the selected email address contact used for domain validation observed by the Primary Network Perspective. Note: Once the FQDN has been validated using this method, the Certification Authority MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This rule also applies to an application for a wildcard domain name. ##### 3.2.2.4.15 Phone Contact with Domain Contact This Certification Authority does not use this method. ##### 3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact This Certification Authority SHALL examine the Subscriber's authorization or control of the FQDN by calling the contact’s phone number (DNS TXT Record Phone Contact) in the DNS TXT record. Each phone call MAY confirm control of multiple Authorization Domain Names provided that the same DNS TXT Record Phone Contact phone number is listed for each Authorization Domain Name being examined and they provide a confirming response for each Authorization Domain Name. The Certification Authority MUST NOT knowingly be transferred or request to be transferred as this phone number has been specifically listed for the purposes of Domain Validation. In the event of reaching voicemail, the Certification Authority may leave the Random Value and the Authorization Domain Name(s) being examined. The Random Value MUST be returned to the Certification Authority to approve the request. The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The Certification Authority using this method MUST implement Multi-Perspective Issuance Corroboration in accordance with section 3.2.2.9 of the BR. To corroborate validation results as Multi-Perspective Issuance Corroboration, a remote Network Perspective MUST retrieve the selected Contact’s phone number used for domain validation observed by the Primary Network Perspective. Note: Once the FQDN has been validated using this method, the Certification Authority MAY also issue the Subscriber’s Certificates for other FQDNs that end with all the labels of the validated FQDN. This rule also applies to an application for a wildcard domain name. ##### 3.2.2.4.17 Phone Contact with DNS CAA Phone Contact This Certification Authority SHALL examine the Subscriber’s authorization or control of the FQDN by calling a phone number verified as the DNS CAA Phone Contact. The relevant CAA Resource Record Set must be found by using the search algorithm defined in RFC 8659. Each phone call MAY confirm control of multiple Authorization Domain Names provided that the same DNS CAA Phone Contact phone number is listed for each ADN being verified and they provide a confirming response for each Authorization Domain Name. The Certification Authority MUST NOT knowingly be transferred or request to be transferred as this phone number has been specifically listed for the purposes of Domain Validation. In the event of reaching voicemail, the Certification Authority may leave the Random Value and the Authorization Domain Name(s) being examined. The Random Value MUST be returned to the Certification Authority to approve the request. The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The Certification Authority using this method MUST implement Multi-Perspective Issuance Corroboration in accordance with section 3.2.2.9 of the BR. To corroborate validation results as Multi-Perspective Issuance Corroboration, a remote Network Perspective MUST retrieve the selected Contact’s phone number used for domain validation observed by the Primary Network Perspective. Note: Once the FQDN has been validated using this method, the Certification Authority MAY also issue the Subscriber’s Certificates for other FQDNs that end with all the labels of the validated FQDN. This rule also applies to an application for a wildcard domain name. ##### 3.2.2.4.18 Agreed‐Upon Change to Website v2 Confirming the Applicant's control over the FQDN by verifying that the Request Token or Random Value is contained in the contents of a file. 1. The entire Request Token or Random Value MUST NOT appear in the request used to retrieve the file, and 2. This Certification Authority MUST receive a successful HTTP response from the request (meaning a 2xx HTTP status code must be received). The file containing the Request Token or Random Value: 1. MUST be located on the Authorization Domain Name, 2. MUST be located under the "/.well-known/pki-validation" directory, 3. MUST be retrieved via either the "http" or "https" scheme, and 4. MUST be accessed over an Authorized Port. If this Certification Authority follows redirects the following apply: 1. Redirects MUST be initiated at the HTTP protocol layer. Redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in RFC 7231, Section 6.4, or a 308 HTTP status code response, as defined in RFC 7538, Section 3. Redirects MUST be to the final value of the Location HTTP response header, as defined in RFC 7231, Section 7.1.2. 2. Redirects MUST be to resource URLs with either via the "http" or "https" scheme. 3. Redirects MUST be to resource URLs accessed via Authorized Ports. If a Random Value is used, then: 1. This Certification Authority MUST provide a Random Value unique to the certificate request. 2. The Random Value MUST remain valid for use in a confirming response for no more than 30 days from its creation. The Certification Authority using this method MUST implement Multi-Perspective Issuance Corroboration in accordance with section 3.2.2.9 of the BR. To corroborate validation results as Multi-Perspective Issuance Corroboration, a remote Network Perspective MUST retrieve the same Random Value as the Primary Network Perspective. This certification authority does not adopt Request Token. Note: When using this method, the Certification Authority shall validate each of requested FQDNs and shall not issue certificates for the different FQDNs that end with all the labels of the validated FQDNs unless the Certification Authority processes another validation. This rule does not apply to the validation of a wildcard domain name. ##### 3.2.2.4.19 Agreed‐Upon Change to Website - ACME This Certification Authority does not use this method. ##### 3.2.2.4.20 TLS Using ALPN This Certification Authority does not use this method. ##### 3.2.2.4.21 DNS Labeled with Account ID - ACME This Certification Authority does not use this method. #### 3.2.2.5 Authentication for an IP Address The Certification Authority does not issue EV Certificates that contain an IP address. Prior to issuing an OV Certificate, the Certification Authority shall confirm that it has validated each IP address to be listed in the OV Certificate by using at least one of the following methods, in accordance with Section 3.2.2.5 of the BR. Validation results regarding the Subscriber’s control of the IP address may be reused within the period specified in Section 4.2.1 "Performing identification and authentication functions" of this CP/CPS and Section 4.2.1 of the BR, and shall be valid for the issuance of multiple Certificates. The Certification Authority shall again verify the control of the IP address for the certificate request if the previous validation results are expired. In all cases, the validation must have been initiated within the time period specified in the relevant requirement (such as Section 4.2.1 of BR) prior to OV Certificate issuance. For purposes of IP address validation, the term Subscriber includes the Subscriber's Parent Company and Subsidiary Company. This Certification Authority SHALL maintain a record of which validation method, including relevant BR version number, was used to validate every IP address. Note: The IP address confirmed by Section 3.2.2.5 may be described in the certificate and the subordinate Certification Authority certificate via the IP address in the permitted subtree within the name restriction extension as stipulated in Section 7.1.2.7 of the BR. Describing it in the subordinate Certification Authority certificate need not be verified via the IP address in the excluded subtree of the name restriction extension. ##### 3.2.2.5.1 Agreed‐Upon Change to Website This Certification Authority confirms the IP address that is accessible in the metatag format under the "/.well-known/pki-validation" directory or in another path registered with IANA for the purpose of IP address validation via HTTP/HTTPS over an Authorized Port. It also screens the Subscriber's control of the IP address by confirming the presence of a Request Token or Random Value. The Request Token or Request Value MUST NOT appear in the request. If a Random Value is used, this Certification Authority SHALL provide a Random Value unique to the Certificate request and SHALL not use the Random Value after 30 days or the time frame permitted for reuse of validated information relevant to the Certificate (see Section 4.2.1 of the BR) if the Subscriber submitted a Certificate request. The Certification Authority using this method MUST implement Multi-Perspective Issuance Corroboration in accordance with section 3.2.2.9 of the BR. To corroborate validation results as Multi-Perspective Issuance Corroboration, a remote Network Perspective MUST retrieve the same Random Value as the Primary Network Perspective. This Certification Authority does not adopt Request Token. ##### 3.2.2.5.2 Email, Fax, SMS, or Postal Mail to IP Address Contact This Certification Authority does not use this method. ##### 3.2.2.5.3 Reverse Address Lookup This Certification Authority acquires the domain name associated with the IP address via reverse IP lookup of the IP address. It also screens the Subscriber’s control of the IP address by using the method allowed in “3.2.2.4 Validation of Domain Authorization or Control” of this CP/CPS to confirm that the subscriber controls the FQDN. The Certification Authority using this method MUST implement Multi-Perspective Issuance Corroboration in accordance with section 3.2.2.9 of the BR. To corroborate validation results as Multi-Perspective Issuance Corroboration, a remote Network Perspective MUST retrieve the same FQDN as the Primary Network Perspective. ##### 3.2.2.5.4 Any Other Method This Certification Authority does not use this method. ##### 3.2.2.5.5 Phone Contact with IP Address Contact This Certification Authority does not use this method. ##### 3.2.2.5.6 ACME “http-01” method for IP Addresses This Certification Authority does not use this method. ##### 3.2.2.5.7 ACME “tls-alpn-01” method for IP Addresses This Certification Authority does not use this method. #### 3.2.2.6 Wildcard Domain Validation The Certification Authority does not issue the EV Certificate that includes a Wildcard Domain Name. Before issuing a OV certificate that uses a wildcard character (\*) in dNSName of subjectAltName, this Certification Authority determines whether the wildcard character occurs at the position of the "registry control" label or the "public suffix" (such as "\* .com" and "\* .co.jp", see Section 8.2 of RFC 6454 for details). Determination of "registry control" shall be based on Section 3.2.2.6 of the BR. When a wildcard exists immediately to the left of the registry control or public suffix, this Certification Authority refuses issuance unless the appropriate control of the entire domain name space is confirmed. (e.g. the Certification Authority MUST NOT issue “\*.co.jp” or “\*.local”, but MAY issue “\*.example.com” to Example Co.). #### 3.2.2.7 Data Source Accuracy This Certification Authority evaluates the reliability of the data source used in examination in accordance with the BR for the OV Certificate or the EV Guidelines for the EV Certificate, as applicable. The evaluation checks the following items such as the accuracy and the resistance to change or falsification. 1. The age of the information provided, 2. The frequency of updates to the information source, 3. The provider and purpose of the collected data, 4. The public accessibility of the data availability, and 5. The relative difficulty in falsifying or altering the data. Databases maintained by the Certification Authority, its owner, or its affiliated companies must be independent of the Certification Authority. They do not qualify as a Reliable Data Source if the primary purpose of the database is to collect information with the intention of passing the examination of the Certification Authority. #### 3.2.2.8 CAA Records The Certification Authority retrieves and processes the CAA Record for each dNSName in the subjectAltName extension, based on RFC8659 (DNS Certification Authority Authorization (CAA) Resource Record) and section 3.2.2.8 of the BR. The Certification Authority MUST retrieve CAA records using Remote Network Perspectives before Certificate issuance based on Section 3.2.2.9 of the BR. To corroborate the Primary Network Perspective, the remote Network Perspective's CAA check response MUST be treated as permission to issue, regardless of whether the responses are byte-for-byte identical. Additionally, the Certification Authority MAY consider the response from a remote Network Perspective as corroborating if one or both of the Perspectives experience a CAA record lookup failure, and the failure is acceptable as defined in this section. When processing CAA records, the Certification Authority processes the issue, issuewild, and iodef property tags as specified in RFC 8659. The Certification Authority does not issue a certificate if they encounter an unrecognized property tag with this critical flag set. For certificates issuance, the Certification Authority verifies the CAA Record within the TTL of the CAA record, or 8 hours, whichever is greater. However, if CAA is checked at time of Precertificate issuance and is logged in at least two public logs, CAA checking is omitted for certificates. The Certification Authority is permitted to treat a CAA record lookup failure as permission to issue if: 1. the cause of the failure is outside the Certification Authority's infrastructure; and 2. the lookup has been retried at least once; and 3. confirmed that the domain is “Insecure” as defined in RFC 4035 Section 4.3. The Certification Authority documents certificate issuance that were prevented by a CAA record in sufficient detail to provide feedback to the CA/Browser Forum, and if a CAA iodef record contains a contact ( mailto: or https: ), the Certification Authority SHOULD send a report regarding the issuance request to that contact. If the CAA record (issue/issuewild) contains any of the values listed in section 4.2.1 of this CP/CPS, the Certification Authority recognizes that it is designated as a certification authority that permits issuance of the certificates. On or after March 15, 2026, the Certification Authority MUST perform DNSSEC validation back to the IANA DNSSEC root trust anchor on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective in accordance with Section 3.2.2.8.1 of the BR, and MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with CAA record lookups. Additionally, the Certification Authority MUST NOT treat the issuance as permitted if the Primary Network Perspective observes DNSSEC validation errors (e.g., SERVFAIL). DNSSEC validation back to the IANA DNSSEC root trust anchor MAY be performed on all DNS queries associated with CAA record lookups performed by Remote Network Perspectives as part of Multi-Perspective Issuance Corroboration. #### 3.2.2.9 Multi-Perspective Issuance Corroboration The Certification Authority implement Multi-Perspective Issuance Corroboration based on Section 3.2.2.9 of the BR. The Certification Authority will confirm the followings using at least two (2)  remote Network Perspectives before Certificate issuance in accordance with based on Quorum Requirements set forth in Section 3.2.2.9 of the BR. - Random Value, IP Address, or Contact Address(Email address or phone number), as used by the relied upon validation method specified in Sections "3.2.2.4 Validation of Domain Authorization or Control" and "3.2.2.5 Authentication for an IP Address"; and - the Certification Authority's authority to issue to the requested domain(s), as specified in Section 3.2.2.8 of this CP/CPS. The Certification Authority MAY reuse corroborating evidence for CAA record quorum compliance for a maximum of 398 days. After issuing a Certificate to a domain, remote Network Perspectives MAY omit retrieving and processing CAA records for the same domain or its subdomains in subsequent Certificate requests from the same Applicant for up to a maximum of 398 days. ### 3.2.3 Authentication of individual identity This Certification Authority does not issue a certificate to individuals. ### 3.2.4 Non-verified subscriber information The Certification Authority does not include information in subscriber certificate when it is not verified. ### 3.2.5 Validation of authority In the case of EV Certificate, the Certification Authority shall verify the name, title and authority of the application supervisor in accordance with Section 3.2.2.8 of the EV Guidelines. Confirmation of authority includes confirmation that the application supervisor is authorized by the subscriber to enter into a subscription agreement on behalf of the subscriber, the application supervisor is authorized to submit or have a processing person in charge of application submit the subscriber's certificate application. Also, the Certification Authority confirms the application supervisor is authorized to submit or have person in charge of application submit information required by this Certification Authority to issue a certificate for the subscriber and the application supervisor is authorized by the subscriber to approve the issuance of a certificate for the subscriber. In the case of OV Certificate, the Certification Authority shall verify that the application supervisor is employed by the Subscriber, that the application supervisor is authorized to apply the application for issuance of certificates on behalf of Subscribers, and that the person in charge designated by the application supervisor applies for the application for issuance of certificates, and that the application supervisor approves the application for issuance of certificates. Furthermore, this Certification Authority confirms that the application supervisor is authorized to agree to the Subscriber Agreement on behalf of the Subscriber and to approve the application for certificate issuance on behalf of the Subscriber. Confirmation to the application supervisor must be made using a reliable method of communication verified by a reliable data source other than the Subscriber. The Certification Authority allows the Subscriber to specify the individuals who may request Certificates. If the Subscriber specifies a certificate requester in writing, then the Certification Authority SHALL NOT accept any certificate requests by other than the specified individual. The Certification Authority SHALL provide the Subscriber a list of its authorized certificate requesters upon the Subscriber’s verified written request. ### 3.2.6 Criteria for interoperation The Certification Authority shall not perform interoperations. ## 3.3 Identification and authentication for re-key requests ### 3.3.1 Identification and authentication for routine re-key The provisions of “3.2 Initial identity validation” of this CP/CPS shall apply correspondingly. ### 3.3.2 Identification and authentication for re-key after revocation The provisions of “3.2 Initial identity validation" of this CP/CPS shall apply correspondingly. However, when it is verified that the certificate information included in the CSR and the expiration date of the certificate to be reissued coincide with the originally issued certificate, validation based on "3.2 Initial identity validation" of this CP/CPS is not performed, and a certificate shall be issued based on the verification of the foregoing coincidence. ## 3.4 Identification and authentication for revocation request When the Certification Authority receives a revocation request from a subscriber via email or in the method indicated on Cybertrust’s website, the Certification Authority shall verify the identity of the person who submitted the revocation, that such person is authorized to submit a revocation request, and the reason for the revocation. As the verification method, the Certification Authority shall compare the information notified to the Certification Authority upon application for issuance of a certificate and the information only known to the Certification Authority and the subscriber. The revocation request submitted from the application-account-site by the person in charge of application is regarded as an authorized request in a same manner. However, the Certification Authority processes the additional verification if necessary. Upon receiving a revocation request for a certificate of a specific subscriber from other than the subscriber of that certificate, the Certification Authority shall investigate the reason of revocation and verify with the subscriber of the certificate if necessary. The Certification Authority verifies the information described above and revoke the certificate if the revocation reason is found corresponding to any of events set forth in the Subscriber Agreement. The email address to be used for the revocation request is indicated in "1.5.2 Contact person" of this CP/CPS and on Cybertrust's website. ----------------------------------------------------- # 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS ## 4.1 Certificate Application ### 4.1.1 Who can submit a certificate application Persons who may apply for a certificate with the Certification Authority shall only be the application supervisor, or a person in charge of application who was authorized by the application supervisor to submit a certificate request. Appointment of the application supervisor or the person in charge of application shall be pursuant to the provisions of "1.3.3 Subscribers" of this CP/CPS. The Certification Authority's verification of a Subscriber’s intent to submit a certificate request shall be answered by the application supervisor or by a person in the Subscriber who is authorized by the application supervisor. ### 4.1.2 Enrollment process and responsibilities A subscriber shall apply for a certificate upon accepting this CP/CPS and the Subscriber Agreement. Upon filing an application, a subscriber is responsible for providing correct and accurate information to the Certification Authority. The method of applying for a certificate is posted on Cybertrust's website. ## 4.2 Certificate application processing ### 4.2.1 Performing identification and authentication functions The provisions of “3.2 Initial identity validation” of this CP/CPS shall apply correspondingly. The Registration Authority of the Certification Authority shall perform the procedure. In cases where the certificate request does not contain all the necessary information about the Applicant, the Certification Authority SHALL obtain the remaining information from the Applicant or, obtain it from a reliable, independent, third-party data source, then confirm it with the Applicant. The Certification Authority shall examine the following as the high-risk status, etc. before issuing a certificate. - In the case of EV Certificate - Records of applications that were dismissed or records of certificates that were revoked by the Certification Authority in the past due to suspicion of past phishing and other fraudulent acts - punishment by an administrative agency against a subscriber (trade embargo). - In the case of OV Certificate - Records of applications that were dismissed or records of certificates that were revoked by the Certification Authority in the past due to suspicion of past phishing and other fraudulent acts. If there is suspicion of fraudulent use of a certificate for which an application was submitted with the Certification Authority based on the foregoing survey, the Certification Authority shall perform additional screening that it deems appropriate as needed. The EV Certificate shall not be issued to an organization under an embargo. If the CAA record (issue/issuewild) contains any of the following values, the Certification Authority recognizes that it is designated as a certification authority that permits issuance of the certificates. cybertrust.ne.jp cybertrust.co.jp Additionally, if an application is made using ACME, it shall be recognized that either of the following values is designated as the Certification Authority authorized to issue subscriber certificates. acme.cybertrust.ne.jp acme.cybertrust.co.jp The Certification Authority MAY reuse documents, data, and previous validation results (including the validation on the Subscriber’s authorization or control over the domain name or the IP address) provided in accordance with Section 3.2 of the BR for the OV Certificate or Section 3.2 of the EV Guidelines for the EV Certificate, and such results shall be valid for the issuance of multiple Certificates. The Certification Authority shall again verify the information for the certificate request if the previous validation results are expired. The maximum reuse periods for validation results are as follows. | Type of Validation Result | Maximum data reuse period | |:--------------|:---------------------| | Identity | 398 days | | Domain Name and IP Address | Until March 14, 2026: 398 days
On or after March 15, 2026: 200 days
On or after March 15, 2027: 100 days
On or after March 15, 2029: 10 days | ### 4.2.2 Approval or rejection of certificate applications When all requirements prescribed in “3.2 Initial identity validation" of this CP/CPS are confirmed, the Registration Authority of the Certification Authority shall approve the application and instruct the Issuing Authority to issue a certificate. The Certification Authority does not notify the subscriber of such issuance in advance. When the requirements prescribed in “3.2 Initial identity validation" of this CP/CPS are not satisfied, the Certification Authority shall dismiss the application for issuing a certificate and reject issuance. In the foregoing case, the Certification Authority shall notify the reason of such rejection to the application supervisor or the person in charge of application who submitted the application. The Certification Authority does not return the information and data obtained from the application supervisor or the person in charge of application during the application process. When the application supervisor or the person in charge of application withdraws the submitted application, the Certification Authority shall dismiss such application. The Certification Authority does not return the information and data obtained from the application supervisor or the person in charge of application during the application process. The Certification Authority SHALL perform final cross-correlation and other due diligence based on the entire corpus of information for the EV Certificate and have multi-person to ensure separation of duties with auditable controls for respect of EV certificate approval and issuance. The Subordinate Certification Authority shall not issue Certificates containing Domain Names that end in an IP Reverse Zone Suffix (“in-addr.arpa” or “ip6.arpa”). ### 4.2.3 Time to process certificate applications After the Registration Authority of the Certification Authority processes the application based on the provisions of “4.2 Certificate application processing" of this CP/CPS, the Issuing Authority shall promptly issue a certificate. ## 4.3 Certificate issuance ### 4.3.1 CA actions during certificate issuance After completing the application procedures based on “3.2 Initial identity validation" of this CP/CPS, the Registration Authority of the Certification Authority shall instruct the Issuing Authority to issue the Subscriber’s certificate. Simultaneously with issuing the certificate, the Issuing Authority shall send to the subscriber the notice set forth in "4.3.2 Notification to subscriber by the CA of issuance of certificate" of this CP/CPS. The Certification Authority do not delegate any of its RA operations to any third parties. Also, the Certification Authority shall enforce multi-factor authentication for all accounts capable of directly causing certificate issuance or performing Registration Authority. The Certification Authority implement a Linting to a Precertificate. The Certification Authority use the Linting tools( https://cabforum.org/resources/tools/ ) that have been widely adopted by the industry. Note that the Subscriber Agreement of the certificate between Cybertrust and the subscriber shall come into force from the time that the subscriber applies for the issuance of a certificate. ### 4.3.2 Notification to subscriber by the CA of issuance of certificate Promptly after the certificate is issued, the Certification Authority shall send an email to the email address designated by the subscriber at the time of application to the effect that the certificate has been issued, and the procedures required for the subscriber to accept the certificate. ## 4.4 Certificate acceptance ### 4.4.1 Conduct constituting certificate acceptance A subscriber shall accept a certificate according to the notified contents recorded in the email sent from the Certification Authority based on the provisions of "4.3.2 Notification to subscriber by the CA of issuance of certificate" of this CP/CPS. The Certification Authority shall deem that a subscriber has accepted the certificate when a subscriber receives the notice of issuance. ### 4.4.2 Publication of the certificate by the CA The certificates of this Certification Authority are published in the repository in accordance with "2.2 Publication of certification information“ of this CP/CPS. Additionally, this Certification Authority will publish subscriber certificates by registering them in CT (Certificate Transparency) logs. ### 4.4.3 Notification of certificate issuance by the CA to other entities The Certification Authority does not notify the issuance of the certificate based on the provisions of “4.3.2 Notification to subscriber by the CA of issuance of certificate" of this CP/CPS other than to the email address designated by the subscriber. ## 4.5 Key pair and certificate usage ### 4.5.1 Subscriber private key and certificate usage A subscriber shall use its private key and certificate only for the usage set forth in “1.4.1 Appropriate certificate uses" of this CP/CPS and any other usage is not allowed. Moreover, a Subscriber’s private key and certificate may only be used by the subscriber, and the subscriber must not license the use thereof to a third party. Other obligations of a subscriber regarding the use of its private key and certificate are set forth in "9.6.3 Subscriber representations and warranties" of this CP/CPS. ### 4.5.2 Relying party public key and certificate usage A relying party shall confirm, under its own responsibility, the validity of the certificate that is used by a subscriber for the usage set forth in "1.4.1 Appropriate certificate uses" of this CP/CPS. Other obligations of a relying party regarding the use of a Subscriber’s public key and certificate are set forth in "9.6.4 Relying party representations and warranties” of this CP/CPS. ## 4.6 Certificate renewal ### 4.6.1 Circumstance for certificate renewal The Certification Authority shall accept a renewal request pursuant to the expiration of the validity period of the certificate used by a subscriber. ### 4.6.2 Who may request renewal The provisions of “4.1.1 Who can submit a certificate application" of this CP/CPS shall apply correspondingly. ### 4.6.3 Processing certificate renewal requests The provisions of "4.2 Certificate application processing" of this CP/CPS shall apply correspondingly. ### 4.6.4 Notification of new certificate issuance to subscriber The provisions of “4.3.2 Notification to subscriber by the CA of issuance of certificate" of this CP/CPS shall apply correspondingly. ### 4.6.5 Conduct constituting acceptance of a renewal certificate The provisions of “4.4.1 Conduct constituting certificate acceptance " of this CP/CPS shall apply correspondingly. ### 4.6.6 Publication of the renewal certificate by the CA The provisions of “4.4.2 Publication of the certificate by the CA" of this CP/CPS shall apply correspondingly. ### 4.6.7 Notification of certificate issuance by the CA to other entities The provisions of “4.4.3 Notification of certificate issuance by the CA to other entities" of this CP/CPS shall apply correspondingly. ## 4.7 Certificate re-key ### 4.7.1 Circumstance for certificate re-key The Certification Authority shall accept a renewal request pursuant to the expiration of the validity period of the certificate used by a subscriber. ### 4.7.2 Who may request certification of a new public key The provisions of “4.1.1 Who can submit a certificate application" of this CP/CPS shall apply correspondingly. ### 4.7.3 Processing certificate re-keying requests The provisions of "4.2 Certificate application processing" of this CP/CPS shall apply correspondingly. ### 4.7.4 Notification of new certificate issuance to subscriber The provisions of “4.3.2 Notification to subscriber by the CA of issuance of certificate" of this CP/CPS shall apply correspondingly. ### 4.7.5 Conduct constituting acceptance of a re-keyed certificate The provisions of “4.4.1 Conduct constituting certificate acceptance" of this CP/CPS shall apply correspondingly. ### 4.7.6 Publication of the re-keyed certificate by the CA The provisions of “4.4.2 Publication of the certificate by the CA" of this CP/CPS shall apply correspondingly. ### 4.7.7 Notification of certificate issuance by the CA to other entities The provisions of “4.4.3 Notification of certificate issuance by the CA to other entities" of this CP/CPS shall apply correspondingly. ## 4.8 Certificate modification ### 4.8.1 Circumstance for certificate modification The Certification Authority shall not accept a request for modifying a previously issued certificate. If there is any modification to the certificate information, a subscriber must promptly request the revocation of the corresponding certificate to the Certification Authority for revoking the corresponding certificate. ### 4.8.2 Who may request certificate modification Not applicable. ### 4.8.3 Processing certificate modification requests Not applicable. ### 4.8.4 Notification of new certificate issuance to subscriber Not applicable. ### 4.8.5 Conduct constituting acceptance of modified certificate Not applicable. ### 4.8.6 Publication of the modified certificate by the CA Not applicable. ### 4.8.7 Notification of certificate issuance by the CA to other entities Not applicable. ## 4.9 Certificate revocation and suspension ### 4.9.1 Circumstances for revocation #### 4.9.1.1 Reasons for Revoking a Subscriber Certificate Subscribers SHALL request revocation of a certificate upon the occurrence of a revocation event as specified in the Subscriber Agreement. This Certification Authority shall revoke a Certificate within 24 hours if the Certification Authority is aware of one or more of the following: 1. The Subscriber requests in writing that this Certification Authority revokes their certificate without specifying the CRL Reason (CRLReason “unspecified (0)” which results in no reasonCode extension being provided in the CRL); 2. The Subscriber notifies Cybertrust that the original Certificate request had not been authorized and does not retroactively grant authorization (CRLReason \#9, privilegeWithdrawn); 3. This Certification Authority obtains evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise (CRLReason \#1, keyCompromise); 4. The Certification Authority 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 (including but not limited to those identified in Section 6.1.1.3(5) of BR) (CRLReason \#1, keyCompromise); or 5. This Certification Authority obtains evidence that the validation of domain authorization or control for any FQDN or IP address in the subscriber’s Certificate should not be relied upon, including cases where the Certification Authority failed to perform CAA checking correctly or where issuance was not permitted according to Section 3.2.2.8 of the BR. (CRLReason #4, superseded). This Certification Authority may revoke a Certificate within 24 hours and must revoke a Certificate within 5 days if the Certification Authority is aware of one or more of the following: 6. The certificate no longer complies with the requirements of Sections 6.1.5 and 6.1.6 of the BR (CRLReason \#4, superseded); 7. This Certification Authority obtains evidence that the certificate was misused (CRLReason \#9, privilegeWithdrawn); 8. This Certification Authority determines or confirms that the subscriber breaches one or more of its material obligation under the Subscriber Agreement (CRLReason \#9, privilegeWithdrawn); 9. This Certification Authority confirms any circumstance indicating that use of the FQDN or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name registrant’s right to use the Domain Name (CRLReason #5, cessationOfOperation); 10. This Certification Authority confirms that the subscriber’s wildcard certificate is used to certify a fraudulent FQDN (CRLReason \#9, privilegeWithdrawn); 11. This Certification Authority confirms a material change in the information contained in the certificate (CRLReason \#9, privilegeWithdrawn); 12. This Certification Authority confirms that the Certificate was issued without complying with the applicable requirements set forth by CA/Browser Forum, this CP/CPS or the Subscriber Agreement provided that this Certification Authority may issue the qualified Certificate with the validity ends of its stated period in the original certificate without charge (CRLReason \#4, superseded); 13. This Certification Authority determines or confirms that any of the information appearing in the certificate is inaccurate (CRLReason \#9, privilegeWithdrawn); 14. The right of this Certification Authority to issue Certificates under the requirements of CA/Browser Forum expires, is revoked, or is terminated, unless this Certification Authority has made arrangements to continue maintaining the CRL/OCSP (Online Certificate Status Protocol) Repository (CRLReason “unspecified (0)” which results in no reasonCode extension being provided in the CRL); 15. Revocation is required by this CP/CPS for a reason that is not otherwise required to be specified by this section 4.9.1.1 (CRLReason “unspecified (0)” which results in no reasonCode extension being provided in the CRL); or 16. This Certification Authority confirms a demonstrated or proven method that exposes the Subscriber’s Private Key to compromise or confirms clear evidence that the specific method used to generate the Private Key was flawed (CRLReason \#1, keyCompromise). This Certification Authority may revoke any Subscriber Certificate in its sole discretion when deemed appropriate. ### 4.9.2 Who can request revocation Persons who may request revocation shall be the application supervisor, the person in charge of application, or an agent who is duly authorized by the subscriber and who knows information that was notified by the Certification Authority when the issuance application of the certificate was submitted, which is shared only between the Certification Authority and the subscriber. Other third parties may submit Certificate Problem Reports informing the Certification Authority of reasonable cause, if exists, to revoke the certificate. Prior to revoking a Certificate, this Certification Authority may verify the identity and authority of the entity requesting revocation. ### 4.9.3 Procedure for revocation request A subscriber shall submit a revocation request via email or in the method indicated by Cybertrust on its website. The email must include information that is known only to the Certification Authority and the subscriber, reason for revocation, contact information and so on in accordance with instructions of the Certification Authority. The Certification Authority shall verify the reason for revocation as prescribed in “3.4 Identification and authentication for revocation request" of this CP/CPS. For the Problem Report informed by a third party, the Certification Authority SHALL investigate the notified issue and SHALL revoke the certificate when the cause is found reasonable. The Certification Authority does not notify the revocation to the subscriber after revokes the certificate. For revocations that involve the free reissuance of a certificate set forth in “9.1 Fees" of this CP/CPS, there may be cases where the notice of revocation is given together with the notice of free reissuance of a certificate. ### 4.9.4 Revocation request grace period In the occurrence of an event corresponding to "4.9.1.1 Reasons for Revoking a Subscriber Certificate " of this CP/CPS, a subscriber shall promptly submit a revocation request. ### 4.9.5 Time within which CA must process the revocation request The Certification Authority accepts the revocation request 24 hours a day, 7 days a week. The Registration Authority of the Certification Authority shall receive the revocation request, take the procedures based on the provisions of "4.9.3 Procedure for revocation request" of this CP/CPS, and thereafter promptly instruct the Issuing Authority to revoke the target certificate. After receiving the revocation instruction, the Issuing Authority shall promptly revoke the relevant certificate. ### 4.9.6 Revocation checking requirement for relying parties The relying parties shall verify the certificate revocation with the CRL issued by the Certification Authority or the OCSP. ### 4.9.7 CRL issuance frequency (if applicable) The Certification Authority issues the CRL in a cycle of at least 7 days. However, the Certification Authority updates and discloses the CRL in 24 hours after revocation if there is any revoked Subscriber certificate. The validity period of the CRL shall not exceed 10 days. ### 4.9.8 Maximum latency for CRLs (if applicable) The Certification Authority shall publish the CRL within reasonable time after the issuance of the CRL. For the cycle of CRL update, "4.9.7 CRL issuance frequency (if applicable)" of this CP/CPS shall be applied. ### 4.9.9 On-line revocation/status checking availability The Certification Authority shall provide revocation information based on OCSP, in addition to CRL. OCSP responses of the Certification Authority conform to RFC 6960. OCSP responses are signed by an OCSP Responder whose Certificate is signed by the CA that issued the Certificate with its revocation status being checked. The OCSP signing Certificate contains an extension of type id‐pkix‐ocsp‐nocheck. ### 4.9.10 On-line revocation checking requirements The GET method described in RFC6960 and/or RFC5019 shall be supported for the OCSP. OCSP responses for the status of subscriber certificates from this service will have a validity interval of 8 hours or more and 10 days or less. The Certification Authority updates information provided via OCSP at least every 4 days and at least 8 hours prior to the nextUpdate time. The Certification Authority shall provide an OCSP response within 15 minutes after the certificate or Precertificate becomes publicly available or becomes usable. The responder shall not respond with a "good" status if the OCSP responder receives a request for the status of a certificate that has not been issued. The Certification Authority shall provide CRL and OCSP services and responses for all certificates presumed to exist based on the presence of a Precertificate, even if the certificate does not actually exist. If necessary, The Certification Authority will revoke a certificate presumed to exist, even if the certificate does not actually exist. ### 4.9.11 Other forms of revocation advertisements available If the Subscriber Certificate is for a high-traffic FQDN, this Certification Authority MAY rely on stapling, in accordance with [RFC4366], to distribute its OCSP responses. In this case, this Certification Authority ensure that the Subscriber “staples” the OCSP response for the Certificate in its TLS handshake. This Certification Authority SHALL enforce this requirement on the Subscriber through the Subscriber Agreement. ### 4.9.12 Special requirements re key compromise When the Certification Authority learns that a subscriber’s private key has been compromised, or there is a possibility thereof, the Certification Authority initiates revocation procedures based on "4.9.3 Procedure for revocation request" of this CP/CPS. This Certification Authority accepts a report for the Private Key Compromise from the third party at the problem report contact listed in "1.5.2 Contact person" of this CP/CPS. Reports or subsequent responses to this Certification Authority of key compromise shall include; 1. the demonstration on the Private Key Compromise: - private Key itself and/or - a CSR signed by the compromised private key with the Common Name of which value specified by this Certification Authority 2. name and reachable contact information such as email address and/or phone number of a person who reports the problem. ### 4.9.13 Circumstances for suspension The Certification Authority does not accept applications for suspending the certificates. ### 4.9.14 Who can request suspension Not applicable. ### 4.9.15 Procedure for suspension request Not applicable. ### 4.9.16 Limits on suspension period Not applicable. ## 4.10 Certificate status services The Certification Authority shall not provide services that enable the verification of the certificate status other than by way of CRL and OCSP. ### 4.10.1 Operational characteristics Revocation entries on a CRL or OCSP Response shall not be removed until after the Expiry Date of the revoked Certificate. ### 4.10.2 Service availability The Certification Authority shall operate and maintain its CRL and OCSP capability with resources sufficient to provide a response time of ten seconds or less under normal operating conditions. The Certification Authority shall maintain an online 24 hours a day, 7 days a week Repository that application software can use to automatically check the current status of all unexpired Certificates issued by the Certification Authority. The Certification Authority shall maintain a continuous 24 hours a day, 7 days a week ability to respond internally to a high-priority Certificate Problem Report, and where appropriate, forward such a notification to law enforcement authorities or CTJPA, and/or revoke a Certificate that is the subject of such a notification. ### 4.10.3 Optional features No stipulation. ## 4.11 End of subscription The reasons for ending the use of a Subscriber’s certificate shall be set forth in the Subscriber Agreement. Moreover, if a subscriber wishes to terminate the Subscriber Agreement midway during the validity period of the certificate, the subscriber must submit a certificate revocation request with the Certification Authority based on "4.9.3 Procedure for revocation request" of this CP/CPS. ## 4.12 Key escrow and recovery ### 4.12.1 Key escrow and recovery policy and practices The Certification Authority does not escrow and recovery subscriber private keys. ### 4.12.2 Session key encapsulation and recovery policy and practices Not applicable. ---------------------------------------------------- # 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS ## 5.1 Physical controls ### 5.1.1 Site location and construction The Certification Authority system shall be installed in a facility that is not easily affected by earthquakes, fires, floods, and other disasters (the "Facility"; unless separately prescribed herein, it shall include the main site and the backup site set forth in "5.1.8 Off-site backup" of this CP/CPS). The Facility shall undergo architectural measures for preventing earthquakes, fires, floods and other disasters as well as preventing unauthorized invasion. Information regarding the location of the Certification Authority shall not be indicated outside or inside the building where the Facility is located. ### 5.1.2 Physical access The Facility and the respective rooms where certification operations are performed in the Facility shall be set with a security level according to the importance of the operation, and suitable entrance/exit control shall be performed. For authentication upon entering/existing the room, an entrance/exit card or biometric identification or other implementable technological means shall be used in accordance with the security level. For entry into particularly important rooms and one or both doors of the safe used for storing the Certification Authority's system and other important assets in the same room, measures must be implemented where the doors cannot be opened unless multiple persons with entrance authority are present. The Facility and the respective rooms where certification operations are performed in the Facility shall be monitored with a monitoring system 24 hours a day, every day. ### 5.1.3 Power and air conditioning In the Facility, power sources with necessary and sufficient capacity for operating Certification Authority system and related equipment shall be secured. An uninterruptible power supply and a private power generator shall be installed as measures against instantaneous interruption and blackouts. Air-conditioning equipment shall be installed in the respective rooms where certification operations are performed, and this shall be duplicated in particularly important rooms. ### 5.1.4 Water exposures A water leakage detector shall be installed in the particularly important rooms in the Facility where certification operations are performed, and waterproofing measures shall be taken. ### 5.1.5 Fire prevention and protection The Facility is of a fire-proof construction. The particularly important rooms shall be located within the fire retarding division, and fire alarms and automatic gas fire extinguishers shall be installed. ### 5.1.6 Media storage Mediums containing the backup data of the Certification Authority system and documents and the like used in the screening operation shall be archived in a room in which only authorized personnel can enter. ### 5.1.7 Waste disposal Documents containing Confidential Information shall be disposed of after being shredded with a shredder. Electronic mediums shall be physically destroyed, initialized, demagnetized, or subject to other similar measures to completely erase the recorded data before being discarded. ### 5.1.8 Off-site backup The original or copy of the private key of Certification Authority and important assets for system recovery shall be archived on the main site and in a remote backup site. The locking of the safe in the backup site shall be controlled by multiple persons, and the opening/closing of the safe shall be recorded. ### 5.1.9 Anti-earthquake measures The Facility is of an earthquake-resistant construction, and the equipment and fixtures of Certification Authority system have undergone tip-prevention measures and anti-drop measures. ## 5.2 Procedural controls ### 5.2.1 Trusted roles Cybertrust shall set forth the personnel required for operating the Certification Authority (the "Certification Authority Staff") and their roles as follows. #### 5.2.1.1 Certification Authority Supervisor The Certification Authority Supervisor shall govern the Certification Authority. #### 5.2.1.2 Issuing Authority Manager The Issuing Authority Manager shall control the operations of the Issuing Authority of the Certification Authority. #### 5.2.1.3 Issuing Authority System Administrator The Issuing Authority System Administrator shall maintain and control the Certification Authority system under the control of the Issuing Authority Manager. #### 5.2.1.4 Issuing Authority Operator The Issuing Authority Operator shall assist the operations of the Issuing Authority Manager and the Issuing Authority System Administrator; provided, however, that the Issuing Authority Operator is not authorized to operate the Certification Authority system. #### 5.2.1.5 Registration Authority Manager The Registration Authority Manager shall control the operations of the Registration Authority of the Certification Authority. #### 5.2.1.6 Registration Authority Operator Manager The Registration Authority Operator Manager shall control the Registration Authority Operators. #### 5.2.1.7 Registration Authority Operator The Registration Authority Operator shall process the applications from the subscribers under the control of the Registration Authority Manager and request the issuance or revocation of certificates to the Issuing Authority. ### 5.2.2 Number of persons required per task Cybertrust shall appoint two or more Issuing Authority System Administrators and Registration Authority Operators, respectively. ### 5.2.3 Identification and authentication for each role Cybertrust shall establish the entrance authority of the respective rooms where certification operations are performed and the operation authority of the Certification Authority system in accordance with the respective roles. For entry into the respective rooms and upon operation of the system, an entrance/exit card, biometric identification, digital certificate, ID and password are used independently or in combination to verify and authenticate the identification and entrance/operation authority. ### 5.2.4 Roles requiring separation of duties Cybertrust does not allow the concurrent serving of the Issuing Authority and the Registration Authority, and it does not allow the Certification Authority Supervisor to concurrently serve another role. ## 5.3 Personnel controls ### 5.3.1 Qualifications, experience, and clearance requirements The Certification Authority Staff shall be hired and assigned based on the recruitment standards to be separately set forth by Cybertrust. ### 5.3.2 Background check procedures The background check of employees to be assigned as the Certification Authority Staff shall be conducted based on Cybertrust's internal rules and regulations and the requirements set forth in the BR. With respect to the Certification Authority staff engaged in operations related to the EV Certificates, the requirements set forth in the EV Guidelines shall also apply. ### 5.3.3 Training requirements Cybertrust shall implement training requirements and procedures to all employees being assigned as the Certification Authority Staff. The training requirements and procedures shall include, in addition to the education of this CP/CPS and the Related Rules, the required training requirements and procedures in accordance with the role of the Certification Authority Staff. The validity of the training requirements and procedures shall be evaluated by the Issuing Authority Manager or the Registration Authority Manager, and retraining shall be implemented as needed. ### 5.3.4 Retraining frequency and requirements Cybertrust shall implement retraining requirements and procedures to the Certification Authority Staff as needed. At the least, the Certification Authority shall implement training in the occurrence of the following events: 1. When this CP/CPS, the subscriber agreement, and the Related Rules are amended, and when CTJ PA, the Certification Authority Supervisor, the Issuing Authority Manager, or the Registration Authority Manager thinks it necessary; 2. When the system of the Certification Authority where the Certification Authority Staff is assigned is changed, and when CTJ PA, the Certification Authority Supervisor, the Issuing Authority Manager or the Registration Authority Manager thinks it necessary; and 3. When CTJ PA, the Certification Authority Supervisor, the Issuing Authority Manager, or the Registration Authority Manager otherwise thinks it necessary. ### 5.3.5 Job rotation frequency and sequence Cybertrust shall rotate jobs of the Certification Authority Staff as needed. ### 5.3.6 Sanctions for unauthorized actions When a Certification Authority Staff conducts an act that is in breach of this CP/CPS, Cybertrust's internal rules and regulations and the Related Rules, Cybertrust shall promptly investigate the cause and scope of influence and impose a penalty on that Certification Authority Staff in accordance with Cybertrust's work rules. ### 5.3.7 Independent contractor requirements When Cybertrust is to assign employees of outsources, contract employees or dispatched employees (collectively, the "Contract Employees") as a Certification Authority Staff, Cybertrust shall conclude a contract that clearly sets forth the details of the outsourced work, confidentiality obligation to be imposed on the Contract Employees, and penal regulations, and demand the Contract Employees to observe this CP/CPS, Cybertrust's internal rules and regulations, and the Related Rules. When the Contract Employees conduct an act that is in breach of this CP/CPS, Cybertrust's internal rules and regulations, and the Related Rules, penalties shall be imposed based on the foregoing contract. ### 5.3.8 Documentation supplied to personnel Cybertrust shall implement measures so that the respective Certification Authority Staff can only refer to documents that are required according to their respective roles. ## 5.4 Audit logging procedures ### 5.4.1 Types of events recorded In order to evaluate the compliance of this CP/CPS and the suitability of security, Cybertrust shall collect the following records as audit logs. The records shall include the date and time, identity of the person making the journal record, and description of the record. 1. The Certification Authority certificate and key lifecycle events, including: - 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; and - Introduction of new Certificate Profiles and retirement of existing Certificate Profiles. 2. Subscriber Certificate lifecycle management events, including: - Certificate requests, renewal, and re-key requests, and revocation; - All verification activities stipulated in the relevant requirements and this CP/CPS; - Approval and rejection of certificate requests; - Issuance of Certificates; - Generation of Certificate Revocation Lists; and - Signing of OCSP Responses. - Multi-Perspective Issuance Corroboration attempts from each Network Perspective, minimally recording the following information: - an identifier that uniquely identifies the Network Perspective used; - the attempted domain name and/or IP address; and - the result of the attempt (e.g., "domain validation pass/fail", "CAA permission/prohibition"). - Multi-Perspective Issuance Corroboration quorum results for each attempted domain name or IP address represented in a Certificate request (i.e., "3/4" which should be interpreted as "Three (3) out of four (4) attempted Network Perspectives corroborated the determinations made by the Primary Network Perspective). 3. Security events, including: - 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; - Router and Firewall activities; and - Entries to and exits from the Certification Authority facility. 4. Log records MUST include the following elements: - Date and time of event; - Identity of the person making the journal record (when applicable); and - Description of the event. #### 5.4.1.1 Router and firewall activities logs Among the audit logs stipulated in this CP/CPS “5.4.1 Types of events recorded”, “Router and Firewall activities logs” of Security events shall be included the following. 1. Successful and unsuccessful login attempts to routers and firewalls; and 2. Logging of all administrative actions performed on routers and firewalls, including configuration changes, firmware updates, and access control modifications; and 3. Logging of all changes made to firewall rules, including additions, modifications, and deletions; and 4. Logging of all system events and errors, including hardware failures, software crashes, and system restarts. ### 5.4.2 Frequency of processing log Cybertrust shall inspect the audit logs prescribed in "5.4.1 Types of events recorded" of this CP/CPS on a regular basis and, as necessary. ### 5.4.3 Retention period for audit log The Certification Authority SHALL retain, for at least two years: 1. Certification Authority certificate and key lifecycle management event records (as set forth in Section 5.4.1 (1) of the BRs) after the later occurrence of: - the destruction of the Certification Authority Private Key; or - the revocation or expiration of the final Certification Authority Certificate in that set of Certificates that have an X.509v3 basicConstraints extension with the cA field set to true and which share a common Public Key corresponding to the Certification Authority Private Key; 2. Subscriber Certificate lifecycle management event records (as set forth in Section 5.4.1 (2) of the BRs) after the revocation or expiration of the Subscriber Certificate; 3. Any security event records (as set forth in Section 5.4.1 (3) of the BRs) after the event occurred. When the audit logs are no longer required, the Certification Authority shall dispose of such audit logs based on the provisions of "5.1.7 Waste disposal" of this CP/CPS. ### 5.4.4 Protection of audit log Cybertrust shall implement access control to the audit logs so that only authorized personnel can view the audit logs. The Certification Authority shall implement physical access control to the safe, and logical access control to folders and the like in cases of electronic mediums. ### 5.4.5 Audit log backup procedures Cybertrust shall acquire the backup of the logs in the systems of the Registration Authority and the Issuing Authority. For paper mediums, only the original copies thereof need to be archived. ### 5.4.6 Audit collection system (internal vs. external) Systems of the Registration Authority and the Issuing Authority shall automatically collect the audit logs by using the function installed in the system. ### 5.4.7 Notification to event-causing subject Cybertrust shall collect and inspect the audit logs without notifying the party that caused the event. ### 5.4.8 Vulnerability assessments Cybertrust conducts the following annual Risk Assessment: 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; and 3. Assesses the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the CA has in place to counter these threats. Cybertrust also performs regular vulnerability assessment and implement the necessary measures for correcting the vulnerability. It shall also take necessary measures when risks or threats are discovered by regularly inspecting audit logs. ## 5.5 Records archival ### 5.5.1 Types of records archived Cybertrust shall archive the following information in addition to the audit logs prescribed in "5.4.1 Types of events recorded" of this CP/CPS: 1. certificates of the Certification Authority; 2. subscriber's certificate; 3. CRL; 4. internal audit report; 5. external audit report; 6. documents received from the subscriber at the time of application; and 7. this CP/CPS and the Related Rules. ### 5.5.2 Retention period for archive The Certification Authority shall retain archived audit logs set forth in "5.5.1 Types of records archived" of this CP/CPS and records listed below for a period of at least two years from their record creation timestamp or as long as required per "5.4.3 Retention period for audit log", whichever is longer. 1. All archived documentation related to the Certificate Systems and Certificate Management Systems. 2. All archived documentation relating to the verification, issuance, and revocation of certificate requests and Certificates after the later occurrence of: - such records and documentation were last relied upon in the verification, issuance, or revocation of certificate requests and Certificates; or - the expiration of the Subscriber Certificates relying upon such records and documentation. The Certification Authority MAY choose a greater value as more appropriate in order to be able to investigate possible security or other types of incidents that will require retrospection and examination of past records archived. When records are no longer required, the Certification Authority shall dispose of such records based on the provisions of "5.1.7 Waste disposal" of this CP/CPS. ### 5.5.3 Protection of archive Records shall be protected based on the same procedures as "5.4.4 Protection of audit log" of this CP/CPS. ### 5.5.4 Archive backup procedures Records shall be backed up based on the same procedures as "5.4.5 Audit log backup procedures" of this CP/CPS. ### 5.5.5 Requirements for time-stamping of records Cybertrust shall record the drafting date or processing date on forms and the like. If the date alone lacks authenticity as a record, the time should also be recorded. The issued date and time shall be recorded for certificates of the Certification Authority and the subscribers. The Certification Authority system shall undergo necessary measures for recording the accurate date and time of the issued certificate and audit logs. ### 5.5.6 Archive collection system (internal or external) Certificates shall automatically be collected by using on the function of the Certification Authority system. Other paper mediums shall be collected by the Certification Authority Staff. ### 5.5.7 Procedures to obtain and verify archive information Cybertrust shall limit persons authorized to acquire and view records to the Certification Authority Staff, the auditor, and the persons authorized by CTJ PA. Validation regarding the legibility of records shall be implemented as needed. ## 5.6 Key changeover Cybertrust renews the key pair of the Certification Authority so that the validity of the certificates of the Certification Authority does not expire while a subscriber's certificate is valid. The certificate that contains the Certification Authority's renewed public key is posted on Cybertrust's website. ## 5.7 Compromise and disaster recovery ### 5.7.1 Incident and compromise handling procedures #### 5.7.1.1 Incident Response and Disaster Recovery Plans Cybertrust shall establish and document 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 any incident that prevents business continuity. These procedures shall be tested, reviewed, and made any necessary update at least annually to ensure their continued effectiveness. When the private key of the Certification Authority is compromised, Cybertrust shall execute the following: 1. discontinuation of certification operations using the compromised private key; 2. revocation of all the certificates that were issued from the Certification Authorities that used the compromised private key; 3. investigation of the cause of compromise; 4. formulation of proposed remedial measures and evaluation/approval thereof by CTJ PA; 5. execution of remedial measures; 6. assessment on appropriateness of resuming business operations; 7. generation of new key pairs and issuance of certificates; 8. resumption of certification operations (including notification to subscribers and relying parties); and 9. reissuance of certificates When the Certification Authority suffers from a disaster, the Certification Authority shall perform recovery operations using backup hardware, software and data based on the business continuation plan prescribed in "5.7.4 Business continuity capabilities after a disaster" of this CP/CPS, exert efforts to resume the certification operations, and publish the fact of such resumption to the subscribers and relying parties when the certification operations are resumed. #### 5.7.1.2 Mass Revocation Plans Cybertrust maintains a comprehensive and actionable Mass Revocation Plan to prepare for a Mass Revocation Event. Mass Revocation Plan includes clearly defined procedures to ensure a rapid, consistent, and reliable response in the event of a large-scale certificate revocation. This plan is tested and reviewed annually, and improvements are made based on lessons learned through these exercises to ensure continual enhancement of Cybertrust’s readiness. The mass revocation plan shall consist of the following elements: 1. Activation criteria 2. Customer contact information 3. Automation points 4. Targets and timelines 5. Subscriber notification methods 6. Role assignments 7. Training and education 8. Plan testing 9. Post-test analysis and update schedule ### 5.7.2 Computing resources, software, and/or data are corrupted When hardware, software, or data is destroyed, Cybertrust shall continue performing the certification operations by using the backup hardware, software, or data. ### 5.7.3 Entity private key compromise procedures In the event the private key that is being managed under the Subscriber’s own responsibility is compromised, or suspected of being compromised, the subscriber must take the certificate revocation procedures based on the procedures prescribed in "4.9 Certificate revocation and suspension" of this CP/CPS. The Certification Authority revokes a Subscriber’s certificate based on "4.9.3 Procedure for revocation request" of this CP/CPS. ### 5.7.4 Business continuity capabilities after a disaster Cybertrust shall separately set forth a business continuation plan regarding the recovery measures for recovering from disasters and business continuity. The business continuation plan defines the operating procedures of recovery and resumption of all or a part (revocation processing) of the operations of the Certification Authority by using data and the like archived in the Facility. With regard to the recovery time from disasters, the step-by-step recovery target is set forth in the business continuation plan based on investigations of the disaster situation. ## 5.8 CA or RA termination When Cybertrust is to terminate the operations of the Certification Authority, it shall notify the subscribers in advance, as well as publish information to such effect on Cybertrust's website. The information of subscribers held by Cybertrust shall be disposed of or provided to the transferee of business operations, and this shall be announced on Cybertrust's website after the termination of operations. --------------------------------- # 6. TECHNICAL SECURITY CONTROLS ## 6.1 Key pair generation and installation ### 6.1.1 Key pair generation The key pair used in the Certification Authority and an OCSP Responder is generated based on instructions of the Certification Authority Supervisor by multiple Issuing Authority System Administrators under the control of the Issuing Authority Manager. Upon generating the key pair of the Certification Authority, a private key cryptographic module (the "HSM") that satisfies the FIPS 140-2 Level 3 or higher standard and other methods of secret sharing shall be used. Upon generating the key pair used in an OCSP Responder, the HSM that satisfies the FIPS 140-2 Level 3 standard shall be used. The key pair of the Certification Authority shall be generated in the presence of the auditor set forth in "8.2 Identity/qualifications of assessor" and "8.3 Assessor's relationship to assessed entity" of the CP/CPS or, when the auditor is not available, by presenting to the auditor the recording of the generation procedures so as to ensure that the generation of the key pair of the Certification Authority was performed according to predetermined procedures based on Key Generation Script. This Certification Authority rejects a certificate request if one or more of the following conditions on generation of Subscriber’s key pair are met; 1. The Key Pair does not meet the requirements set forth in Section 6.1.5 and/or Section 6.1.6 of the BRs; 2. There is clear evidence that the specific method used to generate the Private Key was flawed; 3. This Certification Authority is aware of a demonstrated or proven method that exposes the Applicant’s Private to compromise; 4. This Certification Authority has previously been **notified** that the Applicant’s Private Key has suffered a Key Compromise, such as described in “4.9.3 Procedure for revocation request” and “4.9.12 Special requirements re key compromise” of this CP/CPS; or 5. The Public Key corresponds to an industry-demonstrated weak Private Key. For a certificate request, this Certification Authority is at least the following precautions shall be implemented: - In the case of Debian weak keys vulnerability (https://wiki.debian.org/SSLkeys/), the Certification Authority shall reject all public keys corresponding to key types and sizes listed at https://github.com/cabforum/Debian-weak-keys/. For all other public keys meeting the requirements in Section 6.1.5 of BR, with the exception of RSA key sizes greater than 8192 bits, the Certification Authority shall reject Debian weak keys. - In the case of ROCA vulnerability, the Certification Authority shall reject public keys identified by the tools available at https://github.com/crocs-muni/roca or equivalent. - In the case of Close Primes vulnerability (https://fermatattack.secvuln.info/), the Certification Authority shall reject weak public keys which can be factored within 100 rounds using Fermat’s factorization method. This Certification Authority does not generate the key pair used in a Subscriber certificate when the certificate profile containing an extKeyUsage extension which includes either the values id-kp-serverAuth [RFC5280] or anyExtendedKeyUsage [RFC5280]. This Certification Authority does not also accept the certificate request when the Subscriber’s key pair is previously generated by this Certification Authority. ### 6.1.2 Private key delivery to subscriber The Certification Authority does not deliver and archive a subscriber's private key. A subscriber's private key shall be generated independently by the subscriber. ### 6.1.3 Public key delivery to certificate issuer A Subscriber shall include the public key in the data for requesting the issuance of a certificate, and then deliver the same to the Certification Authority via the website provided by Cybertrust. ### 6.1.4 CA public key delivery to relying parties The Certification Authority does not deliver the public key of the Certification Authority to relying parties. The certificates of the Certification Authority including the public key of the Certification Authority are published on Cybertrust's website. ### 6.1.5 Key sizes The key signature system and key size of the certificates of the Certification Authority shall be as follows. | Name of Certification Authority | Algorithm Type | Key Size | |:------------------------------------:|:--------------:|:--------:| | Cybertrust Japan SureServer EV CA G3 | SHA2 with RSA | 2048 bit | | Cybertrust Japan SureServer CA G4 | SHA2 with RSA | 2048 bit | The key signature system and key size of the OCSP Responder Certificate shall be as follows. | OCSP Responder Certificate | Algorithm Type | Key Size | |:--:|:--:|:--:| | Certificate issued by Cybertrust Japan SureServer EV CA G3 | SHA2 with RSA | 2048 bit | | Certificate issued by Cybertrust Japan SureServer CA G4 | SHA2 with RSA | 2048 bit | The key signature system and key size of the subscriber's certificate shall be as follows. | subscriber's certificate | Algorithm Type | Key Size | |:--:|:--:|:--:| | Certificate issued by Cybertrust Japan SureServer EV CA G3 | SHA2 with RSA | At least 2048 bit (with a modulus size in bits divisible by 8) | | Certificate issued by Cybertrust Japan SureServer CA G4 | SHA2 with RSA | At least 2048 bit (with a modulus size in bits divisible by 8) | ### 6.1.6 Public key parameters generation and quality checking All CA keys are generated on FIPS 140-2 qualified hardware which ensures the proper parameters and their quality for Public Keys. ### 6.1.7 Key usage purposes (as per X.509 v3 key usage field) The key usage of certificates of the Certification Authority shall be Certificate Signing, CRL Signing. The key usage of a subscriber's certificate shall be Digital Signature, Key Encipherment. The key usage of a certificate for use in the Certification Authority's OCSP Responder shall be Digital Signature. ## 6.2 Private Key Protection and Cryptographic Module Engineering Controls ### 6.2.1 Cryptographic module standards and controls The cryptographic module for controlling the key pair of the Certification Authority shall be the HSM that satisfies the FIPS 140-2 Level 3 standard. The HSM is controlled by the Issuing Authority. The key pair used in an OCSP Responder is controlled based on the HSM that satisfies the FIPS 140-2 Level 3 standard. The OCSP Responder is controlled by the Issuing Authority. ### 6.2.2 Private key (n out of m) multi-person control The private key used by the Certification Authority and an OCSP Responder shall at all times be controlled by multiple Issuing Authority System Administrators. ### 6.2.3 Private key escrow The Certification Authority does not escrow the private key of the Certification Authority and of subscribers. ### 6.2.4 Private key backup The Issuing Authority System Administrator shall back up the private key of the Certification Authority. The private key backed up from the HSM shall be encrypted and then divided into multiple pieces, and each of them shall be safely archived in a lockable safe. The private key to be used in an OCSP Responder is backed up and archived, by the Issuing Authority System Administrator, in a status encrypted by using the HSM function. ### 6.2.5 Private key archival Cybertrust shall not archive the private key used by the Certification Authority and the OCSP Responder. ### 6.2.6 Private key transfer into or from a cryptographic module Cybertrust shall transfer a copy of the private key used by the Certification Authority to the backup site based on a safe method. When it is necessary to restore the private key of the Certification Authority due to a failure of the HSM or other reasons, the Issuing Authority System Administrator shall restore the private key using the backup archived in the main site or the backup site. When the recovery of the private key of an OCSP Responder is required, the Issuing Authority System Administrator shall perform such recovery by using the system backup archived in the main site or the backup site; provided, however, that, based on the approval of the Certification Authority Supervisor of the Certification Authority, there may be cases where the corresponding certificate is revoked, and a private key is newly generated. ### 6.2.7 Private key storage on cryptographic module The private key used by the Certification Authority shall be stored in an encrypted state in the HSM that satisfies the standards of FIPS 140-2 Level 3. The private key used by the OCSP Responder shall be stored in an encrypted state in the HSM that satisfies the standards of FIPS 140-2 Level 3. ### 6.2.8 Method of activating private key The private key used by the Certification Authority and the OCSP Responder shall be activated by multiple Issuing Authority System Administrators based on the procedures to be separately prescribed with the approval of the Issuing Authority Manager. The activation operation shall be recorded. ### 6.2.9 Method of deactivating private key The private key used by the Certification Authority and the OCSP Responder shall be non-activated by multiple Issuing Authority System Administrators based on the procedures to be separately prescribed with the approval of the Issuing Authority Manager. The non-activation operation shall be recorded. ### 6.2.10 Method of destroying private key The private key used by the Certification Authority and the OCSP Responder shall be destroyed by multiple Issuing Authority System Administrators based on the procedures to be separately prescribed under the control of the Issuing Authority Manager and according to instructions of the Certification Authority Supervisor. Simultaneously, the private key that was backed up pursuant to "6.2.4 Private key backup" of this CP/CPS shall also be destroyed based on the same procedures. The destruction operation shall be recorded. ### 6.2.11 Cryptographic Module Rating The Certification Authority shall use the HSM that satisfies the standards set forth in "6.2.1 Cryptographic module standards and controls" of this CP/CPS. ## 6.3 Other aspects of key pair management ### 6.3.1 Public key archival Storage of the public key shall be carried out by storing the certificate containing that public key. ### 6.3.2 Certificate operational periods and key pair usage periods The maximum validity periods of certificates of the Certification Authority and of subscriber shall be as per the following table. | Type | Private Key | Certificate | |:---|:---|:---| | Certificates of the Certification Authority | Not specified | No more than 120 months | | OCSP Responder Certificate | Not specified | No more than 25 months | | iTrust EV SSL/TLS Server Certificate
iTrust SSL/TLS Server Certificate | Not specified | Untill March 14, 2026: Less than 398 days
On or after March 15, 2026: Less than 200 days
On or after March 15, 2027: Less than 100 days
On or after March 15, 2029: Less than 47 days | ## 6.4 Activation data ### 6.4.1 Activation data generation and installation The activation data used by the Certification Authority shall be generated and set upon giving consideration so that it cannot be easily speculated. ### 6.4.2 Activation data protection The activation data used in the Certification Authority shall be stored in a lockable safe in a room that is subject to entrance/exit control based on the provisions of "5.1.2 Physical access" of this CP/CPS. ### 6.4.3 Other aspects of activation data No stipulation. ## 6.5 Computer security controls ### 6.5.1 Specific computer security technical requirements The Certification Authority shall enforce multi-factor authentication for all accounts capable of directly causing certificate issuance. In addition to the above, the Certification Authority system shall perform the following as security measures: 1. authentication of authority of the operator; 2. identification and authentication of the operator; 3. acquisition of operation logs for important system operations; 4. setup of appropriate passwords and periodical modification thereof; and 5. backup and recovery. ### 6.5.2 Computer security rating Cybertrust shall implement, in advance, installation assessment of hardware and software to be installed by the Certification Authority. Cybertrust shall also continuously collect information and perform evaluations regarding the security vulnerability in the system to be used and take necessary measures if a critical vulnerability is discovered. ## 6.6 Life cycle technical controls ### 6.6.1 System development controls The construction and modification of the Certification Authority system shall be performed based on the provisions to be separately set forth under the control of the development supervisor appointed internally by Cybertrust. When the development supervisor deems it necessary, necessary and sufficient verification shall be carried out in a testing environment to verify that there are no security-related problems. ### 6.6.2 Security management controls The Certification Authority system shall undergo necessary settings in order to ensure sufficient security. In addition to implementing entrance/exit control and access authorization control according to the security level and antivirus measures of the said system, Cybertrust shall continuously collect information and perform evaluations regarding the security vulnerability, and promptly take necessary measures if a critical vulnerability is discovered. ### 6.6.3 Life cycle security controls Cybertrust shall appoint a supervisor in the respective processes of development, operation, change, and disposal of the Certification Authority system, formulate and evaluate the work plan or procedures, and conduct testing as needed. The respective operations shall be recorded. ## 6.7 Network security controls The Certification Authority manages network security in compliance with the Network and Certificate System Security Requirements set forth by the CA/Browser Forum. The Certification Authority's system and external systems, such as the Internet, shall be connected via a firewall or the like and be monitored by an intrusion detection system. This Certification Authority conducts vulnerability assessments (Section 5.4.8 Vulnerability Assessments). If a discovered vulnerability is assessed as critical, remediation or mitigation measures must be completed within 96 hours. For vulnerabilities assessed at other levels, a decision on the response will be made within 30 days following a risk assessment and the results shall be documented in a report. ## 6.8 Time-stamping According to "5.5.5 Requirements for time-stamping of records” of this CP/CPS. ----------------------------------------- # 7. CERTIFICATE, CRL, AND OCSP PROFILES ## 7.1 Certificate profile Matters regarding the certificate profile of the Certification Authority Certificates, Subscribers and OCSP Responder Certificate are set forth in Appendix B. the EV Certificate does not include any Subject Distinguished Name attributes besides the ones specified in Section 7.1.4.2 of the EV Guidelines. ### 7.1.1 Version number(s) This Certification Authority issues X.509 version 3 Certificates. ### 7.1.2 Certificate extensions The Certification Authority uses certificate extensions in accordance with applicable industry standards, including RFC 5280. The Certification Authority does not issue certificates with a critical private extension. Certificates must contain the ExtendedKeyUsage extension, aligning to Application Software Supplier granted trust bits and private PKI use cases. Certificates may not contain the anyExtendedKeyUsage value. Subordinate certification authorities’ certificates for publicly trusted certificates, with the exception of cross-certificates that share a private key with a corresponding root certificate: must contain an ExtendedKeyUsage extension; and must not include the anyExtendedKeyUsage; and, must not include both the id-kp-serverAuth and id-kp-emailProtection in KeyPurposeId in the same certificate at the same time. Subscriber certificates shall also include, ExtendedKeyUsage extension, however the anyExtendedKeyUsage KeyPurposeId shall not appear, and id-kp-serverAuth and id-kp-emailProtection shall not be included as KeyPurposeId at once for the same certificate. The subjectAltName extension in the subscriber certificate is populated in accordance with RFC 5280. For all web server certificates, the SubjectAltName extension is populated with the authenticated value of either the domain name or public IP Adress(\*) in the Common Name field of the subject DN. The SubjectAltName extension may contain additional authenticated domain names or public iPAddresses. For internationalized domain names, the value encoded by Punycode algorithm shall be listed in the SubjectAltName extension as a Punycode(A-label) value. (\*): The use of IP addresses is permitted only for the OV certificate. As defined in Section 7.1.2.9 of the BR, the order and encoded values of Basic Certificate Fields are byte-for-byte identical between the subscriber certificate and its Precertificate. For Certificate Extensions, the order, criticality, and encoded values are byte-for-byte identical, except extension for Certificate Transparency as indicated below. | Certificate | extension for Certificate Transparency | Type | Value | |----|----|----|----| | subscriber certificate | SignedCertificateTimestampList (extnId :== 1.3.6.1.4.1.11129.2.4.2, critical :== FALSE) | OCTET STRING | Signed CertificateTimestamp List | | Precertificate | Precertificate Poison (extnId :== 1.3.6.1.4.1.11129.2.4.3, critical :== TRUE) | OCTET STRING | ASN.1 NULL value (to be "0500" represented in hex‐encoded bytes) as specified in RFC 6962, Section 3.1 | ### 7.1.3 Algorithm object identifiers #### 7.1.3.1 SubjectPublicKeyInfo | Type | algorithm identifier | OID | |---------|----------------------|----------------------| | RSA key | rsaEncryption | 1.2.840.113549.1.1.1 | #### 7.1.3.2 signatureAlgorithm | Type | algorithm identifier | OID | |-----------------|-------------------------|-----------------------| | SHA256 with RSA | sha256WithRSAEncryption | 1.2.840.113549.1.1.11 | This Certification Authority shall not issue any subscriber certificates using the SHA-1 hash algorithm. Matters regarding the certificate profile of the Certification Authority Certificates and subscriber certificates are set forth in Appendix B. ### 7.1.4 Name forms The Certification Authority uses distinguished names that are composed of standard attribute types, such as those identified in RFC 5280. The content of the Certificate Issuer Distinguished Name field must match the Subject DN of the Issuer CA to support name chaining as specified in section 4.1.2.4 of RFC 5280. Certificates are populated with the Issuer Name and Subject Distinguished Name required under Section 3.1.1. Subject attributes must not contain only metadata such as '.', '‐', and ’ ’ (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. The subjectAltName extension in the EV Certificates must be present and contain at least one FQDN, and the FQDN included in the certificate shall be validated based on section 3.2.2.4 of this CP/CPS. Also, Common Name and the subjectAltName in certificates cannot contain internal names. The subjectAltName extension in the OV Certificates must be present and contain at least one FQDN or iPAddress, and those included in the certificate shall be validated based on section 3.2.2.4 or 3.2.2.5 of this CP/CPS. Also, Common Name and the subjectAltName in certificates cannot contain internal names or reserved IP addresses. Matters regarding the certificates profile of the Certification Authority Certificates and subscriber certificates are set forth in Appendix B. ### 7.1.5 Name constraints Not applicable. ### 7.1.6 Certificate policy object identifier When the Certification Authority issues a certificate containing one or more than one of the following policy identifiers, it asserts that the certificate is managed in accordance with the policy that is identified herein. | Name of the Policy | OID | |:--:|:--:| | Cybertrust Japan iTrust EV SSL/TLS Server Certificate (Policy for EV Certificates issued in accordance this CP/CPS) | 1.2.392.200081.1.22.1 | | Cybertrust Japan iTrust SSL/TLS Server Certificate Policy (Policy for OV Certificates issued in accordance this CP/CPS) | 1.2.392.200081.1.23.1 | | CA/Browser Forum EV Guidelines EV Certificate Policy | 2.23.140.1.1 | | CA/Browser Forum BR OV Certificate Policy | 2.23.140.1.2.2 | | SECOM Passport for Web EV CA CP | 1.2.392.200091.100.721.1 | ### 7.1.7 Usage of Policy Constraints extension Not applicable. ### 7.1.8 Policy qualifiers syntax and semantics Matters regarding the certificate profile of the Certification Authority Certificates and subscriber certificates are set forth in Appendix B. ### 7.1.9 Processing semantics for the critical Certificate Policies extension Not applicable. ## 7.2 CRL profile For revoked Subscriber Certificates, the CRLReason indicated MUST NOT be unspecified (0) or certificateHold (6). If the reason for revocation is unspecified, the Certification Authority MUST omit reasonCode extension. If the revoked subscriber certificates include a reasonCode extension, must include one of following reason codes which is the most appropriate reason for revocation of the certificate listed in RFC5280, section 5.3.1. The Certification Authority provides certificate subscribers, in the subscriber agreement, the options and explanation about when to choose each option on the revocation reason. 1. keyCompromise (1) 2. affiliationChanged (3) 3. superseded (4) 4. cessationOfOperation (5) 5. privilegeWithdrawn (9) ### 7.2.1 Version number(s) The Certification Authority issues version 2 CRLs that conform to RFC 5280. Matters regarding the profile of CRL issued by this Certification Authority are set forth in Appendix B of this CP/CPS. ### 7.2.2 CRL and CRL entry extensions Matters regarding the profile of CRL issued by this Certification Authority are set forth in Appendix B of this CP/CPS. ## 7.3 OCSP profile Issuer Certification Authority shall operate an OCSP service in accordance with RFC 6960. For publicly-trusted TLS, the CRLReason indicated contains a value permitted for CRLs, as specified in Section 7.2 of this CP/CPS. ### 7.3.1 Version number(s) OCSP response conform to version 1 as specified in RFC 6960. ### 7.3.2 OCSP extensions The singleExtensions of an OCSP response does not contain the reasonCode (OID 2.5.29.21) CRL entry extension. -------------------------------------------- # 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS ## 8.1 Frequency or circumstances of assessment The Certification Authority is verified by the qualified outside auditor with the appropriate WebTrust Principles and Criteria formulated by CPA Canada at the times CTJPA deemed necessary or at least annual basis. ## 8.2 Identity/qualifications of assessor The qualified auditor performing the external audit on the Certification Authority shall be independent from the Certification Authority. ## 8.3 Assessor's relationship to assessed entity The auditor shall be, as a rule, a party that is independent from the operations of the Certification Authority and capable of maintaining neutrality. ## 8.4 Topics covered by assessment The topics covered by the audit shall be the scope set forth in the programs of the WebTrust Principles and Criteria. ## 8.5 Actions taken as a result of deficiency Identified matters that are discovered in the verification are reported to CTJ PA, the Certification Authority Supervisor, the Issuing Authority Manager, and the Registration Authority Manager. When the auditor, CTJ PA, or the Certification Authority Supervisor determines that corrective action is required, corrective action shall be taken under the control of CTJ PA. ## 8.6 Communication of results Validation results of the WebTrust Principles and Criteria are published according to the provisions of the respective requirements. The results of each audit are reported to the CTJPA and to any third party entities which are entitled by law, regulation, or agreement to receive the audit results. Cybertrust’s audit reports can be found at: https://www.cybertrust.co.jp/ssl/. On an annual basis and within three months of completion, Cybertrust will submit relevant audit compliance reports to SECOM Trust Systems operating the Root CA. ## 8.7 Self audit On at least a quarterly basis, the Certification Authority performs regular internal audits against a randomly selected sample of at least three percent of Certificates issued during the targeted audit period. The Certification Authority uses a Linting process to verify the technical accuracy of Certificates within the selected sample set independently of previous linting performed on the same Certificates. -------------------------------------- # 9. OTHER BUSINESS AND LEGAL MATTERS ## 9.1 Fees ### 9.1.1 Certificate issuance or renewal fees The fees and payment method concerning the certificates issued by the Certification Authority are notified so that a subscriber can properly verify the same such as by posting on Cybertrust's website or submitting a quote. If there is any discrepancy between the description on Cybertrust's website and the description in the quote separately submitted by Cybertrust, the descriptions of the quote shall prevail. Moreover, if the Certification Authority is requested by a subscriber to reissue a certificate based on the following reasons, the Certification Authority shall reissue a certificate that is valid for the remaining period, free of charge, as long as such request is made within thirty (30) days after the issuance of the original certificate in principle. The original certificate shall basically be revoked: 1. the key pair generated during the application was unintentionally erased or damaged; 2. the original certificate cannot be used due to server replacement; 3. the password required for downloading a certificate based on “4.4.1 Conduct constituting certificate acceptance" of this CP/CPS is lost; or 4. the Certification Authority otherwise deems it appropriate. ### 9.1.2 Certificate access fees No stipulation. ### 9.1.3 Revocation or status information access fees No stipulation. ### 9.1.4 Fees for other services No stipulation. ### 9.1.5 Refund policy Cybertrust shall separately stipulate refund policy in the Subscriber Agreement. ## 9.2 Financial responsibility ### 9.2.1 Insurance coverage Cybertrust shall maintain a sufficient financial foundation that is required for observing the subject matter set forth in this CP/CPS and for operating the Certification Authority. Cybertrust shall also take out appropriate insurance for covering its indemnity liability. In the case of the EV Certificate, in addition to the above, the Certification Authority SHALL maintain insurance that meets the following requirements stipulated in Section 9.2.1. of the EV Guidelines: 1. Commercial General Liability insurance (occurrence form) with policy limits of at least two million US dollars in coverage; and 2. Professional Liability/Errors and Omissions insurance, with policy limits of at least five million US dollars in coverage, and including coverage for: - claims for damages arising out of an act, error, or omission, unintentional breach of contract, or neglect in issuing or maintaining EV Certificates, and; - claims for damages arising out of infringement of the proprietary rights of any third party (excluding copyright, and trademark infringement), and invasion of privacy and advertising injury. Such insurance must be with a company 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 the members of which are so rated). The Certification Authority does not apply the self‐insure allowed in EV Guideline. ### 9.2.2 Other assets No stipulation. ### 9.2.3 Insurance or warranty coverage for end-entities No stipulation. ## 9.3 Confidentiality of business information ### 9.3.1 Scope of confidential information Cybertrust shall handle the following information as confidential information (the "Confidential Information"): 1. application information from a subscriber; 2. information set forth in "9.4.2 Information treated as private" of this CP/CPS; 3. inquiry information received from a subscriber, a relying party, or other third parties; and 4. information relating to the security of the Certification Authority. ### 9.3.2 Information not within the scope of confidential information Of the information held by Cybertrust, the following information shall be excluded from the scope of Confidential Information: 1. information set forth in “2.2 Publication of certification information" of this CP/CPS as information to be published; 2. subscriber's certificate; 3. information that became public knowledge for reasons other than the negligence on the part of Cybertrust; 4. information that became public knowledge without any restriction of confidentiality from a party other than Cybertrust; and 5. information for which a subscriber agreed in advance to the effect of being disclosed or provided. ### 9.3.3 Responsibility to protect confidential information Cybertrust shall implement measures for preventing the divulgence of the Confidential Information. Cybertrust shall not use the Confidential Information except when it is necessary for performing its operations; provided, however, that, when disclosure of the Confidential Information is demanded in the course of judicial, administrative or other legal proceedings; or when the Confidential Information is to be disclosed to a party such as a financial advisor or a potential acquirer/acquiree that executed a confidentiality agreement with Cybertrust in relation to an acquisition/merger and/or a party such as an attorney, certified public accountant, tax attorney or the like that legally bears the confidentiality obligation, or when Cybertrust obtains the prior approval of the subscriber disclosing the Confidential Information, Cybertrust may disclose the Confidential Information to the party requesting disclosure of such Confidential Information. In the foregoing case, the party receiving the disclosure of the requested Confidential Information must not disclose or divulge such information to any third party regardless of the method thereof. The handling of protection of personal information shall be set forth in “9.4 Privacy of personal information" of this CP/CPS. ## 9.4 Privacy of personal information ### 9.4.1 Privacy plan Handling of personal information held by Cybertrust shall be set forth in the Privacy Policy that is published on Cybertrust' website (https://www.cybertrust.co.jp/corporate/privacy-policy.html). ### 9.4.2 Information treated as private Cybertrust shall handle, as personal information, any personally identifiable information that is included in the issuance of certificates and revocation requests, inquiries, or the like. Note that the Certification Authorities shall treat data, including IP addresses, from OCSP requests by the Relying Parties as personal data, in accordance with the General Data Protection Regulation (“GDPR”), Regulation (EU) 2016/679. Cybertrust Japan does not use these data in server logs to build profiles or identify individuals. The server logs are used for operational purposes only and are normally kept at least until next audit. After that, the server logs are deleted in accordance with Cybertrust's internal rules. ### 9.4.3 Information not deemed private Cybertrust shall not deem, as personal information, any information other than the information set forth in "9.4.2 Information treated as private" of this CP/CPS. ### 9.4.4 Responsibility to protect private information The responsibility of protecting the personal information held by Cybertrust shall be as set forth in "9.4.1 Privacy plan " of this CP/CPS. ### 9.4.5 Notice and consent to use private information Based on a subscriber's issuance application or revocation request, it shall be deemed that Cybertrust has obtained the consent of the subscriber with regard to the Certification Authority using the personal information of that subscriber for performing its certificate issuance/revocation operations that are scheduled in this CP/CPS and the Certification Authority conducting an audit. Moreover, Cybertrust shall not use the personal information acquired from a subscriber for any purpose other than performing the certification operations; save for the cases set forth in "9.4.6 Disclosure pursuant to judicial or administrative process" of this CP/CPS. ### 9.4.6 Disclosure pursuant to judicial or administrative process When disclosure of personal information handled by Cybertrust is demanded in the course of judicial, administrative, or other legal proceedings, Cybertrust may disclose such personal information. ### 9.4.7 Other information disclosure circumstances When Cybertrust is to outsource a part of its operations, there may be cases where Cybertrust needs to disclose the Confidential Information and personal information to the outsourcee. In the foregoing case, Cybertrust shall include a provision in the service contract which imposes a confidentiality obligation on the outsourcee for maintaining the confidentiality of the Confidential Information and personal information. ## 9.5 Intellectual property rights Unless separately agreed herein, all Intellectual Property Rights pertaining to the following information shall belong to Cybertrust or Cybertrust's supplier or licensor related to the Certification Authority service: 1. certificates issued by the Certification Authority and certificate revocation information; 2. this CP/CPS and related documents; 3. public key and private key of the Certification Authority; and 4. hardware and software leased by the Certification Authority. ## 9.6 Representations and warranties The representations and warranties of the Issuing Authority, the Registration Authority, subscribers and relying parties are prescribed below. Excluding the representations and warranties of the Issuing Authority, the Registration Authority, subscribers and relying parties that are expressly prescribed in “9.6 Representations and warranties" of this CP/CPS, the respective parties mutually verify that they shall not make any express or implied representations or warranties. ### 9.6.1 CA representations and warranties When issuing a Certificate, Cybertrust represents and warrants that it bears the following obligations: 1. Right to Use Domain Name or IP Address The Certification Authority implemented and followed 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, and accurately describes the procedure in this CP/CPS. 2. Authorization for Certificate The Certification Authority implemented and followed a procedure 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, and accurately describes the procedure in this CP/CPS. 3. Accuracy of Information The Certification Authority implemented and followed a procedure for verifying the accuracy of all of the information contained in the Certificate, and accurately describes the procedure in this CP/CPS 4. Identity of Applicant The Certification Authority implemented and followed a procedure to verify the identity of the Applicant in accordance with Section 3.2 and Section 7.1.2 of the BR, and accurately describes the procedure in this CP/CPS. In the case of the EV Certificate, the Certification Authority has confirmed that, as of the date the certificate was issued, the legal name 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 of Incorporation or Registration. 5. Subscriber Agreement That the Subscriber has been provided with the most current version of the Subscriber Agreement, the applicable Subscriber Agreement is the Subscriber Agreement that was accepted when the Certificate was issued, and the Subscriber and Certification Authority are parties to a legally valid and enforceable Subscriber Agreement that satisfies these Requirements, and both parties agree upon Subscriber Agreement. 6. Status That the Certification Authority maintains for 24 hours a day, 365days a year publicly‐accessible Repository with current information regarding the status (valid or revoked) of all unexpired Certificates. 7. Revocation That the Certification Authority revokes the Certificate for any of the reasons specified in this CP/CPS, Subscriber Agreement, or relevant Requirements. 8. Legal Existence In the case of the EV Certificate, the Certification Authority has confirmed with the Incorporating or Registration Agency in the Subject’s Jurisdiction of Incorporation or Registration that, as of the date the certificate was issued, the Subject named in the certificate legally exists as a valid organization or entity in the Jurisdiction of Incorporation or Registration. 9. Cybertrust also represents and warrants following. - to comply with Relevant Requirements and this CP/CPS. - to safely control the CA private key. - to monitor and operate the system. ### 9.6.2 RA representations and warranties Cybertrust represents and warrants that it bears the following obligations upon performing operations as the Registration Authority: 1. perform screening of subscribers based on this CP/CPS; 2. properly handle certificate issuance applications and revocation requests to the Issuing Authority; and 3. accept inquiries ("1.5.2 Contact person" of this CP/CPS). ### 9.6.3 Subscriber representations and warranties A subscriber represents and warrants that it bears the following obligations. 1. Accuracy of Information An obligation and warranty to provide correct and accurate information at all times upon applying for the issuance of a certificate and when requested by the Certification Authority. 2. Protection of Private Key An obligation and warranty by the Applicant to take all reasonable measures to assure control of, keep confidential, and properly protect at all times the Private Key that corresponds to the Public Key to be included in the Certificate(s) (and any associated activation data or device, e.g. password or token). 3. Acceptance of Certificate An obligation and warranty to refrain from installing a Certificate in a server and using the certificate until the accuracy of the information included in the Certificate is confirmed. 4. Use of Certificate An obligation and warranty to use the certificate according to the law and regulations and the Subscriber Agreement. 5. Reporting and Revocation An obligation and warranty to 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 an obligation and warranty to promptly request revocation of the Certificate, and cease using it, if any information in the Certificate is or becomes incorrect or inaccurate. 6. Termination of Use of Certificate An obligation and warranty to promptly cease all use of the Private Key corresponding to the Public Key contained in certificate upon revocation of that Certificate for reasons of Key Compromise. 7. Responsiveness An obligation and warranty to respond to the Certification Authority's instruction within a specified period upon the occurrence of an event set forth in the Subscriber Agreement such as Key Compromise or Certificate misuse. 8. Acknowledgment and Acceptance An acknowledgment and acceptance that the Certification Authority is entitled to revoke the certificate immediately if the Applicant violates the terms of the Subscriber Agreement or if revocation is required by this CP/CPS, the requirements set forth by the CA/Browser Forum or the requirements imposed on certificate authorities by the Application Software Supplier that includes the Root CA certificate in its application software. A subscriber also represents and warrants following; - provide additional information besides certificate requests (which includes but not limited to information or documentation related to services such as hosting service, SaaS(Software as a Service), DaaS(Desktop as a Service), Paas(Platform as a Service), IaaS(Infrastructure as a Service), and etc.(the "Specific Service")) when the Certification Authority deems necessary for the validation, - comply with appropriate usage of certificates and private keys, - refrain from using the certificate in websites that are contrary to public order and morals, - refrain from using any certificate containing only metadata such as '.', '‐', and ’ ’ (i.e. space) characters, and/or any other value indicates that the value is absent, incomplete, or not applicable, - immediately request revocation of the certificate to the Certification Authority upon the occurrence of an event set forth in the Subscriber Agreement, - refrain from using an expired certificate or a revoked certificate, - observe applicable laws and regulations, and - respond to all the inquiries on information of their Certificate requests or the status of Certificate use which the Certification Authority asks to the Subscribers. ### 9.6.4 Relying party representations and warranties A relying party represents and warrants that it bears the following obligations: 1. confirm that the certificates are being used for the usage set forth in "1.4.1 Appropriate certificate uses" of this CP/CPS; 2. confirm the effective period and entries of certificates issued by the Certification Authority; 3. verify the digital signature and verify the issuer of the certificate; 4. confirm whether the certificate has been revoked based on CRL or OCSP; and 5. bear legal liability for situations arising from the default of obligations prescribed in this paragraph. ### 9.6.5 Representations and warranties of other participants No stipulation. ## 9.7 Disclaimers of warranties The Certification Authority shall not be liable for any damages excluding direct damages arising in relation to the warranties set forth in "9.6.1 CA representations and warranties" and "9.6.2 RA representations and warranties" of this CP/CPS. The Certification Authority shall not be liable in any way for the consequences resulting from a relying party trusting the certificates of the Certification Authority and subscribers based on its own judgment. ## 9.8 Limitations of liability Cybertrust shall not be liable in any way in the following cases in relation to the subject matter of "9.6.1 CA representations and warranties" and "9.6.2 RA representations and warranties" of this CP/CPS: 1. any damage that arises regardless of the Certification Authority observing the requirements specified in “1.1 Overview" of this CP/CPS, and legal regulations; 2. any damage that arises due to fraud, unauthorized use or negligence that is not attributable to Cybertrust; 3. damage that arises as a result of subscribers or relying parties neglecting to perform their respective obligations prescribed in “9.6 Representations and warranties" of this CP/CPS; 4. damage that arises as a result of the key pair of the certificate issued by the Certification Authority being divulged due to acts of a third party other than Cybertrust; 5. damage that arises as a result of the certificate infringing upon the copyright, trade secret or any other intellectual property right of the subscriber, a relying party or a third party; or 6. damage caused by improvement in the encryption algorithm decoding technology, based on hardware or software, exceeding current expectations. The total amount of damages to be borne by Cybertrust against subscribers and relying parties or other third parties with regard to any and all damages arising in relation to the application, approval, trust or any other use of the certificates of the Certification Authority shall not exceed 10,000,000 yen under no circumstances whatsoever (provided, however, that with respect to damages related to the EV Certificates, the Certification Authority may not, in accordance with the provisions of the EV Guidelines, limit its liability to be less than 2,000 USD for any damage suffered by a subscriber or a relying party per certificate if there are legal grounds for the damage suffered by the subscriber or the relying party, and such damage can be verified). This upper cap shall be applied to each certificate regardless of the number of digital signatures, number of transactions, or number of damages pertaining to the respective certificates, and shall be allocated in order from the claim that is made first. Among the damages arising from any default or breach of this CP/CPS, the Subscriber Agreement, or the Related Rules, the Certification Authority shall not be liable for any data loss, indirect damages including lost profits, consequential damages and punitive damages to the extent permitted under the governing law set forth in "9.14 Governing law" of the CP/CPS. ## 9.9 Indemnities ### 9.9.1 Indemnification by Subscribers and Relying Parties At the time that a subscriber or a relying party receives or uses a certificate issued by the Certification Authority, the subscriber or the relying party shall become liable to compensate for any damage suffered by Cybertrust due to claims made by a third party against Cybertrust or lawsuits or other legal measures initiated or implemented by a third party against Cybertrust resulting from any of the following acts conducted by the relying party, as well as become responsible for implementing measures so that Cybertrust does not suffer any more damage: 1. unauthorized use, falsification, or misrepresentation during the use of a certificate; 2. breach of this CP/CPS or the Subscriber Agreement; or 3. neglect by a subscriber to preserve the private key. The Certification Authority is not the subscriber's or relying party's agent, trustee or any other representative. ### 9.9.2 Indemnification by Cybertrust Cybertrust SHALL defend, indemnify, and hold harmless each Application Software Supplier for any claims, damages, and losses suffered by such Application Software Supplier related to a certificate issued by the Certification Authority, regardless of the cause of action or legal theory involved. This does not apply, however, to any claim, damages, or loss suffered by such Application Software Supplier where such claim, damage, or loss was directly caused by such Application Software Supplier’s software as follows: 1. such Application Software Supplier’s software displays a certificate as not trustworthy while the certificate remains valid; or 2. such Application Software Supplier’s software fails to validate or ignores the revocation status and displays a certificate as trustworthy, even though the certificate is expired or revoked and the revocation status is provided and available online by the Certification Authority. ## 9.10 Term and termination ### 9.10.1 Term This CP/CPS shall come into effect when approved by CTJ PA. This CP/CPS is not invalidated before the time set forth in “9.10.2 Termination" of this CP/CPS. ### 9.10.2 Termination This CP/CPS shall become invalid at the time that the Certification Authority terminates its operations, excluding the cases prescribed in “9.10.3 Effect of termination and survival" of this CP/CPS. ### 9.10.3 Effect of termination and survival The provisions of 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 9.9, 9.10.2, 9.10.3, 9.13, 9.14, 9.15, and 9.16 of this CP/CPS shall continue to remain in force even after the termination of this CP/CPS. ## 9.11 Individual notices and communications with participants When Cybertrust is to notify subscribers individually, such notice shall be deemed to have been made when a written notice is hand-delivered, delivered via registered mail with verification of receipt, or sent via email. Moreover, notices from subscribers to Cybertrust shall all be made in writing, and such notices shall be deemed to have arrived when such notices are sent and received by Cybertrust. ## 9.12 Amendments ### 9.12.1 Procedure for amendment The Certification Authority shall review and update this CP/CPS at least once in 366 days, incrementing the version number and adding a dated changelog entry. This CP/CPS may be amended if needed based on CTJPA’s instruction. CTJ PA shall approve the amendment after obtaining the evaluation of the Certification Authority Staff or the evaluation of outside professionals such as attorneys or other experts. ### 9.12.2 Notification mechanism and period After CTJ PA approves the amendment of this CP/CPS, Cybertrust shall take measures to post the CP/CPS before amendment and the CP/CPS after amendment on the website so that the subscribers and relying parties can verify the amended contents. The amended CP/CPS shall come into force at the time that is separately set forth by CTJ PA unless the withdrawal of the amended CP/CPS is publicly announced by Cybertrust. If a subscriber does not request the revocation of its digital certificate within fifteen (15) days after the effectuation thereof, it shall be deemed that the subscriber has accepted the amended CP/CPS. ### 9.12.3 Circumstances under which OID must be changed CTJ PA is responsible for deciding if the OID updates are required correspondingly to this CP/CPS change. ## 9.13 Dispute resolution provisions All disputes arising in relation to the certificates issued by the Certification Authorities to which this CP/CPS applies shall be submitted to the Tokyo District Court as the competent court of agreed jurisdiction in the first instance. With regard to matters that are not set forth in this CP/CPS or when doubts arise with regard to this CP/CPS, the parties shall consult in good faith to resolve such matters. ## 9.14 Governing law This CP/CPS is construed in accordance with the laws of Japan, and the laws of Japan shall apply to any dispute pertaining to the certification operations based on this CP/CPS. ## 9.15 Compliance with applicable law This CP/CPS is subject to all applicable laws and regulations. ## 9.16 Miscellaneous provisions ### 9.16.1 Entire agreement Unless separately specified herein, the matters agreed in this CP/CPS supersede all other agreements unless this CP/CPS is amended or terminated. ### 9.16.2 Assignment When Cybertrust is to assign this service to a third party, this CP/CPS and the liabilities and other obligations set forth in them may be assigned to such third party. ### 9.16.3 Severability Even if any provision of this CP/CPS is found to be invalid for one reason or another, the remaining provisions shall continue to remain in force. In the event of a conflict between applicable requirements of CA/Browser Forum and a law, regulation or government order of any jurisdiction in which Cybertrust operates or issues certificates, Cybertrust MAY modify any conflicting requirement of CA/Browser Forum to the minimum extent necessary to make the requirement valid and legal in the jurisdiction. This applies only to operations or certificate issuances that are subject to that law, regulation or government order. In such event, Cybertrust SHALL immediately (and prior to issuing a certificate under the modified requirement) include in this section of this CP/CPS a detailed reference to the law, regulation or government order requiring a modification of requirements of CA/Browser Forum and the specific modification to requirements of CA/Browser Forum implemented by Cybertrust. Cybertrust MUST also, prior to issuing a certificate under the modified requirement, notify the CA/Browser Forum of the relevant information newly added to this CP/CPS in accordance with the procedures specified in section 9.16.3 of the BR. ### 9.16.4 Enforcement (attorneys’ fees and waiver of rights) The Certification Authority may seek indemnification and attorneys' fees from a party for damages, losses, and expenses related to that party's conduct. The Certification Authority’s failure to enforce a provision of this CP/CPS does not waive the Certification Authority’s right to enforce the same provision later or right to enforce any other provision of this CP/CPS. To be effective, waivers must be in writing and signed by the Certification Authority. ### 9.16.5 Force Majeure In the event the performance of a part or all of the obligations under this CP/CPS is delayed because of calamities, court orders, labor disputes, or other reasons that are not attributable to the Certification Authorities, Cybertrust shall be exempted from the performance of its obligations under this CP/CPS during the delay period and shall not be liable in any way against a subscriber or a third party that trusted or used a certificate. ## 9.17 Other provisions No stipulation. ---------------------------------- # Appendix A: List of Definitions
Term Definition
Archive As used herein, the term "archive" refers to the process of storing expired certificates for a predetermined period.
Application Software Supplier A supplier of software or other relying-party application software that displays or uses the Certificates, incorporates Root Certificates, and adopts the CA/Browser Forum’s Requirements as all or part of its requirements for participation in a root store program.
Cryptographic Module Software, hardware, or a device configured from the combination of such software and hardware that is used for ensuring security in the generation, storage and use of private keys.
Suspension Measure for temporarily invalidating a certificate during the effective period of that certificate.
Key Size A bit number that represents the key size (number of digits), which is also a factor in deciding the cryptographic strength.
Key Pair A public key and a private key in public key cryptography. The two keys are unique in that one key cannot be derived from the other key.
Activation To cause a system or device to be usable. Activation requires activation data, and specifically includes a PIN and pass phrase.
Subscriber Agreement An agreement to be accepted by a subscriber to apply for and use a certificate. This CP/CPS constitute a part of the subscriber agreement.
Compromise A state where the confidentiality or integrity of information that is incidental to the private key and the private key is lost.
Public Key One key of the key pair in public key cryptography that is notified to and used by the other party (communication partner, etc.).
Sole Proprietor

A person who meets all the following conditions.

  • A person who is 18 years old or older and runs a business as an individual

  • A person who notified the country or municipality of the start of a business and actually runs the business

  • A person who indicates the shop name of the business on the business name registration, business commencement form, and tax declaration

Mixed characters String that contains two or more types of characters, such as alphanumeric characters and symbols.
Revocation Measure for invalidating a certificate even during the effective period of that certificate.
Certificate Management System A system used by a CA or Delegated Third Party to process, approve issuance of, or store certificates or certificate status information, including the database, database server, and storage.
Certificate Revocation List Abbreviated as "CRL" in this CP/CPS. CRL is a list of revoked certificates. A Certification Authority publishes CRL so that the relying parties can verify the validity of certificates.
Certificate Systems The system used by a CA or Delegated Third Party in providing identity verification, registration and enrollment, certificate approval, issuance, validity status, support, and other PKI‐related services.
Certification Operations Series of operations that are performed during the life cycle controls of certificates. Including, but not limited to, operations of accepting issuance/revocation requests, screening operations, issuance/revocation/discarding operations, operations of responding to inquiries, billing operations, and system maintenance and management operations of Certification Authorities.
Backup Site A facility that is separate from the main site for storing important assets of Certification Authorities required for certificate issuance and revocation to ensure business continuity during disasters.
Private Key One key of the key pair in public key cryptography that is kept private from third parties other than a subscriber.
Main Site A facility equipped with assets of Certification Authorities required for certificate issuance and revocation.
Escrow As used herein, the term "escrow" refers to the processing of registering and storing a private key or a public key at a third party.
Repository A website or system for posting public information such as this CP/CPS and CRL.
Linting A process in which the content of digitally signed data such as a Precertificate, Certificates, CRL, or OCSP Response, or data-to-be-signed object such as a `tbsCertificate` (as described in RFC 5280, Section 4.1.1.1) is checked for conformance with the profiles and requirements defined in the BR.
Root CA A certification authority above the Certification Authority. It issues certificates of the Certification Authority.
ACME Abbreviation for "Automated Certificate Management Environment" and it is a standard protocol for automating the processes of domain names verification, installation, and management for X.509 certificates.
ALPN Abbreviation for "Application-Layer Protocol Negotiation" and it is an extended function of TLS.
Apple Root Certificate Program The requirements which Apple imposes certification authorities to have their certificates trusted and included in Apple Root Program.
Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (BR) Requirements for issuing publicly-trusted SSL/TLS Server certificates which were formulated by the CA/Browser Forum.
CA/Browser Forum Organization that consists of the Certification Authorities that issue publicly trusted certificates for SSL/TLS communications and the companies that develop applications such as browsers. It creates standards for the certificates. The website of the organization is https://cabforum.org/.
Certificate Transparency A scheme standardized in RFC6962 for promptly discovering and detecting fraudulent certificates.
Chrome Root Program Policy The requirements which Google imposes certification authorities to have their certificates trusted and included in Google Root Program.
DBA/Tradename Indicates a common name, trade name, shop name, trademark, etc. other than the legal name of an organization.
Distinguished Name An identifier set forth in the X.500 recommendation formulated by ITU-T. Configured from attribute information such as a common name, organization name, and country name.
DNS CAA Email Contact The email address defined in APPENDIX A.1.1 of BR.
DNS CAA Phone Contact The phone number defined in APPENDIX A.1.2 of BR.
DNS Certification Authority Authorization Resource Record (CAA Record) One of the DNS records defined in RFC8659 which aims to clarify the certification authority to issue the server certificate to a domain name and prevent the issuance of unintended certificates.
DNS TXT Record Email Contact The email address defined in APPENDIX A.2.1 of BR.
DNS TXT Record Phone Contact The phone number defined in APPENDIX A.2.2 of BR.
Extended Validation Certificate (EV Certificate) EV certificates that are issued based on the "Guidelines For The Issuance And Management Of Extended Validation Certificates" set forth by the CA/Browser Forum and are used for the authentication of servers in SSL/TLS communication.
FIPS 140-2 FIPS (Federal Information Processing Standards Publication 140) is a U.S. federal standard that prescribes the specifications of security requirements in a cryptographic module, and the latest version of this standard is 2. With this standard, the security requirements are classified as the levels of 1 (lowest) to 4 (highest).
Fully-Qualified Domain Name (FQDN) A domain name to which a subdomain name and a host name are added and is included in a certificate.
Guidelines for the Issuance and Management of Extended Validation Certificates (EV Guidelines) Requirements for issuing EV certificates, which were formulated by the CA/Browser Forum.
IETF PKIX Working Group Internet Engineering Task Force (IETF) is an organization that standardizes technologies used for the Internet, and the PKIX Working Group of IETF set forth in RFC 3647.
IP Address 32-bit or 128-bit label that is assigned to a device that uses the Internet Protocol for communications.
IP Address Contact A person or organization authorized to control the method of using one or more IP addresses that are registered in an IP address registration authority.
IP Address Registration Authority Internet Assigned Numbers Authority (IANA) or Regional Internet Registry (RIPE, APNIC, ARIN, AfriNIC, LACNIC).
ITU-T Telecommunications Standardization Sector of the International Telecommunication Union.
Program Requirements - Microsoft Trusted Root Program The requirements which Microsoft imposes certification authorities to have their certificates trusted and included in Microsoft Root Program.
Mozilla Root Store Policy The requirements which Mozilla imposes certification authorities to have their certificates trusted and included in Mozilla Root Program.
Multi-Perspective Issuance Corroboration

Refers to the process of obtaining same validation results as a domain validation and/or CAA check, confirmed using multiple Network Perspectives before Certificate issuance. This process can protect against Border Gateway Protocol (BGP) attacks or hijacks and improve the reliability of the validation results.

Network Perspective refers to a system that operates on a network to obtain the information necessary for some validations. The Network Perspective used as the primary system is called the Primary Network Perspective, while the Network Perspective operating from a remote location is referred to as the remote Network Perspective.

Name Constraints Registration of the Key Usage and Name Constraint extensions in a certificate of a certification authority to restrict the issue of a certificate.
Network and Certificate System Security Requirements The requirements developed by CA/Browser Forum for the security on network of publicly trusted certificate and the security of CA systems.
OCSP Abbreviation of "Online Certificate Status Protocol" and is a communication protocol for providing certificate revocation information. A Certification Authority operates an OCSP Responder, in addition to publicly disclosing the CRL, so that a relying party can verify the validity of a certificate.
Organizational Validation Certificates (OV Certificate) OV certificates that are issued based on the “Baseline Requirements for the Issuance and Management of Publicly Trusted TLS Server Certificates” as set forth by the CA/Browser Forum and are used for the authentication of servers in SSL/TLS communication.
Punycode Punycode is a method, defined in RFC 3492, designed to encode an Internationalized Domain Names (IDN). The value transformed its Unicode string into an ASCII characters with ACE prefix "xn--" added in accordance with Punycode encoding method shall be called "A-label".
Precertificate Certificates explained in RFC6962 which is a document on Certificate Transparency.
RSA Public key cryptography developed by Rivest, Shamir, and Adelman.
RFC7231 The document named "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content" defining semantics of HTTP/1.1 message which is set forth by the IETF PKIX Working Group.
RFC7538 The document named "The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)" defining the additional Hypertext Transfer Protocol (HTTP) status code 308 (Permanent Redirect) which is set forth by the IETF PKIX Working Group.
SHA1/SHA2 A hash function used in digital signatures, etc. A hash function is used for reducing data into a given length based on mathematical operations, and makes it infeasible to calculate the same output value from two different input values. It is also infeasible to inverse the input value from the output value.
SSL/TLS A protocol for encrypting and sending/receiving information on the Internet which was developed by Netscape Communications. TLS is an improvement of SSL 3.0.
WebTrust Principles and Criteria Audit standards established by CPA Canada to evaluate the appropriateness and effectiveness of certification authority operations.
X.500 International standard of distribution directory services to be provided on a network standardized by ITU-T.
X.509 International standard of digital certificates standardized by ITU-T.
------------------------------------- # Appendix B: Profile of Certificate Cybertrust Japan SureServer EV CA G3 Intermediate CA Certificate (Validity Period: December 13, 2023 to May 29, 2029) (Basic Certificate Fields)
version value
Version Version of the encoded certificate

type:INTEGER

2 (Ver.3)
serialNumber value
CertificateSerialNumber Serial number of certificate

type:INTEGER

46157929531853354100488418937468587687 (0x22b9b1a12d91f181ad7a7b6dbeb38ea7)
signature value
AlgorithmIdentifier The identifier for the signature algorithm used by the CA to sign this certificate

algorithm

Object ID for the signature algorithm

type:OID

1.2.840.113549.1.1.11 (sha256WithRSAEncryption)

parameters

Parameters of signature algorithm

type:NULL

NULL
issuer value
countryName Country name attribute of certificate issuer

type

Object ID for the country name

type:OID

2.5.4.6

value

Value of country name

type:PrintableString

JP
organizationName Organization name attribute of certificate issuer

type

Object ID for organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString

SECOM Trust Systems CO.,LTD.
organizationalUnitName Organizational unit name attribute of certificate issuer

type

Object ID for organizational unit name

type:OID

2.5.4.11

value

Value of organizational unit name

type:PrintableString

Security Communication RootCA2
validity value
Validity Validity period of the certificate

notBefore

The date on which the certificate validity period begins

type:UTCTime

231213062845Z

(December 13, 2023 15:28:45 JST)

notAfter

The date on which the certificate validity period ends

type:UTCTime

290529050039Z

(May 29, 2029 14:00:39 JST)

subject value
countryName Country name attribute of certificate subject

type

Object ID for the country name

type:OID

2.5.4.6

value

Value of country name

type:PrintableString

JP
organizationName Organization name attribute of certificate subject

type

Object ID for organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString

Cybertrust Japan Co., Ltd.
commonName Common name attribute of certificate subject

type

Object ID for common name

type:OID

2.5.4.3

value

Value of common name

type:PrintableString

Cybertrust Japan SureServer EV CA G3
subjectPublicKeyInfo value
SubjectPublicKeyInfo Subject’s public key information

AlgorithmIdentifier

The identifier for cryptographic algorithm

algorithm

Object ID for the cryptographic algorithm

type:OID

1.2.840.113549.1.1.1 (rsaEncryption)

parameters

Parameters of cryptographic algorithm

type:NULL

NULL

subjectPublicKey

Value of public key

type:BIT STRING

*Public key of 2048 bit size
(Certificate Extensions)
subjectKeyIdentifier (extnId :== 2.5.29.14, critical :== FALSE) value
SubjectKeyIdentifier Information of Subject Key Identifier

KeyIdentifier

The identifier for public key

type:OCTET STRING

82:6C:75:5D:53:F5:45:69:BC:25:2D:A4:4C:89:E6:B2:B7:41:87:A3
authorityKeyIdentifier (extnId :== 2.5.29.35, critical :== FALSE) value
AuthorityKeyIdentifier Authority Key Identifier

KeyIdentifier

The identifier for public key
type:OCTET STRING 0A:85:A9:77:65:05:98:7C:40:81:F8:0F:97:2C:38:F1:0A:EC:3C:CF
basicConstraints (extnId :== 2.5.29.19, critical :== TRUE) value
BasicConstraints Basic Constraints

cA

The flag to determine whether the supplied certificate is associated with a CA or an end entity

type:BOOLEAN

TRUE

pathLenConstraint

Path length constraint

type:INTEGER

0
keyUsage (extnId :== 2.5.29.15, critical :== TRUE) value
KeyUsage Key Usage

type:BIT STRING

00000110 (0x06)

(keyCertSign, cRLSign)

cRLDistributionPoints (extnId :== 2.5.29.31, critical :== FALSE) value
CRLDistributionPoints CRL Distribution Point

DistributionPoint

CRL Distribution Point

uniformResourceIdentifier

URI of CRL Distribution Point

type:IA5String

http://repository.secomtrust.net/SC-Root2/SCRoot2CRL.crl
certificatePolicies (extnId :== 2.5.29.32, critical :== FALSE) value
PolicyInformation Information of the Policy

policyIdentifier

Object ID for the Policy

type:OID

2.23.140.1.1

PolicyInformation

Information of the Policy

policyIdentifier

Object ID for the Policy

type:OID

1.2.392.200091.100.721.1

policyQualifiers

Information of the policy qualifiers

PolicyQualifierID

Classification of the policy qualifiers

type:OID

1.3.6.1.5.5.7.2.1 (CPSuri)

Qualifier

URI of CPS is published

type:IA5String

https://repository.secomtrust.net/SC-Root2/
authorityInfoAccess (extnId :== 1.3.6.1.5.5.7.1.1, critical :== FALSE) value
AuthorityInfoAccess Authority Information Access

AccessDescription

Online Certificate Status Protocol

accessMethod

Access method

type:OID

1.3.6.1.5.5.7.48.1 (ocsp)

accessLocation

Access location

type:IA5String

http://scrootca2.ocsp.secomtrust.net

AccessDescription

Issuer of the Authority

accessMethod

Access method

type:OID

1.3.6.1.5.5.7.48.2 (caIssuers)

accessLocation

Access location

type:IA5String

http://repository.secomtrust.net/SC-Root2/SCRoot2ca.cer
extKeyUsage (extnId :== 2.5.29.37, critical :== FALSE) value
ExtKeyUsage Extended Key Usage

KeyPurposeId

The purpose of the key contained in the certificate

type:OID

1.3.6.1.5.5.7.3.1 (serverAuth)

1.3.6.1.5.5.7.3.2 (clientAuth)

Cybertrust Japan SureServer EV CA G3 Intermediate CA Certificate (Validity Period: September 27, 2019 to May 29, 2029) (Basic Certificate Fields)
version value
Version Version of the encoded certificate

type:INTEGER

2 (Ver.3)
serialNumber value
CertificateSerialNumber Serial number of certificate

type:INTEGER

640569885012466767356 (0x22b9b16488bce695fc)
signature value
AlgorithmIdentifier The identifier for the signature algorithm used by the CA to sign this certificate

algorithm

Object ID for the signature algorithm

type:OID

1.2.840.113549.1.1.11 (sha256WithRSAEncryption)

parameters

Parameters of signature algorithm

type:NULL

NULL
issuer value
countryName Country name attribute of certificate issuer

type

Object ID for the country name

type:OID

2.5.4.6

value

Value of country name

type:PrintableString

JP
organizationName Organization name attribute of certificate issuer

type

Object ID for organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString

SECOM Trust Systems CO.,LTD.
organizationalUnitName Organizational unit name attribute of certificate issuer

type

Object ID for organizational unit name

type:OID

2.5.4.11

value

Value of organizational unit name

type:PrintableString

Security Communication RootCA2
validity value
Validity Validity period of the certificate

notBefore

The date on which the certificate validity period begins

type:UTCTime

190927020420Z

(September 27, 2019 11:04:20 JST)

notAfter

The date on which the certificate validity period ends

type:UTCTime

290529050039Z

(May 29, 2029 14:00:39 JST)

subject value
countryName Country name attribute of certificate subject

type

Object ID for the country name

type:OID

2.5.4.6

value

Value of country name

type:PrintableString

JP
organizationName Organization name attribute of certificate subject

type

Object ID for organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString

Cybertrust Japan Co., Ltd.
commonName Common name attribute of certificate subject

type

Object ID for common name

type:OID

2.5.4.3

value

Value of common name

type:PrintableString

Cybertrust Japan SureServer EV CA G3
subjectPublicKeyInfo value
SubjectPublicKeyInfo Subject’s public key information

AlgorithmIdentifier

The identifier for cryptographic algorithm

algorithm

Object ID for the cryptographic algorithm

type:OID

1.2.840.113549.1.1.1 (rsaEncryption)

parameters

Parameters of cryptographic algorithm

type:NULL

NULL

subjectPublicKey

Value of public key

type:BIT STRING

*Public key of 2048 bit size
(Certificate Extensions)
subjectKeyIdentifier (extnId :== 2.5.29.14, critical :== FALSE) value
SubjectKeyIdentifier Information of Subject Key Identifier

KeyIdentifier

The identifier for public key

type:OCTET STRING

82:6C:75:5D:53:F5:45:69:BC:25:2D:A4:4C:89:E6:B2:B7:41:87:A3
certificatePolicies (extnId :== 2.5.29.32, critical :== FALSE) value
PolicyInformation Information of the Policy

policyIdentifier

Object ID for the Policy
type:OID 1.2.392.200091.100.721.1

policyQualifiers

Information of the policy qualifiers

PolicyQualifierID

Classification of the policy qualifiers

type:OID

1.3.6.1.5.5.7.2.1 (CPSuri)

Qualifier

URI of CPS is published

type:IA5String

https://repository.secomtrust.net/SC-Root2/
cRLDistributionPoints (extnId :== 2.5.29.31, critical :== FALSE) value
CRLDistributionPoints CRL Distribution Point

DistributionPoint

CRL Distribution Point

uniformResourceIdentifier

URI of CRL Distribution Point

type:IA5String

http://repository.secomtrust.net/SC-Root2/SCRoot2CRL.crl
authorityInfoAccess (extnId :== 1.3.6.1.5.5.7.1.1, critical :== FALSE) value
AuthorityInfoAccess Authority Information Access

AccessDescription

Online Certificate Status Protocol

accessMethod

Access method

type:OID

1.3.6.1.5.5.7.48.1 (ocsp)

accessLocation

Access location

type:IA5String

http://scrootca2.ocsp.secomtrust.net

AccessDescription

Issuer of the Authority

accessMethod

Access method

type:OID

1.3.6.1.5.5.7.48.2 (caIssuers)

accessLocation

Access location

type:IA5String

http://repository.secomtrust.net/SC-Root2/SCRoot2ca.cer
authorityKeyIdentifier (extnId :== 2.5.29.35, critical :== FALSE) value
AuthorityKeyIdentifier Authority Key Identifier

KeyIdentifier

The identifier for public key

type:OCTET STRING

0A:85:A9:77:65:05:98:7C:40:81:F8:0F:97:2C:38:F1:0A:EC:3C:CF
keyUsage (extnId :== 2.5.29.15, critical :== TRUE) value
KeyUsage Key Usage

type:BIT STRING

00000110 (0x06)

(keyCertSign, cRLSign)

extKeyUsage (extnId :== 2.5.29.37, critical :== FALSE) value
ExtKeyUsage Extended Key Usage

KeyPurposeId

The purpose of the key contained in the certificate

type:OID

1.3.6.1.5.5.7.3.1 (serverAuth)

1.3.6.1.5.5.7.3.2 (clientAuth)

basicConstraints (extnId :== 2.5.29.19, critical :== TRUE) value
BasicConstraints Basic Constraints

cA

The flag to determine whether the supplied certificate is associated with a CA or an end entity

type:BOOLEAN

TRUE

pathLenConstraint

Path length constraint

type:INTEGER

0
Cybertrust Japan SureServer CA G4 Intermediate CA Certificate (Validity Period: December 13, 2023 to May 29, 2029) (Basic Certificate Fields)
version value
Version Version of the encoded certificate

type:INTEGER

2 (Ver.3)
serialNumber value
CertificateSerialNumber Serial number of certificate

type:INTEGER

46157929474543200098709732507498232300 (0x22b9b1a074641857f7a01332db42b9ec)
signature value
AlgorithmIdentifier The identifier for the signature algorithm used by the CA to sign this certificate

algorithm

Object ID for the signature algorithm

type:OID

1.2.840.113549.1.1.11 (sha256WithRSAEncryption)

parameters

Parameters of signature algorithm

type:NULL

NULL
issuer value
countryName Country name attribute of certificate issuer

type

Object ID for the country name

type:OID

2.5.4.6

value

Value of country name

type:PrintableString

JP
organizationName Organization name attribute of certificate issuer

type

Object ID for organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString

SECOM Trust Systems CO.,LTD.
organizationalUnitName Organizational unit name attribute of certificate issuer

type

Object ID for organizational unit name

type:OID

2.5.4.11

value

Value of organizational unit name

type:PrintableString

Security Communication RootCA2
validity value
Validity Validity period of the certificate

notBefore

The date on which the certificate validity period begins

type:UTCTime

231213055730Z

(December 13, 2023 14:57:30 JST)

notAfter

The date on which the certificate validity period ends

type:UTCTime

290529050039Z

(May 29, 2029 14:00:39 JST)

subject value
countryName Country name attribute of certificate subject

type

Object ID for the country name

type:OID

2.5.4.6

value

Value of country name

type:PrintableString

JP
organizationName Organization name attribute of certificate subject

type

Object ID for organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString

Cybertrust Japan Co., Ltd.
commonName Common name attribute of certificate subject

type

Object ID for common name

type:OID

2.5.4.3

value

Value of common name

type:PrintableString

Cybertrust Japan SureServer CA G4
subjectPublicKeyInfo value
SubjectPublicKeyInfo Subject’s public key information

AlgorithmIdentifier

The identifier for cryptographic algorithm

algorithm

Object ID for the cryptographic algorithm

type:OID

1.2.840.113549.1.1.1 (rsaEncryption)

parameters

Parameters of cryptographic algorithm

type:NULL

NULL

subjectPublicKey

Value of public key

type:BIT STRING

*Public key of 2048 bit size
(Certificate Extensions)
subjectKeyIdentifier (extnId :== 2.5.29.14, critical :== FALSE) value
SubjectKeyIdentifier Information of Subject Key Identifier

KeyIdentifier

The identifier for public key

type:OCTET STRING

62:A7:D2:DA:DE:85:B6:92:F1:85:BC:F6:E8:95:9D:75:A0:FA:4E:1F
authorityKeyIdentifier (extnId :== 2.5.29.35, critical :== FALSE) value
AuthorityKeyIdentifier Authority Key Identifier

KeyIdentifier

The identifier for public key
type:OCTET STRING 0A:85:A9:77:65:05:98:7C:40:81:F8:0F:97:2C:38:F1:0A:EC:3C:CF
basicConstraints (extnId :== 2.5.29.19, critical :== TRUE) value
BasicConstraints Basic Constraints

cA

The flag to determine whether the supplied certificate is associated with a CA or an end entity
type:BOOLEAN TRUE

pathLenConstraint

Path length constraint

type:INTEGER

0
keyUsage (extnId :== 2.5.29.15, critical :== TRUE) value
KeyUsage Key Usage

type:BIT STRING

00000110 (0x06)

(keyCertSign, cRLSign)

cRLDistributionPoints (extnId :== 2.5.29.31, critical :== FALSE) value
CRLDistributionPoints CRL Distribution Point

DistributionPoint

CRL Distribution Point

uniformResourceIdentifier

URI of CRL Distribution Point

type:IA5String

http://repository.secomtrust.net/SC-Root2/SCRoot2CRL.crl
certificatePolicies (extnId :== 2.5.29.32, critical :== FALSE) value
PolicyInformation Information of the Policy

policyIdentifier

Object ID for the Policy

type:OID

2.23.140.1.2.2
PolicyInformation Information of the Policy

policyIdentifier

Object ID for the Policy

type:OID

1.2.392.200091.100.901.4

policyQualifiers

Information of the policy qualifiers

PolicyQualifierID

Classification of the policy qualifiers

type:OID

1.3.6.1.5.5.7.2.1 (CPSuri)

Qualifier

URI of CPS is published

type:IA5String

https://repository.secomtrust.net/SC-Root2/
authorityInfoAccess (extnId :== 1.3.6.1.5.5.7.1.1, critical :== FALSE) value
AuthorityInfoAccess Authority Information Access

AccessDescription

Online Certificate Status Protocol

accessMethod

Access method

type:OID

1.3.6.1.5.5.7.48.1 (ocsp)

accessLocation

Access location

type:IA5String

http://scrootca2.ocsp.secomtrust.net

AccessDescription

Issuer of the Authority

accessMethod

Access method

type:OID

1.3.6.1.5.5.7.48.2 (caIssuers)

accessLocation

Access location

type:IA5String

http://repository.secomtrust.net/SC-Root2/SCRoot2ca.cer
extKeyUsage (extnId :== 2.5.29.37, critical :== FALSE) value
ExtKeyUsage Extended Key Usage

KeyPurposeId

The purpose of the key contained in the certificate

type:OID

1.3.6.1.5.5.7.3.1 (serverAuth)

1.3.6.1.5.5.7.3.2 (clientAuth)

Cybertrust Japan SureServer CA G4 Intermediate CA Certificate (Validity Period: September 27, 2019 to May 29, 2029) (Basic Certificate Fields)
version value
Version Version of the encoded certificate

type:INTEGER

2 (Ver.3)
serialNumber value
CertificateSerialNumber Serial number of certificate

type:INTEGER

640569883381181201454 (0x22b9b1630cecb43c2e)
signature value
AlgorithmIdentifier The identifier for the signature algorithm used by the CA to sign this certificate

algorithm

Object ID for the signature algorithm

type:OID

1.2.840.113549.1.1.11 (sha256WithRSAEncryption)

parameters

Parameters of signature algorithm

type:NULL

NULL
issuer value
countryName Country name attribute of certificate issuer

type

Object ID for the country name

type:OID

2.5.4.6

value

Value of country name

type:PrintableString

JP
organizationName Organization name attribute of certificate issuer

type

Object ID for organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString

SECOM Trust Systems CO.,LTD.
organizationalUnitName Organizational unit name attribute of certificate issuer

type

Object ID for organizational unit name

type:OID

2.5.4.11

value

Value of organizational unit name

type:PrintableString

Security Communication RootCA2
validity value
Validity Validity period of the certificate

notBefore

The date on which the certificate validity period begins

type:UTCTime

190927015423Z

(September 27, 2019 10:54:23 JST)

notAfter

The date on which the certificate validity period ends

type:UTCTime

290529050039Z

(May 29, 2029 14:00:39 JST)

subject value
countryName Country name attribute of certificate subject

type

Object ID for the country name

type:OID

2.5.4.6

value

Value of country name

type:PrintableString

JP
organizationName Organization name attribute of certificate subject

type

Object ID for organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString

Cybertrust Japan Co., Ltd.
commonName Common name attribute of certificate subject

type

Object ID for common name

type:OID

2.5.4.3

value

Value of common name

type:PrintableString

Cybertrust Japan SureServer CA G4
subjectPublicKeyInfo value
SubjectPublicKeyInfo Subject’s public key information

AlgorithmIdentifier

The identifier for cryptographic algorithm

algorithm

Object ID for the cryptographic algorithm

type:OID

1.2.840.113549.1.1.1 (rsaEncryption)

parameters

Parameters of cryptographic algorithm

type:NULL

NULL

subjectPublicKey

Value of public key

type:BIT STRING

*Public key of 2048 bit size
(Certificate Extensions)
subjectKeyIdentifier (extnId :== 2.5.29.14, critical :== FALSE) value
SubjectKeyIdentifier Information of Subject Key Identifier

KeyIdentifier

The identifier for public key

type:OCTET STRING

62:A7:D2:DA:DE:85:B6:92:F1:85:BC:F6:E8:95:9D:75:A0:FA:4E:1F
certificatePolicies (extnId :== 2.5.29.32, critical :== FALSE) value
PolicyInformation Information of the Policy

policyIdentifier

Object ID for the Policy
type:OID 1.2.392.200091.100.901.4

policyQualifiers

Information of the policy qualifiers

PolicyQualifierID

Classification of the policy qualifiers

type:OID

1.3.6.1.5.5.7.2.1 (CPSuri)

Qualifier

URI of CPS is published

type:IA5String

https://repository.secomtrust.net/SC-Root2/
cRLDistributionPoints (extnId :== 2.5.29.31, critical :== FALSE) value
CRLDistributionPoints CRL Distribution Point

DistributionPoint

CRL Distribution Point

uniformResourceIdentifier

URI of CRL Distribution Point

type:IA5String

http://repository.secomtrust.net/SC-Root2/SCRoot2CRL.crl
authorityInfoAccess (extnId :== 1.3.6.1.5.5.7.1.1, critical :== FALSE) value
AuthorityInfoAccess Authority Information Access

AccessDescription

Online Certificate Status Protocol

accessMethod

Access method

type:OID

1.3.6.1.5.5.7.48.1 (ocsp)

accessLocation

Access location

type:IA5String

http://scrootca2.ocsp.secomtrust.net

AccessDescription

Issuer of the Authority

accessMethod

Access method

type:OID

1.3.6.1.5.5.7.48.2 (caIssuers)

accessLocation

Access location

type:IA5String

http://repository.secomtrust.net/SC-Root2/SCRoot2ca.cer
authorityKeyIdentifier (extnId :== 2.5.29.35, critical :== FALSE) value
AuthorityKeyIdentifier Authority Key Identifier

KeyIdentifier

The identifier for public key

type:OCTET STRING

0A:85:A9:77:65:05:98:7C:40:81:F8:0F:97:2C:38:F1:0A:EC:3C:CF
keyUsage (extnId :== 2.5.29.15, critical :== TRUE) value
KeyUsage Key Usage

type:BIT STRING

00000110 (0x06)

(keyCertSign, cRLSign)

extKeyUsage (extnId :== 2.5.29.37, critical :== FALSE) value
ExtKeyUsage Extended Key Usage

KeyPurposeId

The purpose of the key contained in the certificate

type:OID

1.3.6.1.5.5.7.3.1 (serverAuth)

1.3.6.1.5.5.7.3.2 (clientAuth)

basicConstraints (extnId :== 2.5.29.19, critical :== TRUE) value
BasicConstraints Basic Constraints

cA

The flag to determine whether the supplied certificate is associated with a CA or an end entity

type:BOOLEAN

TRUE

pathLenConstraint

Path length constraint

type:INTEGER

0
iTrust EV SSL/TLS Server Certificate Certificate issued on or after January 25, 2024 (Basic Certificate Fields)
version value
Version Version of the encoded certificate

type:INTEGER

2 (Ver.3)
serialNumber value
CertificateSerialNumber Serial number of certificate

type:INTEGER

*Serial number of certificate (unique positive integer)
signature value
AlgorithmIdentifier The identifier for the signature algorithm used by the CA to sign this certificate

algorithm

Object ID for the signature algorithm

type:OID

1.2.840.113549.1.1.11 (sha256WithRSAEncryption)

parameters

Parameters of signature algorithm

type:NULL

NULL
issuer value
countryName Country name attribute of certificate issuer

type

Object ID for the country name

type:OID

2.5.4.6

value

Value of country name

type:PrintableString

JP
organizationName Organization name attribute of certificate issuer

type

Object ID for organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString

Cybertrust Japan Co., Ltd.
commonName Common name attribute of certificate issuer

type

Object ID for common name

type:OID

2.5.4.3

value

Value of common name

type:PrintableString

Cybertrust Japan SureServer EV CA G3
validity value
Validity Validity period of certificate

notBefore

The date on which the certificate validity period begins

type:UTCTime

*The date on which the certificate validity period begins

notAfter

The date on which the certificate validity period ends

type:UTCTime

*The date on which the certificate validity period ends
subject value
jurisdictionOfIncorporationCountryName Jurisdiction of incorporation country name attribute of certificate subject

type

Object ID for the jurisdiction of incorporation state or province name

type:OID

1.3.6.1.4.1.311.60.2.1.3

value

Value of jurisdiction of incorporation state or province name

type:PrintableString

JP (Fixed value)
jurisdictionOfIncorporationStateOrProvinceName Jurisdiction of incorporation state or province name attribute of certificate subject *Only valid when business category of the applicant is government entity (municipality or other)

type

Object ID for the jurisdiction of incorporation state or province name

type:OID

1.3.6.1.4.1.311.60.2.1.2

value

Value of jurisdiction of incorporation state or province name

type:PrintableString

*Jurisdiction of incorporation state or province name
jurisdictionOfIncorporationLocalityName Jurisdiction of incorporation locality name attribute of certificate subject *Only valid when business category of the applicant is government entity (other)

type

Object ID for the jurisdiction of incorporation locality name

type:OID

1.3.6.1.4.1.311.60.2.1.1

value

Value of jurisdiction of incorporation locality name

type:PrintableString

*Jurisdiction of incorporation locality name
serialNumber Registration number attribute of certificate subject

type

Object ID for the registration number

type:OID

2.5.4.5

value

Value of registration number

type:PrintableString

*Registration number attribute of certificate subject

*When business category of the applicant is private organization, it is required registration number.

When business category of the applicant

is government entity, it is required "The Subject is Government Entity".

businessCategory Business category attribute of certificate subject

type

Object ID for the business category

type:OID

2.5.4.15

value

Value of business category

type:PrintableString

*Business category attribute of certificate subject

Private: Private Organization

Government (central government ministries /the administrative divisions of Japan / municipality): Government Entity

Government(others) : Government Entity

countryName Validated country name attribute of certificate subject

type

Object ID for the country name

type:OID

2.5.4.6

value

Value of country name

type:PrintableString

*Validated country name attribute of certificate subject
stateOrProvinceName Validated state or Province name attribute of certificate subject

type

Object ID for the state or province name

type:OID

2.5.4.8

value

Value of state or province name

type:PrintableString / UTF8String

*Validated state or province name attribute of certificate subject
localityName Validated locality name attribute of certificate subject

type

Object ID for the locality name

type:OID

2.5.4.7

value

Value of locality name

type:PrintableString / UTF8String

*Validated locality name attribute of certificate subject
organizationName Formal organization name attribute of certificate subject

type

Object ID for organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString / UTF8String

*Formal organization name attribute of certificate subject
commonName Common name attribute of certificate subject

type

Object ID for common name

type:OID

2.5.4.3

value

Value of common name

type:PrintableString

*FQDN of the SSL/TLS server
subjectPublicKeyInfo value
SubjectPublicKeyInfo Subject’s public key information

AlgorithmIdentifier

The identifier for cryptographic algorithm

algorithm

Object ID for the cryptographic algorithm

type:OID

1.2.840.113549.1.1.1 (rsaEncryption)

parameters

Parameters of cryptographic algorithm

type:NULL

NULL

subjectPublicKey

Value of public key

type:BIT STRING

*The key size depends on application

*The key size must be at least 2048 bit

(Certificate Extensions)
basicConstraints (extnId :== 2.5.29.19, critical :== TRUE) value
BasicConstraints Basic Constraints

cA

The flag to determine whether the supplied certificate is associated with a CA or an end entity

type:BOOLEAN

FALSE
certificatePolicies (extnId :== 2.5.29.32, critical :== FALSE) value
PolicyInformation Information of the Policy

policyIdentifier

Object ID for the Policy

type:OID

2.23.140.1.1 (extended-validation)
PolicyInformation Information of the Policy

policyIdentifier

Object ID for the Policy

type:OID

1.2.392.200081.1.22.1
PolicyInformation Information of the Policy

policyIdentifier

Object ID for the Policy

type:OID

1.2.392.200091.100.721.1

policyQualifiers

Information of the policy qualifiers

PolicyQualifierID

Classification of the policy qualifiers

type:OID

1.3.6.1.5.5.7.2.1 (CPSuri)

Qualifier

URI of CPS is published

type:IA5String

https://www.cybertrust.ne.jp/ssl/repository/index.html
authorityInfoAccess (extnId :== 1.3.6.1.5.5.7.1.1, critical :== FALSE) value
AuthorityInfoAccess Authority Information Access

AccessDescription

Online Certificate Status Protocol

accessMethod

Access method

type:OID

1.3.6.1.5.5.7.48.1 (ocsp)

accessLocation

Access location

type:IA5String

http://evocsp.cybertrust.ne.jp/OcspServer

AccessDescription

Issuer of the Authority

accessMethod

Access method

type:OID

1.3.6.1.5.5.7.48.2 (caIssuers)

accessLocation

Access location

type:IA5String

http://crl.cybertrust.ne.jp/SureServer/evcag3/evcag3.crt
subjectAltName (extnId :== 2.5.29.17, critical :== FALSE) value
SubjectAltName Subject Alternative Name

dNSName

DNSName

type:IA5String

*FQDN of the SSL/TLS server
keyUsage (extnId :== 2.5.29.15, critical :==TRUE) value
KeyUsage Key Usage

type:BIT STRING

10100000 (0xA0)

(digitalSignature, keyEncipherment)

extKeyUsage (extnId :== 2.5.29.37, critical :== FALSE) value
ExtKeyUsage Extended Key Usage

KeyPurposeId

The purpose of the key contained in the certificate

type:OID

1.3.6.1.5.5.7.3.1 (serverAuth)

1.3.6.1.5.5.7.3.2 (clientAuth)

authorityKeyIdentifier (extnId :== 2.5.29.35, critical :== FALSE) value
AuthorityKeyIdentifier Authority Key Identifier

KeyIdentifier

The identifier for public key

type:OCTET STRING

82:6C:75:5D:53:F5:45:69:BC:25:2D:A4:4C:89:E6:B2:B7:41:87:A3
cRLDistributionPoints (extnId :== 2.5.29.31, critical :== FALSE) value
CRLDistributionPoints CRL Distribution Point

DistributionPoint

CRL Distribution Point

uniformResourceIdentifier

URI of CRL Distribution Point

type:IA5String

http://crl.cybertrust.ne.jp/SureServer/evcag3/cdp.crl
subjectKeyIdentifier (extnId :== 2.5.29.14, critical :== FALSE) value
SubjectKeyIdentifier Subject Key Identifier(Based on RFC 5280, Section 4.2.1.2)

KeyIdentifier

The identifier for public key

type:OCTET STRING

*Hash value of the BIT STRING subjectPublicKey
signedCertificateTimestampList (extnId :== 1.3.6.1.4.1.11129.2.4.2, critical :== FALSE) value
SignedCertificateTimestampList Timestamp list for Certificate Transparency

SignedCertificateTimestamp

Timestamp of Certificate Transparency

type:OCTET STRING

*Signed CertificateTimestamp List
iTrust SSL/TLS Server Certificate Certificate issued on or after January 25, 2024 (Basic Certificate Fields)
version value
Version Version of the encoded certificate

type:INTEGER

2 (Ver.3)
serialNumber value
CertificateSerialNumber Serial number of certificate

type:INTEGER

*Serial number of certificate (unique positive integer)
signature value
AlgorithmIdentifier The identifier for the signature algorithm used by the CA to sign this certificate

algorithm

Object ID for the signature algorithm

type:OID

1.2.840.113549.1.1.11 (sha256WithRSAEncryption)

parameters

Parameters of signature algorithm

type:NULL

NULL
issuer value
countryName Country name attribute of certificate issuer

type

Object ID for the country name

type:OID

2.5.4.6

value

Value of country name

type:PrintableString

JP
organizationName Organization name attribute of certificate issuer

type

Object ID for organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString

Cybertrust Japan Co., Ltd.
commonName Common name attribute of certificate issuer

type

Object ID for common name

type:OID

2.5.4.3

value

Value of common name

type:PrintableString

Cybertrust Japan SureServer CA G4
validity value
Validity Validity period of certificate

notBefore

The date on which the certificate validity period begins

type:UTCTime

*The date on which the certificate validity period begins

notAfter

The date on which the certificate validity period ends

type:UTCTime

*The date on which the certificate validity period ends
subject value
countryName Validated country name attribute of certificate subject

type

Object ID for the country name

type:OID

2.5.4.6

value

Value of country name

type:PrintableString

*Validated country name attribute of certificate subject
stateOrProvinceName Validated state or Province name attribute of certificate subject

type

Object ID for the state or province name

type:OID

2.5.4.8

value

Value of state or province name

type:PrintableString / UTF8String

*Validated state or province name attribute of certificate subject
localityName Validated locality name attribute of certificate subject

type

Object ID for the locality name

type:OID

2.5.4.7

value

Value of locality name

type:PrintableString / UTF8String

*Validated locality name attribute of certificate subject
organizationName Formal organization name attribute of certificate subject

type

Object ID for organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString / UTF8String

* Formal organization name attribute of certificate subject
commonName Common name attribute of certificate subject

type

Object ID for common name

type:OID

2.5.4.3

value

Value of common name

type:PrintableString

*FQDN of the SSL/TLS server
subjectPublicKeyInfo value
SubjectPublicKeyInfo Subject’s public key information

AlgorithmIdentifier

The identifier for cryptographic algorithm

algorithm

Object ID for the cryptographic algorithm

type:OID

1.2.840.113549.1.1.1 (rsaEncryption)

parameters

Parameters of cryptographic algorithm

type:NULL

NULL

subjectPublicKey

Value of public key

type:BIT STRING

*The key size depends on application

*The key size must be at least 2048 bit

(Certificate Extensions)
basicConstraints (extnId :== 2.5.29.19, critical :== TRUE) value
BasicConstraints Basic Constraints

cA

The flag to determine whether the supplied certificate is associated with a CA or an end entity

type:BOOLEAN

FALSE
certificatePolicies (extnId :== 2.5.29.32, critical :== FALSE) value
PolicyInformation Information of the Policy

policyIdentifier

Object ID for the Policy

type:OID

2.23.140.1.2.2 (organization-validated)
PolicyInformation Information of the Policy

policyIdentifier

Object ID for the Policy

type:OID

1.2.392.200081.1.23.1

policyQualifiers

Information of the policy qualifiers

PolicyQualifierID

Classification of the policy qualifiers

type:OID

1.3.6.1.5.5.7.2.1 (CPSuri)

Qualifier

URI of CPS is published

type:IA5String

https://www.cybertrust.ne.jp/ssl/repository/index.html
subjectAltName (extnId :== 2.5.29.17, critical :== FALSE) value
SubjectAltName Subject Alternative Name

dNSName or iPAddress

DNS Name or iPAddress

type:IA5String (DNS Name)

type: OCTET STRING (iPAddress)

*FQDN or IP address of the SSL/TLS server
authorityInfoAccess (extnId :== 1.3.6.1.5.5.7.1.1, critical :== FALSE) value
Authority Information Access Authority Information Access

AccessDescription

Online Certificate Status Protocol

accessMethod

Access method

type:OID

1.3.6.1.5.5.7.48.1 (ocsp)

accessLocation

Access location

type:IA5String

http://ssocsp.cybertrust.ne.jp/OcspServer

AccessDescription

Issuer of the Authority

accessMethod

Access method

type:OID

1.3.6.1.5.5.7.48.2 (caIssuers)

accessLocation

Access location

type:IA5String

http://crl.cybertrust.ne.jp/SureServer/ovcag4/ovcag4.crt
keyUsage (extnId :== 2.5.29.15, critical :==TRUE) value
KeyUsage Key Usage

type:BIT STRING

10100000 (0xA0)

(digitalSignature, keyEncipherment)

extKeyUsage (extnId :== 2.5.29.37, critical :== FALSE) value
ExtKeyUsage Extended Key Usage

KeyPurposeId

The purpose of the key contained in the certificate

type:OID

1.3.6.1.5.5.7.3.1 (serverAuth)

1.3.6.1.5.5.7.3.2 (clientAuth)

authorityKeyIdentifier (extnId :== 2.5.29.35, critical :== FALSE) value
AuthorityKeyIdentifier Authority Key Identifier

KeyIdentifier

The identifier for public key

type:OCTET STRING

62:A7:D2:DA:DE:85:B6:92:F1:85:BC:F6:E8:95:9D:75:A0:FA:4E:1F
cRLDistributionPoints (extnId :== 2.5.29.31, critical :== FALSE) value
CRLDistributionPoints CRL Distribution Point

DistributionPoint

CRL Distribution Point

uniformResourceIdentifier

URI of CRL Distribution Point

type:IA5String

http://crl.cybertrust.ne.jp/SureServer/ovcag4/cdp.crl
subjectKeyIdentifier (extnId :== 2.5.29.14, critical :== FALSE) value
SubjectKeyIdentifier Subject Key Identifier (Generated according to RFC5280, Section 4.2.1.2)

KeyIdentifier

The identifier for public key

type:OCTET STRING

*Hash value of the BIT STRING subjectPublicKey
signedCertificateTimestampList (extnId :== 1.3.6.1.4.1.11129.2.4.2, critical :== FALSE) value
SignedCertificateTimestampList Timestamp list for Certificate Transparency

SignedCertificateTimestamp

Timestamp of Certificate Transparency

type:OCTET STRING

*Signed CertificateTimestamp List
OCSP Responder Certificate Cybertrust Japan SureServer EV CA G3 (Basic Certificate Fields)
version value
Version Version of the encoded certificate

type:INTEGER

2 (Ver.3)
serialNumber value
CertificateSerialNumber Serial number of certificate

type:INTEGER

*Serial number of certificate (unique positive integer)
signature value
AlgorithmIdentifier The identifier for the signature algorithm used by the CA to sign this certificate

algorithm

Object ID for the signature algorithm

type:OID

1.2.840.113549.1.1.11 (sha256WithRSAEncryption)

parameters

Parameters of signature algorithm

type:NULL

NULL
issuer value
countryName Country name attribute of certificate issuer

type

Object ID for the country name

type:OID

2.5.4.6

value

Value of country name

type:PrintableString

JP
organizationName Organization name attribute of certificate issuer

type

Object ID for organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString

Cybertrust Japan Co., Ltd.
commonName Common name attribute of certificate issuer

type

Object ID for common name

type:OID

2.5.4.3

value

Value of common name

type:PrintableString

Cybertrust Japan SureServer EV CA G3
validity value
Validity Validity period of certificate

notBefore

The date on which the certificate validity period begins

type:UTCTime

*The date on which the certificate validity period begins

notAfter

The date on which the certificate validity period ends

type:UTCTime

*The date on which the certificate validity period ends
subject value
countryName Country name attribute of certificate subject

type

Object ID for the country name

type:OID

2.5.4.6

value

Value of country name

type:PrintableString

JP
organizationName Organization name attribute of certificate subject

type

Object ID for organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString

Cybertrust Japan Co., Ltd.
commonName Common name attribute of certificate subject

type

Object ID for common name

type:OID

2.5.4.3

value

Value of common name

type:PrintableString

Cybertrust Japan SureServer EV CA G3 OCSP Responder
subjectPublicKeyInfo value
SubjectPublicKeyInfo Subject’s public key information

AlgorithmIdentifier

The identifier for cryptographic algorithm

algorithm

Object ID for the cryptographic algorithm

type:OID

1.2.840.113549.1.1.1 (rsaEncryption)

parameters

Parameters of cryptographic algorithm

type:NULL

NULL

subjectPublicKey

Value of public key

type:BIT STRING

*Public key of 2048 bit size
(Certificate Extensions)
basicConstraints (extnId :== 2.5.29.19, critical :== TRUE) value
BasicConstraints Basic Constraints

cA

The flag to determine whether the supplied certificate is associated with a CA or an end entity

type:BOOLEAN

FALSE
ocspNoCheck (extnId :== 1.3.6.1.5.5.7.48.1.5, critical :== FALSE) value
OCSPNoCheck Revocation checking of signer certificates
Do not check revocation NULL
keyUsage (extnId :== 2.5.29.15, critical :== TRUE) value
KeyUsage Key Usage

type:BIT STRING

10000000 (0x80)

(digitalSignature)

extKeyUsage (extnId :== 2.5.29.37, critical :== FALSE) value
ExtKeyUsage Extended Key Usage

KeyPurposeId

The purpose of the key contained in the certificate

type:OID

1.3.6.1.5.5.7.3.9 (OCSPSigning)
authorityKeyIdentifier (extnId :== 2.5.29.35, critical :== FALSE) value
AuthorityKeyIdentifier Authority Key Identifier

KeyIdentifier

The identifier for public key

type:OCTET STRING

82:6C:75:5D:53:F5:45:69:BC:25:2D:A4:4C:89:E6:B2:B7:41:87:A3
subjectKeyIdentifier (extnId :== 2.5.29.14, critical :== FALSE) value
SubjectKeyIdentifier Subject Key Identifier

KeyIdentifier

The identifier for public key

type:OCTET STRING

*Hash value of the BIT STRING subjectPublicKey
Cybertrust Japan SureServer CA G4 (Basic Certificate Fields)
version value
Version Version of the encoded certificate

type:INTEGER

2 (Ver.3)
serialNumber value
CertificateSerialNumber Serial number of certificate

type:INTEGER

*Serial number of certificate (unique positive integer)
signature value
AlgorithmIdentifier The identifier for the signature algorithm used by the CA to sign this certificate

algorithm

Object ID for the signature algorithm

type:OID

1.2.840.113549.1.1.11 (sha256WithRSAEncryption)

parameters

Parameters of signature algorithm

type:NULL

NULL
issuer value
countryName Country-name attribute of certificate issuer

type

Object ID for the country name

type:OID

2.5.4.6

value

Value of country name

type:PrintableString

JP
organizationName Organization name attribute of certificate issuer

type

Object ID for organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString

Cybertrust Japan Co., Ltd.
commonName Common name attribute of certificate issuer

type

Object ID for common name

type:OID

2.5.4.3

value

Value of common name

type:PrintableString

Cybertrust Japan SureServer CA G4
validity value
Validity Validity period of certificate

notBefore

The date on which the certificate validity period begins

type:UTCTime

*The date on which the certificate validity period begins

notAfter

The date on which the certificate validity period ends

type:UTCTime

*The date on which the certificate validity period ends
subject value
countryName Country name attribute of certificate subject

type

Object ID for the country name

type:OID

2.5.4.6

value

Value of country name

type:PrintableString

JP
organizationName Organization name attribute of certificate subject

type

Object ID for organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString

Cybertrust Japan Co., Ltd.
commonName Common name attribute of certificate subject

type

Object ID for common name

type:OID

2.5.4.3

value

Value of common name

type:PrintableString

Cybertrust Japan SureServer CA G4 OCSP Responder
subjectPublicKeyInfo value
SubjectPublicKeyInfo Subject’s public key information

AlgorithmIdentifier

The identifier for cryptographic algorithm

algorithm

Object ID for the cryptographic algorithm

type:OID

1.2.840.113549.1.1.1 (rsaEncryption)

parameters

Parameters of cryptographic algorithm

type:NULL

NULL

subjectPublicKey

Value of public key

type:BIT STRING

*Public key of 2048 bit size
(Certificate Extensions)
basicConstraints (extnId :== 2.5.29.19, critical :== TRUE) value
BasicConstraints Basic Constraints

cA

The flag to determine whether the supplied certificate is associated with a CA or an end entity

type:BOOLEAN

FALSE
ocspNoCheck (extnId :== 1.3.6.1.5.5.7.48.1.5, critical :== FALSE) value
OCSPNoCheck Revocation checking of signer certificates
Do not check revocation NULL
keyUsage (extnId :== 2.5.29.15, critical :== TRUE) value
KeyUsage Key Usage

type:BIT STRING

10000000 (0x80)

(digitalSignature)

extKeyUsage (extnId :== 2.5.29.37, critical :== FALSE) value
ExtKeyUsage Extended Key Usage

KeyPurposeId

The purpose of the key contained in the certificate

type:OID

1.3.6.1.5.5.7.3.9 (OCSPSigning)
authorityKeyIdentifier (extnId :== 2.5.29.35, critical :== FALSE) value
AuthorityKeyIdentifier Authority Key Identifier

KeyIdentifier

The identifier for public key

type:OCTET STRING

62:A7:D2:DA:DE:85:B6:92:F1:85:BC:F6:E8:95:9D:75:A0:FA:4E:1F
subjectKeyIdentifier (extnId :== 2.5.29.14, critical :== FALSE) value
SubjectKeyIdentifier Subject Key Identifier

KeyIdentifier

The identifier for public key
type:OCTET STRING *Hash value of the BIT STRING subjectPublicKey
CRL Cybertrust Japan SureServer EV CA G3 (CRL Fields)
version value
Version Version of the CRL (Revocation list)

type:INTEGER

1 (Ver.2)
signature value
AlgorithmIdentifier The identifier for the signature algorithm used by the CRL issuer to sign the CertificateList

algorithm

Object ID for the signature algorithm

type:OID

1.2.840.113549.1.1.11 (sha256WithRSAEncryption)

parameters

Parameters of signature algorithm

type:NULL

NULL
issuer value
countryName Country name attribute of CRL issuer

type

Object ID for the country name

type:OID

2.5.4.6

value

Value of country name

type:PrintableString

JP
organizationName Organization name attribute of CRL issuer

type

Object ID for organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString

Cybertrust Japan Co., Ltd.
commonName Common name attribute of CRL issuer

type

Object ID for common name

type:OID

2.5.4.3

value

Value of common name

type:PrintableString

Cybertrust Japan SureServer EV CA G3
thisUpdate value
thisUpdate The issue date of this CRL

type:UTCTime

*The date on which the certificate validity period begins
nextUpdate value
nextUpdate The date by which the next CRL is issued

type:UTCTime

*The date by which the next CRL is issued
(CRL Extensions)
authorityKeyIdentifier (extnId :== 2.5.29.35, critical :== FALSE) value
AuthorityKeyIdentifier Authority Key Identifier

KeyIdentifier

The identifier for public key

type:OCTET STRING

82:6C:75:5D:53:F5:45:69:BC:25:2D:A4:4C:89:E6:B2:B7:41:87:A3
cRLNumber (extnId :== 2.5.29.20, critical :== FALSE) value
cRLNumber CRL Number

type:INTEGER

*Serial number of CRL
(CRL Entry)
revokedCertificates value
CertificateSerialNumber Serial number of revoked certificate

type:INTEGER

*Serial number of revoked certificate
revocationDate The date on which the revocation occurred

type:UTCTime

*The date on which the revocation occurred
(CRL Entry Extensions)
invalidityDate (extnId :== 2.5.29.24, critical :== FALSE) value
invalidityDate The date on which it is known or suspected That the certificate became invalid

type:GeneralizedTime

*The date on which the revocation occurred of the certificate
cRLReason (extnId :== 2.5.29.21, critical :== FALSE) value
CRLReason The reason code for the certificate revocation

type:ENUMERATED

*Value of reason code for the revocation
Cybertrust Japan SureServer CA G4 (CRL Fields)
version value
Version Version of the CRL(Revocation list)

type:INTEGER

1 (Ver.2)
signature value
AlgorithmIdentifier The identifier for the signature algorithm used by the CRL issuer to sign the CertificateList

algorithm

Object ID for the signature algorithm

type:OID

1.2.840.113549.1.1.11 (sha256WithRSAEncryption)

parameters

Parameters of signature algorithm

type:NULL

NULL
issuer value
countryName Country name attribute of CRL issuer

type

Object ID for the country name

type:OID

2.5.4.6

value

Value of country name

type:PrintableString

JP
organizationName Organization name attribute of CRL issuer

type

Object ID for organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString

Cybertrust Japan Co., Ltd.
commonName Common name attribute of CRL issuer

type

Object ID for common name

type:OID

2.5.4.3

value

Value of common name

type:PrintableString

Cybertrust Japan SureServer CA G4
thisUpdate value
thisUpdate The issue date of this CRL

type:UTCTime

*The issue date of this CRL
nextUpdate value
nextUpdate The date by which the next CRL is issued

type:UTCTime

*The date by which the next CRL is issued
(CRL Extensions)
authorityKeyIdentifier (extnId :== 2.5.29.35, critical :== FALSE) value
AuthorityKeyIdentifier Authority Key Identifier

KeyIdentifier

The identifier for public key

type:OCTET STRING

62:A7:D2:DA:DE:85:B6:92:F1:85:BC:F6:E8:95:9D:75:A0:FA:4E:1F
cRLNumber (extnId :== 2.5.29.20, critical :== FALSE) value
cRLNumber CRL Number

type:INTEGER

*Serial number of CRL
(CRL Entry)
revokedCertificates value
CertificateSerialNumber Serial number of revoked certificate

type:INTEGER

*Serial number of revoked certificate
revocationDate The date on which the revocation occurred

type:UTCTime

*The date on which the revocation occurred
(CRL Entry Extensions)
invalidityDate (extnId :== 2.5.29.24, critical :== FALSE) value
invalidityDate The date on which it is known or suspected that the certificate became invalid

type:GeneralizedTime

*The date on which the revocation occurred of the certificate
cRLReason (extnId :== 2.5.29.21, critical :== FALSE) value
CRLReason The reason code for the certificate revocation

type:ENUMERATED

*Value of reason code for the revocation