#### Cybertrust Japan Certificate Policy/Certification Practice Statement for Public Server Certificate OID: 1.2.392.200081.1.32 Version 2.00 Cybertrust Japan Co., Ltd. February 14, 2025 # **■ 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. © 2020 Cybertrust Japan Co., Ltd. Version 2.00 Creation/revision date: February 14, 2025 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_rt/ 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.00 October 14, 2021
  • Merged two existing CPSes(JCSI Root Certification Practice Statement and Cybertrust Root Certification Practice Statement) and established “Cybertrust Japan Certification Practice Statement” as version 1.00.

1.01 November 25, 2021
  • Modified "5.4.1 Types of Events Recorded"

1.02 August 25, 2022
  • Modified the description listed in "5.4.1 Types of events recorded" for the clarification.

  • Added descriptions in Section "9.16.3 Severability"

  • Minor modifications on phraseology.

1.03 September 21, 2022
  • Revised "1.1 Overview" and "Appendix B: List of Revoked CAs" due to the revocation of CA certificates.

1.04 November 11, 2022
  • Modified names of the documents referenced in "1.1 Overview"

1.05 April 21, 2023
  • Added about the Validation Specialist internal examination in section “5.3.3 Training Requirements”

  • Added about notification to root program in "5.7.1 Incident and Compromise Handling Procedures"

  • Added about requirements to comply in "6.7 Network Security Controls"

1.06 April 28, 2023
  • Revised "1.1 Overview", "2.2 Publication of Certification Information", and "Appendix B: List of Revoked CAs" due to the revocation of CA certificates.

1.07 August 24,2023
  • Modified descriptions in "1.1 Overview" due to the issuance of CA certificate.

  • Revised "1.1 Overview" and "Appendix B: List of Revoked CAs" due to the revocation of CA certificate.

  • Added descriptions in "1.5.2 Contact Person" for clarification.

  • Modified descriptions in "9.12.1 Procedure for Amendment".

  • Added definitions in "Appendix B List of Definitions".

  • Minor modifications on phraseology.

1.08 March 15, 2024
  • Modified descriptions in "6.8 Time-stamping"

  • Minor modifications on phraseology.

1.09 April 15, 2024
  • Added descriptions on Timestamp Authority in “1.1 Overview”

  • Modified ”1.3.3 Issuing Authorities” to “1.3.1.1 Issuing Authorities”

  • Added “1.3.2.1 Enterprise registration authorities”

  • Added descriptions on Timestamp Authority in “1.3.5 Other Participants”

  • Modified descriptions in “2.4 Access Controls on Repositories”

  • Modified descriptions in “5.7.1 Incident and Compromise Handling Procedures”

1.10 July 30, 2024
  • Added newly created CAs' information in "1.1 Overview" and “2.2 Publication of certification information”

  • Modified descriptions in "1.3.3 Subscribers“

  • Clarified “1.3.5 Other Participants”

  • Added “5.4.1.1 Router and firewall activities logs”

  • Modified the description in “6.4.1 Activation data generation and installation” due to new equipment procurement of HSM

  • Added 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.11 August 20, 2024
  • Deleted revoked Subordinate Certification Authorities information in “1.1 Overview” and “2.2 Publication of certification information”.

  • Deleted or modified descriptions related to “Organization-validated Legacy Generation of S/MIME Certificate”, “EV Code Signing Certificate”, “Non EV Code Signing Certificate”, and “Timestamp Certificate”, which had been no longer issued due to revocation of Subordinate Certification Authorities.

  • Added revoked Subordinate Certification Authorities information in “Appendix D: List of Revoked CAs”.

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

  • Add definitions in "Appendix B List of Definitions"

  • Minor modifications on phraseology

2.00 February 14, 2025
  • Integrated CP(Cybertrust Japan Certificate Policy) and CPS(Cybertrust Japan Certification Practice Statement), removed descriptions related to S/MIME, and established a dedicated CP/CPS for SSL/TLS server certificate(Cybertrust Japan Certificate Policy/Certification Practice Statement for Public Server Certificate)

\*Note This “Cybertrust Japan Certificate Policy/Certification Practice Statement for Public Server Certificate Version 2.00” of Cybertrust Japan Co., Ltd. basically describes the following matters. Please note that the following is a reference translation, and the effective statement is the original statement in the Japanese language. Also please kindly note that Cybertrust Japan Co., Ltd. does not guarantee the accuracy of this English translation in comparison to the original statement in the Japanese language, and will not be liable in any way for any inconsistency between this English translation and the original statement in the Japanese language. However, Cybertrust attests that the translation is updated per Japanese revision, and it is not materially different to the original. Cybertrust Japan Co., Ltd. may provide the revised English translation with the date of revision for the same version of Cybertrust Japan’s “Cybertrust Japan Certificate Policy/Certification Practice Statement for Public Server Certificate.” Upon disclosure of the new version of “Cybertrust Japan Certificate Policy/Certification Practice Statement for Public Server Certificate” by Cybertrust Japan Co., Ltd., please stop referring to/using this documentation. Your understanding on above mentioned conditions is requested prior to refer to this documentation. # Contents - [](#-1) - [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.2.1 Enterprise registration authorities](#1321-enterprise-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 and Mailbox Authorization or Control ](#3224-validation-of-domain-and-mailbox-authorization-or-control) - [3.2.2.5 Authentication for an IP Address ](#3225-authentication-for-an-ip-address) - [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 Record (Certification Authority Authorization Record) Procedures ](#3228-caa-record-certification-authority-authorization-record-procedures) - [3.2.2.9 Multi-Perspective Issuance Corroboration ](#3229-multi-perspective-issuance-corroboration) - [3.2.2.10 TLS Using a Random Value ](#32210-tls-using-a-random-value) - [3.2.2.11 Any Other Method ](#32211-any-other-method) - [3.2.2.12 Validating Applicant as a Domain Contact ](#32212-validating-applicant-as-a-domain-contact) - [3.2.2.13 Email to DNS CAA Contact ](#32213-email-to-dns-caa-contact) - [3.2.2.14 Email to DNS TXT Contact ](#32214-email-to-dns-txt-contact) - [3.2.2.15 Phone Contact with Domain Contact ](#32215-phone-contact-with-domain-contact) - [3.2.2.16 Phone Contact with DNS TXT Record Phone Contact ](#32216-phone-contact-with-dns-txt-record-phone-contact) - [3.2.2.17 Phone Contact with DNS CAA Phone Contact  ](#32217-phone-contact-with-dns-caa-phone-contact) - [3.2.2.18 Agreed‐Upon Change to Website v2 ](#32218-agreedupon-change-to-website-v2) - [3.2.2.19 Agreed‐Upon Change to Website - ACME ](#32219-agreedupon-change-to-website---acme) - [3.2.2.20 TLS Using ALPN ](#32220-tls-using-alpn) - [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.1.2 Reasons for Revoking a Subordinate CA Certificate](#4912-reasons-for-revoking-a-subordinate-ca-certificate) - [4.9.1.3 Reason of Revoking Other Certificates ](#4913-reason-of-revoking-other-certificates) - [4.9.1.3.1 Root CA Certificate](#49131-root-ca-certificate) - [4.9.1.3.2 OCSP Responder Certificate](#49132-ocsp-responder-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.12.1 Certificate](#49121-certificate) - [4.9.12.2 OCSP Responder Certificate](#49122-ocsp-responder-certificate) - [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.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-Audits](#87-self-audits) - [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: Verification Requirements for Subscriber Certificate](#appendix-a-verification-requirements-for-subscriber-certificate) - [Appendix B: List of Definitions](#appendix-b-list-of-definitions) # 1\. INTRODUCTION ## 1.1 Overview Cybertrust Japan Co., Ltd. ("Cybertrust") operates Root Certification Authorities (the "Root CAs") and Subordinate Certification Authorities (the "Subordinate CAs") underneath to issue publicly trusted digital certificates. And The Subordinate CAs of SecureSign RootCA11 is a Technically Constrained CA. The Root CAs and the Subordinate CAs are collectively referred to as the "CAs" hereinafter unless separately described in this document. The "EV SSL/TLS Server Certificate", "OV SSL/TLS Server Certificate" (hereinafter collectively referred to as "certificates" unless separately stipulated) are issued from each Subordinate CA to its subscribers. For certificates, subordinate CAs does not issue the subscriber certificates of Domain Validated (DV) and Individual Validated (IV). Each Root CA is identified with the information in following tables, and the certificates for each Subordinate CA are issued by either one of the Root CAs operated by Cybertrust. Note that revoked CAs are listed in Appendix D. Root CAs | Name of CA | SecureSign RootCA11 | | --------------------------------- | :--------------------------------------------------------------- | | Launch Date of CA | June 30, 2014 | | Serial Number of CA Certificate | 01 | | Validity Period of CA Certificate | April 8, 2009 to April 8, 2029 | | Signature Algorithm | SHA1 with RSA | | Key Size of CA | 2048 bit | | Hash value (SHA-1) | 3BC49F48F8F373A09C1EBDF85BB1C365C7D811B3 | | Hash value (SHA-256) | BF0FEEFB9E3A581AD5F9E9DB7589985743D261085C4D314F6F5D7259AA421612 | | Name of CA | SecureSign Root CA12 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 66F9C7C1AFECC251B4ED5397E6E682C32B1C9016 | | Validity Period of CA Certificate | April 8, 2020 to April 8, 2040 | | Signature Algorithm | SHA256 with RSA | | Key Size of CA | 2048 bit | | Hash value (SHA-1) | 7A221E3DDE1B06AC9EC84770168E3CE5F76B06F4 | | Hash value (SHA-256) | 3F034BB5704D44B2D08545A02057DE93EBF3905FCE721ACBC730C06DDAEE904E | | Name of CA | SecureSign Root CA14 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 64DB5A0C204EE8D72977C85027A25A27DD2DF2CB | | Validity Period of CA Certificate | April 8, 2020 to April 8, 2045 | | Signature Algorithm | SHA384 with RSA | | Key Size of CA | 4096 bit | | Hash value (SHA-1) | DD50C0F779B3642E74A2B89D9FD340DDBBF0F24F | | Hash value (SHA-256) | 4B009C1034494F9AB56BBA3BA1D62731FC4D20D8955ADCEC10A925607261E338 | | Name of CA | SecureSign Root CA15 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 1615C7C3D849A7BE690C8A88EDF070F9DDB73E87 | | Validity Period of CA Certificate | April 8, 2020 to April 8, 2045 | | Signature Algorithm | ECDSA with SHA384 | | Key Size of CA | 384 bit | | Hash value (SHA-1) | CBBA83C8C15A5DF1F9736FCAD7EF2813064A077D | | Hash value (SHA-256) | E778F0F095FE843729CD1A0082179E5314A9C291442805E1FB1D8FB6B8886C3A | | Name of CA | SecureSign Root CA16 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 547B8DAB53110077A81803AEA12B1129AB42E045 | | Validity Period of CA Certificate | July 30, 2024 to July 29, 2044 | | Signature Algorithm | SHA384 with RSA | | Key Size of CA | 4096 bit | | Hash value (SHA-1) | D17917EC45E2A0CAD774513010A4C65CAAB33C49 | | Hash value (SHA-256) | 4C1CCD24F17E950FC18536B33CAFE32293CFC33E8467B41E1C693055D7F513BF | Subordinate CAs | Name of CA | Cybertrust Japan SureServer EV CA G7 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 2C77F85B12969E757EAC8921C7155089AE35F418 | | Validity Period of CA Certificate | June 22, 2020 to June 22, 2030 | | Signature Algorithm | SHA256 with RSA | | Key Size of CA | 2048 bit | | Hash value (SHA-1) | 99865D3428D04DEF0D3FA29DEFBD5905A0B040A7 | | Hash value (SHA-256) | 76648FBC40CC4164CEA02422A09EB4EAD29C67F5E7DD74F691B7FA08043472C5 | | Certificates to be Issued | EV SSL/TLS Server Certificate | | Root CA | SecureSign Root CA12 | | Name of CA | Cybertrust Japan SureServer EV CA G8 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 7CA3593373BD43AA87416AB0439DAC5D0361D803 | | Validity Period of CA Certificate | June 22, 2020 to June 22, 2030 | | Signature Algorithm | ECDSA with SHA384 | | Key Size of CA | 384 bit | | Hash value (SHA-1) | FBF4B414FBA71E4F10AA57CF8C47697489D59ED1 | | Hash value (SHA-256) | 70C4002E0DF2FF51E691654903BE742D09D5A74A84B15B68FBCDA320FBF3DC6B | | Certificates to be Issued | EV SSL/TLS Server Certificate | | Root CA | SecureSign Root CA15 | | Name of CA | Cybertrust Japan SureServer EV CA G9 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 756AA35ABA8847DD5103C33A37B168FA13A4F715 | | Validity Period of CA Certificate | June 22, 2020 to June 22, 2030 | | Signature Algorithm | SHA384 with RSA | | Key Size of CA | 4096 bit | | Hash value (SHA-1) | EDEC2820E5CD08CB234D3B2417FE0DCDB51D238B | | Hash value (SHA-256) | 93397E182492A7E7C582BADFE04348E6FA985CBA19AFDE16FD740FF03857367C | | Certificates to be Issued | EV SSL/TLS Server Certificate | | Root CA | SecureSign Root CA14 | | Name of CA | Cybertrust Japan SureServer CA G7 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 167DDD4E7ABD348B6A105BC9CA24ACE745F2B6CB | | Validity Period of CA Certificate | June 22, 2020 to June 22, 2030 | | Signature Algorithm | SHA256 with RSA | | Key Size of CA | 2048 bit | | Hash value (SHA-1) | F9DDEC1E1FCF62CE4FAD04EDC44109A9504F4784 | | Hash value (SHA-256) | A2E2C3D73CFF96451325712E212FA15C40FD4F2C3F143C1BB619385365304C02 | | Certificates to be Issued | OV SSL/TLS Server Certificate | | Root CA | SecureSign Root CA12 | | Name of CA | Cybertrust Japan SureServer CA G8 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 4D8247384ADF541F88340F4928553224B6C48FE2 | | Validity Period of CA Certificate | June 22, 2020 to June 22, 2030 | | Signature Algorithm | ECDSA with SHA384 | | Key Size of CA | 384 bit | | Hash value (SHA-1) | A07043D2965389E4EF90EBEAEA319996A9877819 | | Hash value (SHA-256) | 93D931D5F95411998705B148532F4E16FBCF00F3318DFF9B6A0765ED749C8FD0 | | Certificates to be Issued | OV SSL/TLS Server Certificate | | Root CA | SecureSign Root CA15 | Subordinate CA (Technically Constrained) | Name of CA | JCSI TLSSign Public CA | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 7540ACF59D071D7A7ECAFC2FB965A7D11415CD53 | | Validity Period of CA Certificate | October 11, 2018 to August 8, 2029 | | Signature Algorithm | SHA256 with RSA | | Key Size of CA | 2048 bit | | Hash value (SHA-1) | 5E2ED0EDD013B5EF5EB2203FAAB6F876452FCEC2 | | Hash value (SHA-256) | 9253BFB668F3E743A525E48B5F750A8A66035F806297C25F8134DC8AC9635BD8 | | Certificates to be Issued | OV SSL/TLS Server Certificate | | Root CA | SecureSign RootCA11 (JCSI Root CA) | The CAs are compliant with the following requirements and laws and ordinances: 1. Cybertrust Japan Certification Practice Statement (This document and hereafter called "this CP/CPS.") 2. The requirements imposed on the CAs by the CA/Browser Forum, such as followings: - "Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates" (“BR”) disclosed at https://cabforum.org/working-groups/server/baseline-requirements/documents/; - "Guidelines For The Issuance And Management Of Extended Validation Certificates" ("EV Guidelines") disclosed at https://cabforum.org/extended-validation/; - "Network and Certificate System Security Requirements" disclosed at https://cabforum.org/working-groups/netsec/documents/ ; - Baseline Requirements for the Issuance and Management of Publicly‐Trusted S/MIME Certificates (SMBR) disclosed at https://cabforum.org/working-groups/smime/ (\*: They apply only to the certification authorities that issue SureMail Certificate.). 3. The requirements imposed on the CAs by the Application Software Supplier who includes the CA's root certificate(s) in its application software is registered, such as followings: - Mozilla Root Store Policy disclosed at https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/; - Program Requirements - Microsoft Trusted Root Program disclosed at https://learn.microsoft.com/en-us/security/trusted-root/program-requirements; - Chrome Root Program Policy disclosed at https://www.chromium.org/Home/chromium-security/root-ca-policy/; - Apple Root Certificate Program disclosed at https://www.apple.com/certificateauthority/ca_program.html; and 4. Laws of Japan that are applicable to the operations performed by the certification authority established in Japan. Cybertrust complies with the latest versions of the above requirements published by CA/Browser Forum at https://www.cabforum.org and the above requirements imposed on the CAs by the Application Software Supplier who includes the CA's root certificate(s) in its application software is registered. If there is any discrepancy between this CP/CPS and the requirements, the requirements shall prevail. The latest version of CP/CPS, and relevant documents may be found in the Cybertrust repository page. This CP/CPS prescribes the requirements for operating the CAs as well as the various requirements thereto issuing certificates. The requirements include obligations of the CAs, of subscribers, and of Relying Parties. Cybertrust shall adopt the RFC 3647 "Certificate Policy and Certification Practices Framework" set forth by the IETF PKIX Working Group upon specifying the various requirements in this CP/CPS. RFC 3647 is an international guideline that sets forth the framework for CP/CPS. In each provision of this CP, which is established based on the framework of RFC3647, matters that the CA does not perform are described as "Not applicable" while "No Stipulation" is used when there is no requirement for related provision. ## 1.2 Document name and identification The formal name of this CP/CPS shall be “Cybertrust Japan Certificate Policy/Certification Practice Statement for Public Server Certificate”. An object ID (OID) specific to this CP/CPS is assigned as following. | | | | :------------------------------------------------------------------------------------------------: | :-----------------: | | Document Name | OID | | Cybertrust Japan Certificate Policy/Certification Practice Statement for Public Server Certificate | 1.2.392.200081.1.32 | ## 1.3 PKI participants Cybertrust Japan Policy Authority (“CTJ PA”) determines policies such as this CP/CPS and appoints CA Supervisors set forth in “5.2.1 Trusted roles” of this CP/CPS. The following describes the parties related to the certificates issued by the CAs. Each party shall observe the obligations set forth in this CP/CPS. ### 1.3.1 Certification authorities The CAs set forth in the “1.1 Overview" of this CP/CPS. Each CAs consists of a Registration Authority and an Issuing Authority. Each CA is supervised by the CA Supervisor. #### 1.3.1.1 Issuing Authorities Each Issuing Authority of the Root CA is operated by Cybertrust, issues or revokes Subordinate CA certificates based on instructions from the RA of the Root CA. The Issuing Authorities also control the Private Key of the Root CAs based on this CP/CPS. Each Issuing Authority of the Subordinate CA is also operated by Cybertrust, issues or revokes subscriber certificates based on instructions from the RA. The Issuing Authority also controls the Private Key of the Subordinate CA based on this CP/CPS. ### 1.3.2 Registration authorities Each Registration Authority (“RA”) is operated by Cybertrust and accepts applications for subscriber certificates, and verifies the applications based on this CP/CPS. Based on the validation results, the RAs instruct corresponding Issuing Authorities to issue/revoke the subscriber certificates, or to dismisses the applications. The CAs do not delegate any of its RA operations including domain or email address control validation to any third parties. #### 1.3.2.1 Enterprise registration authorities Not applicable. ### 1.3.3 Subscribers Subscribers are organizations that apply for a certificate with either Subordinate CAs and use issued subscriber 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 SSL/TLS Server Certificate, an application supervisor indicates who authorized as roles for both of "Certificate Approver" and "Contract Signer" defined in "Guidelines For The Issuance And Management Of Extended Validation Certificates" ("EV Guidelines")). A subscriber must appoint an application supervisor among persons affiliated with the subscriber. Persons affiliated with the subscriber who may submit a certificate request to the Subordinate CAs shall be limited to the application supervisor, or a person in charge of application who is authorized by the application supervisor to submit a certificate request. (For the EV SSL/TLS Server Certificate, a person in charge of application indicates who authorized as roles of "Certificate requestor" defined in EV Guidelines.) The person in charge of application may be appointed among persons inside or outside of the subscriber. When the procedural manager is to be appointed from the outside, the procedural manager may be an individual or an organization. The procedural manager appointed among persons outside the subscriber may be defined as the "Applicant's Agent" in the Subscriber Agreement, etc. When the CA applies for and use the certificate for its own use, the CA also acts as a subscriber. ### 1.3.4 Relying parties Relying Parties are organizations or individuals verify the validity of the certificates of the CAs and subscribers and rely on the certificates based on own judgment. ### 1.3.5 Other participants Other parties include application software suppliers, and auditors.. ## 1.4 Certificate usage ### 1.4.1 Appropriate certificate uses Uses of certificate shall be as set forth in the table below. Matters in detail regarding each certificate of the CAs and subscribers are set forth in Appendix C.
Certificate Type  Use
EV SSL/TLS Server Certificate
  • Certificate of Server authentication (certification of the organization that uses the certificate and certification that the organization has the right to use the FQDN) issued in accordance with EV Guidelines.

OV SSL/TLS Server Certificate
  • Certificate of Server authentication (certification of the organization that uses the certificate and certification that the organization has the right to use the FQDN) issued in accordance with "Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Server Certificates" (“BR”).

Root Certificate
  • Certificate of Root CA that issues a Subordinate CA certificate.

  • Issuing a Certificate which is for the OCSP responder providing revocation information of the Subordinate CA certificates.

Subordinate CA certificate
  • Certificate of Subordinate CA that issues a subscriber certificate to subscriber.

  • Issuing a Certificate which is for the OCSP responder providing revocation information of the subscriber certificates.

OCSP Responder Certificate
  • Certificate used by the OCSP responder to digital signing to OCSP responses providing revocation information.

The Root CAs do not issue the Subordinate CA certificates to any third party. With the approval of Root CA Supervisor, each Root CA MAY issues an OCSP Responder Certificate that appends the digital signature to OCSP responses when the Root CA provides revocation information with regards to the corresponding Subordinate CA based on OCSP. Furthermore, with the approval of Subordinate CA Supervisor, each Subordinate CA MAY issues an OCSP Responder Certificate that appends the digital signature to OCSP responses when the Subordinate CA provides revocation information with regards to its subscriber certificates based on OCSP. ### 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 shall be prohibited. The certificates issued by Cybertrust do not guarantee that the Subject is trustworthy, reputable in its business, safe to do business with, compliant with any law nor that the equipment into which the certificate has been installed is free from defect, malware, or virus. The CAs merely certify that the reasonable means of verification for submitted information has been executed prior to certificate issuance. ## 1.5 Policy administration ### 1.5.1 Organization administering the document This CP/CPS and the Subscriber Agreement are administered by Cybertrust, which operates every CA described in this document. ### 1.5.2 Contact person Cybertrust accepts inquiries related to its services and this CP/CPS at the following contact information.
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 JST

Inquiries and complaints: As indicated below

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

  • Inquiries regarding this CP/CPS, etc.

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

servicedesk@cybertrust.ne.jp
  • Inquiries regarding request and application processes for certificate revocation.

  • Inquiries regarding certificate problems or upon discovery of fraudulent certificates.

  • Communication of other complaints.

  • An emergency contact and capable of response for 24 hours a day, 7 days a week

evc-report@cybertrust.ne.jp

(*)

(*) The existing contact, jcsi-r@cybertrust.ne.jp, which is used for the problem report on SecureSign RootCA11 is also available.

### 1.5.3 Person determining CP/CPS suitability for the policy The suitability of this CP/CPS is evaluated and determined by CTJ PA. ### 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. ## 1.6 Definitions and acronyms As prescribed in Appendix B of this CP/CPS. # 2\. PUBLICATION AND REPOSITORY RESPONSIBILITIES ## 2.1 Repositories Repositories of the CAs are controlled by Cybertrust. Publish the following information at https://www.cybertrust.ne.jp/ssl/repository_rt/index.html for 24 hours a day, 7 days a week. 1. this CP/CPS 2. Subscriber Agreement 3. other terms and conditions regarding the services of the CAs (the "Related Rules") ## 2.2 Publication of certification information Cybertrust publishes the following information in repositories accessible for 24 hours a day, 7 days a week. 1. Publish each CA Certificate information on following each URL. | The Root CA | URL | | -------------------- | -------------------------------------------------------------------------- | | SecureSign RootCA11 | http://rtcrl.managedpki.ne.jp/SecureSignAD/SecureSignRootCA11/SSAD-rca.crt | | SecureSign Root CA12 | http://rtcrl.cybertrust.ne.jp/SecureSign/rtca12/rtca12.crt | | SecureSign Root CA14 | http://rtcrl.cybertrust.ne.jp/SecureSign/rtca14/rtca14.crt | | SecureSign Root CA15 | http://rtcrl.cybertrust.ne.jp/SecureSign/rtca15/rtca15.crt | | The Subordinate CA | URL | | ------------------------------------ | -------------------------------------------------------------------------------- | | JCSI TLSSign Public CA  | http://rtcrl.managedpki.ne.jp/SecureSignAD/JCSITLSSignPublicCA/SSAD-JCSITLS.crt  | | Cybertrust Japan SureServer EV CA G7 | http://evcrl.cybertrust.ne.jp/SureServer/evcag7/evcag7.crt | | Cybertrust Japan SureServer EV CA G8 | http://evcrl.cybertrust.ne.jp/SureServer/evcag8/evcag8.crt | | Cybertrust Japan SureServer EV CA G9 | http://evcrl.cybertrust.ne.jp/SureServer/evcag9/evcag9.crt | | Cybertrust Japan SureServer CA G7 | http://sscrl.cybertrust.ne.jp/SureServer/ovcag7/ovcag7.crt | | Cybertrust Japan SureServer CA G8 | http://sscrl.cybertrust.ne.jp/SureServer/ovcag8/ovcag8.crt | 2. Publish each CRL on following each URL. | The Root CA | URL | | -------------------- | --------------------------------------------------------------------- | | SecureSign RootCA11 | http://rtcrl.managedpki.ne.jp/SecureSignAD/SecureSignRootCA11/cdp.crl | | SecureSign Root CA12 | http://rtcrl.cybertrust.ne.jp/SecureSign/rtca12/cdp.crl | | SecureSign Root CA14 | http://rtcrl.cybertrust.ne.jp/SecureSign/rtca14/cdp.crl | | SecureSign Root CA15 | http://rtcrl.cybertrust.ne.jp/SecureSign/rtca15/cdp.crl | | The Subordinate CA | URL | | ------------------------------------ | ----------------------------------------------------------------------- | | JCSI TLSSign Public CA | http://rtcrl.managedpki.ne.jp/SecureSignAD/JCSITLSSignPublicCA/cdp.crl  | | Cybertrust Japan SureServer EV CA G7 | http://evcrl.cybertrust.ne.jp/SureServer/evcag7/cdp.crl | | Cybertrust Japan SureServer EV CA G8 | http://evcrl.cybertrust.ne.jp/SureServer/evcag8/cdp.crl | | Cybertrust Japan SureServer EV CA G9 | http://evcrl.cybertrust.ne.jp/SureServer/evcag9/cdp.crl | | Cybertrust Japan SureServer CA G7 | http://sscrl.cybertrust.ne.jp/SureServer/ovcag7/cdp.crl | | Cybertrust Japan SureServer CA G8 | http://sscrl.cybertrust.ne.jp/SureServer/ovcag8/cdp.crl | 3. Publish test websites of Certificates that chain up to each Root CA Certificate at following URLs. | The Root CA | URL | | ----------------------- | ------------------------------------- | | SecureSign RootCA11(\*) | https://jcsi-expired.managedpki.ne.jp | | | https://jcsi-revoke.managedpki.ne.jp | | | https://jcsi-valid.managedpki.ne.jp | | SecureSign Root CA12 | https://ss12-expired.managedpki.ne.jp | | | https://ss12-revoked.managedpki.ne.jp | | | https://ss12-valid.managedpki.ne.jp | | SecureSign Root CA14 | https://ss14-expired.managedpki.ne.jp | | | https://ss14-revoked.managedpki.ne.jp | | | https://ss14-valid.managedpki.ne.jp | | SecureSign Root CA15 | https://ss15-expired.managedpki.ne.jp | | | https://ss15-revoked.managedpki.ne.jp | | | https://ss15-valid.managedpki.ne.jp | ## 2.3 Time or frequency of publication The timing and frequency of publication regarding the information to be published by CAs shall be as follows. These does not apply for the cases where repository maintenance or the like is required, but CRL shall be available 24 hours. 1. This CP/CPS, the Subscriber Agreement for each certificate, and the Related Rules 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 the CP for each certificate and then published. 3. The certificates of the Subordinate CAs shall be published at least during the effective period. 4. The Root CA Certificates shall be published at least during the operation period of each Root CA. ## 2.4 Access controls on repositories The CAs 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. Subscribers are identified based on the X.500 Distinguished Name ("DN") in the certificate. Need for names to be meaningful ### 3.1.2 Need for names to be meaningful > The name included in the DN of the subscriber’s certificates shall have the meaning of the subsequent paragraph. SSL/TLS Certificate
DN Item Meaning
Common Name

Complete host name of server or network device to use the certificate (FQDN or IP address)

Note: EV SSL/TLS Server Certificate does not include any IP address or Wildcard Domain Name starting with an asterisk (*) as Common Names

Organization Name of an entity 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

* Only for EV SSL/TLS Server Certificate

Information for identifying form of organization set forth in the EV Guidelines

Private Organization

Government Entity

(The Subordinate CAs do not issue a certificate to Business Entity or Non-Commercial Entity.)

Serial Number

* Only for EV SSL/TLS Server Certificate

For private organizations, indicate the corporate registration number

For government entities, indicate "The Subject is a Government Entity"

Jurisdiction of Incorporation State or Province

* Only for EV SSL/TLS Server Certificates where the Jurisdiction of Incorporation or Registration of the Subscriber is State, Province, or Locality.

Jurisdiction of Incorporation or Registration State or Province

Jurisdiction of Incorporation Locality

* Only for EV SSL/TLS Server Certificates where the Jurisdiction of Incorporation or Registration of the Subscriber is Locality.

Jurisdiction of Incorporation or Registration Locality

Jurisdiction of Incorporation Country

* Only for EV SSL/TLS Server Certificates

Jurisdiction of Incorporation or Registration Country
> Each of dNSName or iPAddress included in Subject Alternative Name extension of certificates shall have a meaning below.
Subject Alternative Names Meaning
dNSName

Complete host name of server or network device to use the certificate (FQDN).

Note: EV SSL/TLS Server Certificate does not include any Wildcard Domain Name starting with an asterisk (*) as Subject Alternative Names.

iPAddress

Complete IP address of server or network device to use the certificate.

Note: EV SSL/TLS Server Certificate does not include any IP address as Subject Alternative Names.

JCSI Certificate | | | | ------------------ | ---------------------------------------------------------------------------------------------------- | | DN Item | Meaning | | Common Name  | Name of a server or complete host name of server/network device that the certificate is used (FQDN)  | | Organization  | Name of organization of the Subscriber  | | Locality  | Address of business location of the Subscriber (locality)  | | State or Province  | Address of business location of the Subscriber (state or province)  | | Country  | Address of business location of the Subscriber (country)  | The name included in the DN of the certificate shall have the meaning of the subsequent paragraph. . | Subject Alternative Name | Meaning | | -------------------------- | -------------------------------------------------------------------------------- | | Subject Alternative Names  | Complete host name of server/network device that the certificate is used (FQDN)  | ### 3.1.3 Anonymity or pseudonymity of subscribers The Subordinate CAs do not accept any certificate request by anonymity or pseudonymity of subscribers. ### 3.1.4 Rules for interpreting various name forms Rules for interpreting the DN form of certificates issued by the CAs shall be pursuant to X.500. ### 3.1.5 Uniqueness of names A common name of each Subordinate CA issued by corresponding Root CA shall be unique value per each Root CA. The certificates issued by the Subordinate CAs can uniquely identify a subscriber based on the DN. ### 3.1.6 Recognition, authentication, and role of trademarks The Subordinate CAs do 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 Subordinate CA 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:jursidictionCountryName (OID: 1.3.6.1.4.1.311.60.2.1.3) with the data published by the relevant corporation establishment/registration agency before issuing EV SSL/TLS Server Certificate. 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 a Government Entity”. The list of corporate establishment/registration agency databases used by the Subordinate CAs 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 Subordinate CAs verify a 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 and Mailbox Authorization or Control”,”3.2.2.5 Authentication for an IP Address”, and “3.2.2.8 CAA Records” MUST be made from the CA to authoritative nameservers, i.e. without the use of recursive resolvers operated outside the CA's audit scope. All contact information for Domain Contacts MUST come from the WHOIS record, a DNS SOA record, or direct contact with the Domain Name Registrar of the Base Domain Name, and MUST be obtained directly by the CA, i.e. without the use of third-party services operated outside the CA's audit scope. All contact information for IP Address Contacts MUST be obtained through direct contact with the IP Address Registration Authority, i.e. without the use of any other third-party services operated outside the CA's audit scope. #### 3.2.2.1 Identity  The Subordinate CAs validate the organization identity included in a certificate as per the applicable verification process for the type of certificate before issuing a requested certificate. The Subordinate CAs do not issue a certificate to a natural person. For OV SSL/TLS Server Certificate, the organization identity shall be verified based on BR 3.2.2.1. For EV SSL/TLS Server Certificate, the organization identity shall be verified based on the EV Guidelines 3.2.2.2, 3.2.2.4, 3.2.2.6 ,and Appendix D-1 Japan. Details of the verification process are addressed in Appendix A. #### 3.2.2.2 DBA/Tradename  For OV SSL/TLS Server Certificate, when the organization name to be included in the subscriber's certificate is DBA/Tradename, the Subordinate CAs shall confirm as per BR 3.2.2.2. This shall be referred in Appendix A #### 3.2.2.3 Verification of Country  The Subordinate CAs validate Country which to be included in a certificate as per the applicable verification process for its type of certificate before issuing a requested certificate. For OV SSL/TLS Server Certificate, Country shall be verified based on BR 3.2.2.3 and 7.1.2.7.4. For EV SSL/TLS Server Certificate, Country shall be verified based on the EV Guidelines 3.2.2.4 and 7.1.4.2.6. Details of each validation methods shall be referred in Appendix A. #### 3.2.2.4 Validation of Domain and Mailbox Authorization or Control  The Subordinate CAs validate authorization or control of Domain which to be included in a certificate as per the applicable verification process for its type of certificate before issuing a requested certificate. However, the Subordinate CAs do not issue a certificate of a FQDN or an email address that contains ".onion" as the rightmost label. For OV SSL/TLS Server Certificate, authorization or control of Domain shall be verified based on BR 3.2.2.4. For EV SSL/TLS Server Certificate, authorization or control of Domain shall be verified based on the EV Guidelines 3.2.2.7. Note: Once the FQDN has been validated using this method, the Subordinate CA may also issue the Subscriber certificates for other FQDNs that end with all the domain labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. Details of each validation methods shall be referred in Appendix A. #### 3.2.2.5 Authentication for an IP Address  This section is applied only for OV SSL/TLS Server Certificate. The Subordinate CAs validate control of IP address as per BR3.2.2.5 before issuing a requested certificate. This shall be referred in Appendix A. The Subordinate CAs of SecureSign RootCA11 does not allow to issue the Subscriber certificate with an IPAddress under its hierarchy and it does not allow specifying an IPAddresses within the NameConstraints extension in the Subordinate CA certificate. #### 3.2.2.6 Wildcard Domain Validation  This section is applied only for OV SSL/TLS Server Certificate. Before issuing a Certificate with a Wildcard Domain Name starting with an asterisk (\*) in the common name and subjectAltName dNSName, the Subordinate CAs MUST establish and follow a documented procedure that determines if the FQDN portion of any Wildcard Domain Name in the Certificate is “registry-controlled” or is a “public suffix” (e.g. “\*.com”, “\*.co.jp”, see RFC 6454 Section 8.2 for further explanation). Determination of “registry-control" shall be based on Section 3.2.2.6 of the BR. If the FQDN portion of any Wildcard Domain Name is “registry-controlled” or is a “public suffix”, the Subordinate CAs MUST refuse issuance unless the Applicant proves its rightful control of the entire Domain Namespace. (e.g. the Subordinate CAs MUST NOT issue “\*.co.jp” or “\*.local”, but MAY issue “\*.example.com” to Example Co.). The Subordinate CAs of SecureSign RootCA11 does not allow to issue the Subscriber certificate with an Wildcard Domain Name under its hierarchy and it does not allow specifying an Wildcard Domain Name within the NameConstraints extension in the Subordinate CA certificate. #### 3.2.2.7 Data Source Accuracy Before using a data source as a reliable data source, the Subordinate CA evaluate the source for its reliability, accuracy, and resistance to alteration or falsification. For OV SSL/TLS Server Certificate, the reliability of the data source shall be verified based on BR 3.2.2.7. For EV SSL/TLS Server Certificate, the reliability of the data source shall be verified based on the EV Guidelines 3.2.2.11. Databases maintained by the CAs, Cybertrust, or its affiliated companies must be independent from the CAs. 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 validation of the CAs. Unqualified data source MUST NOT be used by the CAs. #### 3.2.2.8 CAA Record (Certification Authority Authorization Record) Procedures  For SSL/TLS Certificate, the Subordinate CAs retrieve and process the CAA Record for each dNSName in the subjectAltName extension, based on RFC8659 (DNS CA Authorization (CAA) Resource Record) and section 3.2.2.8 of the BR. In addition, on-or-after September 15, 2024, the Subordinate CAs that issue certificates 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 Subordinate CAs 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 Subordinate CAs process the issue, issuewild, and iodef property tags as specified in RFC 8659. The Subordinate CAs do not issue a certificate if they encounter an unrecognized property tag with this critical flag set. For certificates issuance, the Subordinate CAs verify 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 Subordinate CAs are permitted to treat a CAA record lookup failure as permission to issue if: - the cause of the failure is outside the Subordinate CA’s infrastructure; and - the lookup has been retried at least once; and - the domain’s zone does not have a DNSSEC validation chain to the ICANN root. The Subordinate CAs document certificate issuances that were prevented by a CAA record in detail to provide feedback to the CA/Browser Forum. Additionally, the Subordinate CAs MAY not report to the contact specified in CAA iodef record. If the CAA record (issue/issuewild) contains any of the values listed in section 4.2.1 of this CP, the Subordinate CAs recognize that it is designated as it is permitted issuing certificates. For certificates issuance, the Subordinate CAs shall confirm the CAA within the TTL of the CAA record, or 8 hours, whichever is greater. If the Certificate includes more than one email address, then the Subordinate CAs shall perform to retrieve and process CAA records for each email address. The Subordinate CAs shall not issue a Certificate unless the Subordinate CAs determine that the values contained in the issuemail property tag is consistent with the values listed in ”4.2.1 Performing identification and authentication functions" of this CP. The Subordinate CAs shall log all actions taken, if consistent with its CAA processing practice. The Subordinate CAs are permitted to treat a CAA record lookup failure as permission to issue if: - the cause of the failure is outside the Subordinate CAs' infrastructure; and - the lookup has been retried at least once; and - the domain's zone does not have a DNSSEC validation chain to the ICANN root. The Subordinate CAs of SecureSign RootCA11 does not process the validation on CAA based on BR "3.2.2.8 CAA Records" since The Subordinate CAs of SecureSign RootCA11does not own a Subordinate CA which is not Technically Constrained and the validation on CAA is optional for Technically Constrained Subordinate CA. #### 3.2.2.9 Multi-Perspective Issuance Corroboration  On-or-after September 15, 2024, the Subordinate CAs that issue certificates implement Multi-Perspective Issuance Corroboration based on Section 3.2.2.9 of the BR. The Subordinate CAs 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 Subordinate CA's authority to issue to the requested domain(s), as specified in Section 3.2.2.8 of this CP. The Subordinate CAs 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.2.10 TLS Using a Random Value  The CAs do not adopt this method set forth in BR 3.2.2.4.10. #### 3.2.2.11 Any Other Method  The CAs shall not use this method set forth in BR 3.2.2.4.11. #### 3.2.2.12 Validating Applicant as a Domain Contact  The CAs do not adopt this method set forth in BR 3.2.2.4.12. #### 3.2.2.13 Email to DNS CAA Contact  The CAs do not adopt this method set forth in BR 3.2.2.4.13. #### 3.2.2.14 Email to DNS TXT Contact  The CAs do not adopt this method set forth in BR 3.2.2.4.14. #### 3.2.2.15 Phone Contact with Domain Contact  The CAs confirm the Applicant's control over the FQDN by calling the Domain Contact’s phone number and obtain a confirming response to validate the Authorization Domain Name. Each phone call may confirm control of multiple Authorization Domain Names provided that the same Domain Contact phone number is listed for each Authorization Domain Name being verified and they provide a confirming response for each Authorization Domain Name. In the event that someone other than a Domain Contact is reached, the CAs may request to be transferred to the Domain Contact. In the event of reaching voicemail, the CAs may leave the Random Value and the Authorization Domain Name(s) being validated. The Random Value must be returned to the CAs 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. Note: Once the FQDN has been validated using this method, the Subordinate CA may also issue the Subscriber certificates for other FQDNs that end with all the domain labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. #### 3.2.2.16 Phone Contact with DNS TXT Record Phone Contact  The CAs confirm the Applicant's control over the FQDN by calling the DNS TXT Record Phone Contact’s phone number and obtain a confirming response to validate the Authorization Domain Name. 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 verified and they provide a confirming response for each Authorization Domain Name. The CAs 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 CAs may leave the Random Value and the Authorization Domain Name(s) being validated. The Random Value must be returned to the CAs 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. Note: Once the FQDN has been validated using this method, the Subordinate CA may also issue the Subscriber certificates for other FQDNs that end with all the domain labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. #### 3.2.2.17 Phone Contact with DNS CAA Phone Contact   The CAs do not adopt this method set forth in BR 3.2.2.4.17. #### 3.2.2.18 Agreed‐Upon Change to Website v2  The CAs Confirm 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. The CAs 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, and 2. MUST be located under the "/.well-known/pki-validation" directory, and 3. MUST be retrieved via either the "http" or "https" scheme, and 4. MUST be accessed over an Authorized Port. If the CAs 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. The CAs 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. However, the Subordinate CA with nameConstraints shall not adopt Request Token. Note: The Subordinate CA shall not issue certificates for different FQDNs that end with all the labels of the validated FQDNs, unless the Subordinate CA processes another validation. This method does not apply to the validation of a Wildcard Domain Names. #### 3.2.2.19 Agreed‐Upon Change to Website - ACME  The CAs do not adopt this method set forth in BR 3.2.2.4.19. #### 3.2.2.20 TLS Using ALPN  The CAs do not adopt this method set forth in BR 3.2.2.4.20. ### 3.2.3 Authentication of individual identity The Subordinate CAs do not issue a certificate to a natural person who are specified in BR 3.2.3. ### 3.2.4 Non-verified subscriber information The Subordinate CAs do not include non-verifying subscriber information in certificates as specified in BR 3.2.4. ### 3.2.5 Validation of authority The Subordinate CA shall verify, as per the applicable verification process for its type of certificate, that the application supervisor employed by the Subscriber organization and that the application supervisor is authorized to apply the application for issuance of certificates on behalf of Subscribers. For OV SSL/TLS Server Certificate, the authority shall be verified based on BR 3.2.5. For EV SSL/TLS Server Certificate, the authority shall be verified based on the EV Guidelines 3.2.2.8 and 3.2.2.9. Details of each validation methods shall be referred in Appendix A. The Subordinate CAs allow an Applicant to specify the individuals who may request Certificates. If an Applicant specifies, in writing, the individuals who may request a Certificate, then the CA SHALL NOT accept any certificate requests that are outside this specification. The CA SHALL provide an Applicant with a list of its authorized Certificate Requesters upon the Applicant’s verified written request. ### 3.2.6 Criteria for interoperation The CAs do not operate interoperation. ## 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.2Initial identity validation" of this CP/CPS shall apply correspondingly. However, when it is verified that the certification information and expiration date with the reissuance application coincide with the certificate of the re-issuer, verification 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 Subordinate CAs receive a revocation request from a subscriber via email or in the method indicated on Cybertrust’s website(The Subordinate CAs of SecureSign RootCA11 case is only via email), the Subordinate CAs 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, each Subordinate CA shall compare the information notified upon application for issuance of a certificate and the information only known between the Subordinate CA and the subscriber which are presented for verification. If verified, the Subordinate CA revokes the certificate. 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 Subordinate CAs process 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 Subordinate CAs shall survey the reason of revocation and verify with the subscriber of the certificate if necessary. Each Subordinate CA verifies the result of survey and revoke the certificate if the revocation reason is found corresponding any of events set forth in the Subscriber Agreement. The email address to be used for the revocation request is indicated in "16+1 and 2256-1. The modulus SHOULD also have the following characteristics: an odd number, not the power of a prime, and have no factors smaller than 752. [Source: Section 5.3.3, NIST SP 800-89]. ECC: The CA SHOULD confirm the validity of all keys using either the ECC Full Public Key Validation Routine or the ECC Partial Public Key Validation Routine. [Source: Sections 5.6.2.3.2 and 5.6.2.3.3, respectively, of NIST SP 56A: Revision 2] In generating the key pair of the CAs, the hardware that satisfies the standards of FIPS 140-2 or FIPS 186-2 shall be used. ### 6.1.7 Key usage purposes (as per X.509 v3 key usage field) The key usage of the Root CA Certificate shall be Certificate Signing, CRL Signing. The key usage of certificates shall be Digital Signature and Key Encipherment for RSA, and Digital Signature for ECC. The key usage of certificates for use in the CA's OCSP responder shall be Digital Signature. The Private Keys of the Root CA Certificates must not be used except for signing in the following cases: 1. Self-signed Certificates to represent the Root CA itself; 2. Certificates for Subordinate CAs and Cross Certificates; 3. Certificates for infrastructure purposes of the CA; 4. CRL published by the Root CA; and 5. Certificates used for OCSP Response provided by the Root CA. ## 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 CAs shall be the HSM that satisfies the at least FIPS 140-2 Level 3 standard. The HSM shall be controlled by the Issuing Authority. The key pair used in an OCSP Responder is controlled based on the HSM that satisfies the at least 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 CA and an OCSP Responder shall at all times be controlled by multiple Issuing Authority System Administrators. ### 6.2.3 Private key escrow The CA does not escrow the Private Key of the CA, subscribers and an OCSP Responder. ### 6.2.4 Private key backup The Issuing Authority System Administrator shall back up the Private Key of the CA. 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 CA 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 CA to the backup site based on a safe method. When it is necessary to restore the Private Key of the CA 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, there may be cases where the corresponding certificate is revoked, and a Private Key is newly generated based on the approval of the CA Supervisor. ### 6.2.7 Private key storage on cryptographic module The Private Keys used by the CAs shall be stored in the HSM that satisfies the standards of at least FIPS 140-2 Level 3. The Private Key used by the OCSP Responder shall be stored in the HSM that satisfies the standards of at least FIPS 140-2 Level 3. ### 6.2.8 Method of activating private key The Private Key used by the CA 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 CA 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 CA 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 CA 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 CA 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 each certificate shall be as per the following table. | Type | Private Key | Maximum Validity Period of Certificate | | ------------------------------ | ------------- | -------------------------------------- | | Certificates of Root CA | Not specified | 25 years 1month | | Certificates of Subordinate CA | Not specified | 16 years 1month | | EV SSL/TLS Server Certificates | Not specified | 397 days | | OV SSL/TLS Server Certificates | Not specified | 397 days | | OCSP Responder Certificates | Not specified | 25 months | ## 6.4 Activation data ### 6.4.1 Activation data generation and installation The activation data used by the CA shall be generated and set upon giving consideration so that it cannot be easily speculated. Cybertrust activates the cryptographic module containing its CA Private Keys according to the specifications of the hardware manufacturer. This method has been evaluated as meeting the requirements of at least FIPS 140-2 Level 3. The cryptographic hardware is held under two-person control as explained in Section 5.2.2. Cybertrust will only transmit activation data via an appropriately protected channel and at a time and place that is distinct from the delivery of the associated cryptographic module. All Cybertrust personnel are instructed to use strong passwords and to protect PINs and passwords that meet the requirements specified by the CAB Forums Network Security Requirements. ### 6.4.2 Activation data protection The activation data used in the CA 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 CAs shall enforce multi-factor authentication for all accounts capable of directly causing certificate issuance. In addition to the above, the CA 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 CA. 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 establishment and modification of the CA 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, verification which is indispensable and competent shall be carried out in a testing environment to verify that there are no security-related problems. ### 6.6.2 Security management controls The CA system shall undergo necessary settings in order to ensure competent security. In addition to implementing entrance/exit control, 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 CA 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 CA manages network security in compliance with the Network and Certificate System Security Requirements set forth by the CA/Browser Forum. The CA'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. Provided that, the Root CA system shall not be connected to a network and shall be operated offline. ## 6.8 Time-stamping All logs contain synchronized timestamp 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 Cybertrust uses the ITU X.509 version 3 standard to construct digital Certificates. ### 7.1.1 Version number(s) Cybertrust issues X.509 version 3 Certificates. ### 7.1.2 Certificate extensions The CAs use certificate extensions in accordance with applicable industry standards, including RFC 5280. The CAs do 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 CA 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; 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. For JCSI, Technically Constrained Subordinate CA certificates shall include, in Extended Key Usage extension, all extended key usages for which the Subordinate CA certificate is authorized to issue certificates. The anyExtendedKeyUsage KeyPurposeId shall not appear in the ExtendedKeyUsage extension of publicly trusted certificates. The subscriber certificates:must also contain an ExtendedKeyUsage extension; 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. For SSL/TLS Certificates, the subjectAltName extension is populated in accordance with RFC 5280. The SubjectAltName extension is populated with the authenticated value of the domain name in the Common Name field of the subject DN (either domain name or public iPAddress applicable). 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. For S/MIME Certificate also, the subjectAltName extension is populated in accordance with RFC 5280 as well. The authorized email address is included in subjectAltName extension. Cybertrust generates non-sequential Certificate serial numbers (positive numbers greater than zero) that contain at least 64 bits of output from a CSPRNG. Matters regarding the CA Certificate, the Subscriber Certificate, and OCSP responders Certificate are set forth in Appendix C. 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 | | ECDSA key | id-ecPublicKey | 1.2.840.10045.2.1 | | namedCurve parameter for P-256 key | secp256r1 | 1.2.840.10045.3.1.7 | | namedCurve parameter for P-384 key | secp384r1 | 1.3.132.0.34 | #### 7.1.3.2 signatureAlgorithm | Type | algorithm identifier | OID | | ----------------- | ----------------------- | --------------------- | | SHA256 with RSA | sha256WithRSAEncryption | 1.2.840.113549.1.1.11 | | SHA384 with RSA | sha384WithRSAEncryption | 1.2.840.113549.1.1.12 | | ECDSA with SHA384 | ecdsa-with-SHA384 | 1.2.840.10045.4.3.3 | Matters regarding the certificates of the CA and subscribers are set forth in Appendix C. Note that the Root CA shall not issue any Subordinate CA certificates using the SHA-1 hash algorithm, and neither Subordinate CAs issue any subscriber certificates using the SHA-1 hash algorithm. ### 7.1.4 Name forms The CAs use 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. The Root CAs shall not allow including organization unit (OU) attribute in the Subordinate CA certificates. For OV SSL/TLS Server Certificates, the subjectAltName extension must be present and contain at least one FQDN or IP address , and those shall be validated based on section 3.2.2.4 or 3.2.2.5 of this CP/CPS. For EV SSL/TLS Server Certificates, the subjectAltName extension must be present and contain at least one FQDN, and it shall be validated based on section 3.2.2.4 of this CP/CPS. Also, Common Name and the subjectAltName in SSL/TLS Certificates cannot contain internal names or reserved IP addresses. The CAs do not allow containing only metadata such as '.', '‐', and ’ ’ (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable as a value in certificates. Matters regarding the certificates of the CA and subscribers are set forth in Appendix C. As for EV SSL/TLS Server Certificates, the CA shall not include any Subject Distinguished Name attributes besides the ones specified in section 7.1.4.2 of the EV Guidelines. Matters regarding the certificates of the CA and subscribers are set forth in Appendix C. ### 7.1.5 Name constraints Not applicable. ### 7.1.6 Certificate policy object identifier When the CAs issue a Certificate containing one of the policy identifiers, it asserts that the Certificate is managed in accordance with the policy that is identified herein. | Name of Policy | Object Identifier | | ---------------------------------------------------------------- | ---------------------- | | SureServer EV Certificate Policy (EV SSL/TLS Server Certificate) | 1.2.392.200081.1.32.1 | | SureServer Certificate Policy (OV SSL/TLS Server Certificate) | 1.2.392.200081.1.32.2 | | OCSP Certificate Policy | 1.2.392.200081.1.32.20 | | CABF Extended Validation EV Certificate Policy | 2.23.140.1.1 | | CABF Organization Validated OV Certificate Policy | 2.23.140.1.2.2 | Details regarding the certificates of each CA and subscribers are set forth in Appendix C. ### 7.1.7 Usage of Policy Constraints extension Not applicable. ### 7.1.8 Policy qualifiers syntax and semantics The CA may include Policy Qualifier field in the Certificate Policy extension, and may include brief statements in that Policy Qualifier field. This Policy Qualifier field may contain the URI that points to the CP/CPS applied to the certificate. Matters regarding the certificates of the CA and subscribers are set forth in Appendix C. ### 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, CAs MUST omit reasonCode entry extension. The CRLReason for subscriber certificates must indicate one of following reason codes which is the most appropriate reason for revocation of the certificate listed in RFC5280, section 5.3.1 unless a CRLReason is unspecified. If the certificate is revoked for none of the reasons listed below, the CA does not provide the reason Code CRL entry extension. For SSL/TLS Certificates, The CA provides certificate subscribers, in the subscriber agreement, the options and explanation about when to choose each option on the revocation reason. 1. keyCompromise, 2. privilegeWithdrawn, 3. affiliationChanged, 4. superseded, 5. cessationOfOperation, Additionally, the CA may specify following revocation reason in the case of CA certificates revocation with the reasonCode CRL entry extension existed. 1. cACompromise ### 7.2.1 Version number(s) The CAs issue version 2 CRLs that conform to RFC 5280. Matters regarding the CRL issued by this CA are set forth in Appendix C of this CP/CPS. ### 7.2.2 CRL and CRL entry extensions Matters regarding the CRL issued by this CA are set forth in Appendix C of this CP/CPS. ## 7.3 OCSP profile Issuer CAs shall operate an OCSP service in accordance with RFC 6960. For SSL/TLS Certificate, if an OCSP response is for a Root CA or Subordinate CA Certificate, including Cross Certificates, and that certificate has been revoked, then the revocationReason field within the RevokedInfo of the CertStatus shall be present and asserted. For SSL/TLS Certificate, 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 CA is annually audited by the qualified outside auditor with the appropriate WebTrust Principles and Criteria formulated by CPA Canada, accordingly to the certificate type. A visiting audit may additionally be performed on the CA by qualified outside auditor at the times CTJPA deemed necessary. ## 8.2 Identity/qualifications of assessor The qualified auditor performing the external audit on the CA shall be independent from the CA. ## 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 CA 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. The CA shall be audited with the appropriate criteria correspondingly to the certificate type. ## 8.5 Actions taken as a result of deficiency Identified matters that are discovered in the verification are reported to CTJ PA, the CA Supervisor, the Issuing Authority Manager, and the RA Manager. When the auditor, CTJ PA, or the CA 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 a copy of the audit results. Copies of Cybertrust’s WebTrust for CAs audit reports can be found at: https://www.cybertrust.ne.jp/ssl/repository_rt/index.html. On an annual basis and within three months of completion, Cybertrust submits copies of relevant audit compliance reports to the Application Software Supplier who includes the CA's root certificate(s) in its application software. ## 8.7 Self-Audits On at least a quarterly basis, the Subordinate CAs that issue SSL/TLS Certificates perform regular internal audits against a randomly selected sample of the greater of one certificate or at least three percent of subscriber certificates since the last internal audit. In addition, on-or-after March 15, 2025, the Subordinate CAs that issue SSL/TLS Certificates use 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 Subordinate CA are notified so that a subscriber can properly verify the same such as by posting on Cybertrust's website or submitting a quotation. If there is any discrepancy between the description on Cybertrust's website and the description in the quotation separately submitted by Cybertrust, the descriptions of the quotation shall prevail. Moreover, if the Subordinate CA is requested by a subscriber to reissue a certificate based on the following reasons, the Subordinate CA shall reissue a certificate that is valid for the remaining period, free of charge so 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 at the time of application was unintentionally erased or damaged; 2. the original SSL/TLS Certificate cannot be used due to server replacement; 3. the password required for downloading a SSL/TLS Certificate based on “4.4.1Conduct constituting certificate acceptance" of this CP/CPS is lost; or 4. the Subordinate CA 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 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 CA. Cybertrust shall also take out appropriate insurance for covering its indemnity liability. ### 9.2.1 Insurance coverage In addition to “9.2 Financial responsibility” of this CP/CPS, The CA SHALL maintain the following 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 CA does not apply the self‐insure because conditions allowed in EV Guideline are inapplicable. ### 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 CA. ### 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, the Subordinate CA Certificate, and the Root CA 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 during 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 a 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 CA using the personal information of that subscriber for performing its certificate issuance/revocation operations that are scheduled in this CP/CPS and the CA 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 during 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 CA service: 1. certificates issued by the CA and certificate revocation information; 2. this CP/CPS, and related documents; 3. public key and Private Key of the CA; and 4. hardware and software leased by the CA. ## 9.6 Representations and warranties Shall be defined in “9.6 Representations and warranties" of this CP/CPS. ### 9.6.1 CA representations and warranties Cybertrust represents and warrants that it bears the following obligations upon performing its operations. - to comply with Relevant Requirements, this CP/CPS. - to safely control the CA Private Key. - to monitor and operate the system. Cybertrust represents and warrants following obligations at the time of issuance. 1. Right to Use Domain Name, IP Address, or email address The CAs 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) for SSL/TLS Certificate or email address for S/MIME Certificate listed in the Certificate’s subject field and subjectAltName extension, and accurately describe the procedure in this CP/CPS. 2. Authorization for Certificate The CAs 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 describe the procedure in this CP/CPS. 3. Accuracy of Information The CAs implemented and followed a procedure for verifying the accuracy of all of the information contained in the Certificate, and accurately describe the procedure in this CP/CPS. 4. Identity of Applicant The CAs 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 TLSBR for SSL/TLS Certificate or with Section 3.2 and Section 7.1.4.2.2 of the SMBR for S/MIME Certificate, and accurately describe the procedure in this CP/CPS. For the EV SSL/TLS Server Certificate, the CAs have confirmed that, as of the date the EV SSL/TLS Server Certificate was issued, the legal name of the Subject named in the EV SSL/TLS Server 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 the CAs 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 CAs maintain for 24 hours a day, 7 days a week publicly‐accessible Repository with current information regarding the status (valid or revoked) of all unexpired certificates. 7. Revocation That the CAs revoke the certificate for any of the reasons specified in this CP/CPS, Subscriber Agreement, or relevant requirements. 8. Legal Existence For the EV SSL/TLS Server Certificate, the CAs have confirmed with the Incorporating or Registration Agency in the Subject’s Jurisdiction of Incorporation or Registration that, as of the date the EV SSL/TLS Server Certificate was issued, the Subject named in the EV SSL/TLS Server Certificate legally exists as a valid organization or entity in the Jurisdiction of Incorporation or Registration. ### 9.6.2 RA representations and warranties Cybertrust represents and warrants that it bears the following obligations upon performing operations as the RA: 1. Perform validation 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 upon using the service provided by the CA. A subscriber represents and warrants following obligations. 1. Accuracy of Information An obligation and warranty to provide correct and accurate information at all times to the CA, both in the certificate request and as otherwise requested by the CA in connection with the issuance of the Certificate(s) to be supplied by the CA. 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 requested Certificate(s) (and any associated activation data or device, e.g. password or token). 3. Acceptance of Certificate An obligation and warranty that the Subscriber will review and verify the Certificate contents for accuracy. 4. Use of Certificate For SSL/TLS Certificate, an obligation and warranty to use the certificate according to the law and regulations and the Subscriber Agreement. For S/MIME Certificate, an obligation and warranty to use the Certificate only on email address listed in the Certificate, and to use the Certificate solely in compliance with all applicable laws and solely in accordance with 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 using the Private Key corresponding to the Public Key listed in a Certificate upon expiration or revocation of the Certificate. 7. Responsiveness An obligation and warranty to respond to the CA's instruction within a specified period upon the occurrence of a revocation reason such as Private Key compromise or certificate misuse set forth in the Subscriber Agreement. 8. Acknowledgment and Acceptance An obligation and warranty to acknowledge and accept that the CA is entitled to revoke the certificate immediately if the Applicant were to violate the terms of the Subscriber Agreement or if revocation is required by this CP/CPS, or relevant requirements set forth by CA/Browser Forum. A subscriber also represents and warrants followings; - to 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 CA deems necessary for the validation, - to comply with appropriate usage of certificates and Private Keys, - to refrain from using the certificate in websites or in email that are contrary to public order and morals, - to 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, - to immediately request revocation of the certificate to the CA upon the occurrence of an event set forth in the Subscriber Agreement, - to refrain from using an expired certificate or a revoked certificate, - to observe applicable laws and regulations, and - to respond to all the inquiries on information of their Certificate requests or the status of Certificate use which the CA asks to the Subscribers. - to notify the CA when the Subscriber terminate using certain services. ### 9.6.4 Relying party representations and warranties A Relying Party represents and warrants that it bears the following obligations: 1. to confirm that the certificates are being used for the usage set forth in "1.4.1 Appropriate certificate uses" of this CP/CPS; 2. to confirm the effective period and entries of certificates issued by the Subordinate CA; 3. to verify the digital signature and verify the issuer of the certificate; 4. to confirm whether the certificate has been revoked based on CRL or OCSP; and 5. to 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 CA 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 CA shall not be liable in any way for the consequences resulting from a Relying Party trusting the certificates of the CA 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 CAs observing this CP/CPS, 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.6Representations and warranties" of this CP/CPS; 4. damage that arises as a result of the key pair of the certificate issued by the Subordinate CA 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](http://www.cybertrust.ne.jp/SureServer/cps/cps53.html#BTJ#BTJ) against [subscribers](http://www.cybertrust.ne.jp/SureServer/cps/cps53.html#Subscriber#Subscriber) and [Relying Parties](http://www.cybertrust.ne.jp/SureServer/cps/cps53.html#RelyingParty#RelyingParty) 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 CA shall not exceed 10,000,000 yen under no circumstances whatsoever (provided, however, that the CA, for EV SSL/TLS Server Certificate, 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](http://www.cybertrust.ne.jp/SureServer/cps/cps53.html#DigitalSignature#DigitalSignature), 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 CA 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 Subordinate CA, that subscriber or 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 Subordinate CA 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 CA, 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 followings: 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 verifying and displays a certificate as trustworthy, despite the certificate is expired or a revoked and the revocation status is provided and available online by the CAs. ## 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 CA 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 postal 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. Cybertrust will notify the Application Software Suppliers in advance that requires notification of each matter, if any of the matters listed below occur: 1. Ownership or control of the CA certificates changes; 2. The Subordinate CA certificates which are not technically constrained and are directly or transitively chaining up to any Cybertrust Certificates, included in root store (e.g., stipulated in section 5.3 of Mozilla Root Store Policy) are controlled by an organization other than the CA; 3. Ownership or control of Cybertrust's operations changes; or 4. There is a material change in Cybertrust’s operations (e.g., when the cryptographic hardware related to a certificate in Mozilla's root store is consequently moved from one secure location to another). 5. Termination of CA operations ## 9.12 Amendments ### 9.12.1 Procedure for amendment The CA shall review and update this CP/CPS at least once in 365 days, incrementing the version number and adding a dated changelog entry. This CP/CPS may be amended if needed based on CTJ PA’s instruction. CTJ PA shall approve the amendment after obtaining the evaluation of the CA 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 implement measures to post the 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 to decide if the OID updates are required correspondingly to this CP/CPS change. ## 9.13 Dispute resolution provisions All disputes arising in relation to this CP/CPS, the certificates issued by the CAs to which the CP/CPS for each certificate 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 the 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 its CP/CPS in accordance with the procedures specified in section 9.16.3 of applicable requirements. ### 9.16.4 Enforcement (attorneys’ fees and waiver of rights) The CAs may seek indemnification and attorneys' fees from a party for damages, losses, and expenses related to that party's conduct. Cybertrust’s failure to enforce a provision of this CP/CPS does not waive Cybertrust’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 Cybertrust. ### 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 CAs, 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: Verification Requirements for Subscriber Certificate > Verification Items for OV SSL/TLS Server Certificate
Item Method
Identity

The Subordinate CA shall use, based on section 3.2.2.1 of the BR, public documents and data, the documents and data provided by a third party that is deemed reliable by the Subordinate CA, 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 verification as required.

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.

DBA/Tradename When the organization name to be included in the subscriber's certificate is DBA/Tradename, this Subordinate CA 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 Subordinate CA, based on Section 3.2.2.2 of the BR.
Verification of Country This Subordinate CA confirms the Country included in the subscriber's certificate based on applicable requirements such as 3.2.2.3 and 7.1.2.7.4 of the BR. In which process, the method for "Verification of Identity " defined in Appendix A for OV SSL/TLS Server Certificate is equally applied.
Validation of Domain Authorization or Control

The Subordinate CA shall validate, prior to issuance, the subscriber’s authorization or control of the FQDN or the domain name in accordance with applicable requirements such as Section 3.2.2.4 of the BR.

The Subordinate CA validates each Fully‐Qualified Domain Name (FQDN) or the domain name listed in the certificate using at least one of the methods listed below. Provided that, the Subordinate CA does not issue any certificate for a FQDN of which the rightmost label end with “.onion”.

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 certificate issuance. For purposes of domain name validation, the term “Subscriber” includes the Subscriber's Parent Company and Subsidiary Company.

The Subordinate CA SHALL maintain a record of which domain validation method, including relevant BR version number, was used to validate every domain for issuance.

Note: FQDNs for certificates may be listed in subscriber certificates using dNSNames in the subjectAltName extension or in Subordinate CA Certificates via dNSNames in permitted Subtrees within the Name Constraints extension.

If a Random Value is used for any of the methods below, the Subordinate CA SHALL provide a Random Value unique to the certificate request and shall not use the Random Value after 30 days from its creation. If there is validated information available for this process, it MUST not be used later than the time frame set forth in BR section 4.2.1.

The Random Value SHALL be unique in each email, fax, SMS, or postal mail when the Random value is informed via these manners.

The Subordinate CA MAY resend the email, fax, SMS, or postal mail including reuse of Random Value when the FQDNs and/or domain name is validated with the method with these communication manners, provided that the communications content and recipients remain unchanged.

Once the FQDN or the domain name has been validated using these methods except method #8 or #18, the Subordinate CA MAY also issue certificates for other FQDNs that end with all the labels of the validated FQDN or domain name. This rule also applies to applications for a wildcard domain name of OV SSL/TLS Server Certificate.

This Subordinate CA does not adopt Request Token.

#1: Validating the Applicant as a Domain Contact (BR 3.2.2.4.1)

The Subordinate CA does not use this method.

#2: Email, Fax, SMS, or Postal Mail to Domain Contact (BR 3.2.2.4.2)

The Subordinate CA confirms the Subscriber's authorization or control of the FQDN or the domain name by sending a Random Value via email, fax, SMS, or postal mail and then receiving a confirming response containing the Random Value. The Random Value MUST be sent to the email address, fax/SMS number, or postal mail address identified as a Domain Contact.

Each email, fax, SMS, or postal mail MAY confirm control of multiple Authorization Domain Names.

The Subordinate CA MAY send the email, fax, SMS, or postal mail identified under this section to more than one recipient provided that every recipient is identified by the Domain Name Registrar as representing the Domain Name Registrant for every FQDN being verified using the email, fax, SMS, or postal mail.

#3: Phone Contact with Domain Contact (BR 3.2.2.4.3)

The Subordinate CA does not use this method.

#4: Constructed Email to Domain Contact (BR 3.2.2.4.4)

The Subordinate CA sends 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 or the domain name is examined by receiving a response containing the Random Value.

#5: Domain Authorization Document (BR 3.2.2.4.5)

The Subordinate CA does not use this method.

#6: Agreed‐Upon Change to Website (BR 3.2.2.4.6)

The Subordinate CA does not use this method.

#7: DNS Change (BR 3.2.2.4.7)

The Subordinate CA SHALL examine the Subscriber's authorization or control of the FQDN or the domain name by confirming the presence of a Random Value 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.

On-or-after September 15, 2024, the Subordinate CA 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.

#8: IP Address (BR 3.2.2.4.8)

The Subordinate CA SHALL examine the Subscriber's authorization or control of the FQDN or domain name by confirming that the Subscriber controls an IP address returned from a DNS lookup for A or AAAA records for the FQDN or domain name in accordance with Section 3.2.2.5 of the BR or this CP.

On-or-after September 15, 2024, the Subordinate CA 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 IP address as the Primary Network Perspective.

Note: If the FQDN or the domain name has been validated using this method, the Subordinate CA MUST NOT issue certificates for other FQDNs or common names that end with all the labels of the validated FQDN or domain name unless the Subordinate CA performs a separate validation using an authorized method. This rule does not apply to the validation of a wildcard domain name of OV SSL/TLS Server Certificate.

#9: Test Certificate (BR 3.2.2.4.9)

The Subordinate CA does not use this method.

#10: TLS Using a Random Value (BR 3.2.2.4.10)

# The Subordinate CA does not use this method.

#11: Any Other Method (BR 3.2.2.4.11)

The Subordinate CA does not use this method.

#12: Validating the Subscriber as a Domain Contact (BR 3.2.2.4.12)

The Subordinate CA does not use this method.

#13: Email to DNS CAA Contact (BR 3.2.2.4.13)

The Subordinate CA SHALL examine the Subscriber's authorization or control of the FQDN or domain name 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 RFC8659.

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.

On-or-after September 15, 2024, the Subordinate CA 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.

#14: Email to DNS TXT Contact (BR 3.2.2.4.14)

The Subordinate CA SHALL examine the Subscriber's authorization or control of the FQDN or the domain name 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.

On-or-after September 15, 2024, the Subordinate CA 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.

#15: Phone Contact with Domain Contact (BR 3.2.2.4.15)

The Subordinate CA SHALL examine the Subscriber's authorization or control of the FQDN or the domain name by calling the Domain Contact’s phone number.

Each phone call MAY confirm control of multiple Authorization Domain Names provided that the same Domain Contact phone number is listed for each Authorization Domain Name being examined and they provide a confirming response for each Authorization Domain Name.

In the event that someone other than a Domain Contact is reached, the Subordinate CA MAY request to be transferred to the Domain Contact. In the event of reaching voicemail, the Subordinate CA MAY leave the Random Value and the Authorization Domain Name(s) being examined. The Random Value MUST be returned to the Subordinate CA to approve the request.

#16: Phone Contact with DNS TXT Record Phone Contact (BR 3.2.2.4.16)

The Subordinate CA SHALL examine the Subscriber's authorization or control of the FQDN or the domain name 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 Subordinate CA 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 Subordinate CA MAY leave the Random Value and the Authorization Domain Name(s) being examined.

On-or-after September 15, 2024, the Subordinate CA 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.

#17: Phone Contact with DNS CAA Phone Contact (BR 3.2.2.4.17)

The Subordinate CA SHALL examine the Subscriber’s authorization or control of the FQDN or the domain name by calling a phone number verified as the DNS CAA Phone Contact.

The relevant CAA Resource Record Set MUST be found by using each algorithm defined in RFC8659.

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 Authorization Domain Name being verified, and they provide a confirming response for each Authorization Domain Name.

The Subordinate CA 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 Subordinate CA MAY leave the Random Value and the Authorization Domain Name(s) being examined.

The Random Value MUST be returned to the Subordinate CA to approve the request.

On-or-after September 15, 2024, the Subordinate CA 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.

#18: Agreed‐Upon Change to Website v2 (BR 3.2.2.4.18)

Confirming the Applicant's control over the FQDN by verifying that the Random Value is contained in the contents of a file.

  1. The entire Random Value MUST NOT appear in the request used to retrieve the file, and

  2. The Subordinate CA MUST receive a successful HTTP response from the request (meaning a 2xx HTTP status code must be received).

The file containing the Random Value:

  1. MUST be located on the Authorization Domain Name, and

  2. MUST be located under the "/.well-known/pki-validation" directory, and

  3. MUST be retrieved via either the "http" or "https" scheme, and

  4. MUST be accessed over an Authorized Port.

If the Subordinate CA 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.

  1. Redirects MUST be to resource URLs with either via the "http" or "https" scheme.

  2. Redirects MUST be to resource URLs accessed via Authorized Ports.

If a Random Value is used, then:

  1. The Subordinate CA 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.

On-or-after September 15, 2024, the Subordinate CA 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.

Note: For the certificate issued using this method, the Subordinate CA 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 Subordinate CA processes another validation. This rule does not apply to the validation of a wildcard domain name of OV SSL/TLS Server Certificate.

#19: Agreed‐Upon Change to Website - ACME (BR 3.2.2.4.19)

The Subordinate CA does not use this method.

#20: TLS Using ALPN (BR 3.2.2.4.20)

The Subordinate CA does not use this method.

Authentication for an IP Address

The Subordinate CA Shall verify, prior to issuance, the subscriber’s authorization or control of the IP address in accordance with Section 3.2.2.5 of the BR.

The Subordinate CA validates each IP address listed in the certificate using at least one of the methods listed below.

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 certificate issuance. For purposes of IP address validation, the term Subscriber includes the Subscriber's Parent Company and Subsidiary Company.

The Subordinate CA 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 subscriber certificate and the subordinate CA certificate via the IP address in the permitted subtree within the name restriction extension as stipulated in Section 7.1.4.2 of the BR. Describing it in the subordinate CA certificate need not be verified via the IP address in the excluded subtree of the name restriction extension.

If a Random Value is used for any of the methods below, the Subordinate CA SHALL provide a Random Value unique to the certificate request and shall not use the Random Value after 30 days from its creation. If there is validated information available for this process, it MUST not be used later than the time frame set forth in BR section 4.2.1.

The Subordinate CA does not adopt Request Token.

#1: Agreed‐Upon Change to Website (BR 3.2.2.5.1)

The Subordinate CA 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 verifies the Subscriber's authorization or control of the IP address by confirming the presence of a Random Value.

The Random Value MUST NOT appear in the request.

On-or-after September 15, 2024, the Subordinate CA 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.

#2: Email, Fax, SMS, or Postal Mail to IP Address Contact (BR 3.2.2.5.2)

The Subordinate CA does not use this method.

#3: Reverse IP Address Lookup (BR 3.2.2.5.3)

The Subordinate CA acquires the domain name associated with the IP address via reverse IP lookup of the IP address. It also verifies the subscriber's authorization or control of the IP address by using the method allowed in 3.2.2.4 “Validation of Domain Authorization or Control" of this CP to confirm that the subscriber controls the FQDN.

On-or-after September 15, 2024, the Subordinate CA 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.

#4: Any Other Method (BR 3.2.2.5.4)

The Subordinate CA does not use this method.

#5: Phone Contact with IP Address Contact (BR 3.2.2.5.5)

The Subordinate CA does not use this method.

#6: ACME “http-01” method for IP Addresses (BR 3.2.2.5.6)

The Subordinate CA does not use this method.

#7: ACME “tls-alpn-01” method for IP Addresses (BR 3.2.2.5.7)

The Subordinate CA does not use this method.

Validation of Authority and Authorization

Based on section 3.2.5 of BR, the Subordinate CA shall verify, via a communication method equivalent with phone call to the application supervisor, that the application supervisor has accepted the Subscriber Agreement and approved the person in charge of application to submit a certificate request.

The Subordinate CA may use the data source verified in "Verification of Identity " defined in Appendix A for OV SSL/TLS Server Certificate to confirm the contact information for the "Validation of Authority and Authorization" to the application supervisor.

Validation for Application with High Risk Status

The Subordinate CA shall maintain an internal database of all previously revoked Certificates and previously rejected certificate requests due to suspected phishing or other fraudulent usage or concerns based on section 4.2.1 of the BR. The Subordinate CA SHALL use this information to identify subsequent suspicious certificate requests and determine the certificate request as high risk if applicable.

The Subordinate CA SHALL additionally confirm the database of higher risk for phishing or other fraudulent usage which is deemed appropriate by the Subordinate CA, and for those applications requested by the subscriber that is included in the database requires additional verification activity by the CA to ensure such requests are properly verified under respective requirements.

In addition, no Certificate shall be issued when the Subscriber is listed on any government denial list or prohibited list such as embargo under the laws of the CA’s jurisdiction.

Reusable period of Validation Data The Subordinate CA 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 based on Section 3.2 of BR for less than 398 days from the day the initial validation completes to issue multiple Certificates. The Subordinate CA shall again verify the information for the certificate request if the previous validation results are expired.
Verification Items for EV SSL/TLS Server Certificate
Item Method
Identity

The Subordinate CA SHALL verify existence and Identity based on section 3.2.2.2, 3.2.2.4, 3.2.2.6, and Appendix D-1 Japan of the EV Guidelines, such as,

  • records of the Incorporating or Registration Agency in the Subject’s Jurisdiction of Incorporation or Registration or records of the superior governing Government Entity (QGIS including the Incorporating Agency or Registration Agency and QTIS)

  • QIIS

  • A Verified Professional Letter

The Subordinate CA shall additionally verify the Applicant's operational existence by using one or more than one of following methods based on section 3.2.2.6 of the EV Guidelines.

  1. Verifying that the Applicant has been in existence for at least three years, as indicated by the records of an Incorporating Agency or Registration Agency;

  2. Verifying that the Applicant, Affiliate, Parent Company, or Subsidiary Company is listed in either a current QIIS or QTIS; or

  3. Relying on a Verified Professional Letter to the effect that the Applicant has an active current Demand Deposit Account with a Regulated Financial Institution.

DBA/Tradename The Subordinate CA does not allow DBA/Tradename to be included in the subscriber's EV SSL/TLS Server Certificate.
Verification of Country The Subordinate CA SHALL verify Country based on section 3.2.2.4 and 7.1.4.2.6 of the EV Guidelines, and the procedure of the method for "Verification of Identity " defined in Appendix A for EV SSL/TLS Server Certificate is equally applied.
Validation of Domain Authorization or Control

The Subordinate CA SHALL verify Domain Authorization or Control based on section 3.2.2.7 of the EV Guidelines; and section 3.2.2.4 of the BR. In which process, the procedure of each methods in "Validation of Domain Authorization or Control" defined in Appendix A for OV SSL/TLS Server Certificate is equally applied.

The EV SSL/TLS Server Certificate request is determined to be high-risk when a domain name that contains mixed characters and an existing high-risk domain name are compared visually and similarity is observed. To ensure that the subscriber is not a high-risk target organization, additional authentication and verification that are reasonably appropriate shall be conducted.

The Subordinate CA does not issue EV SSL/TLS Server Certificate including the IP address.

Validation of Authority and Authorization

The Subordinate CA SHALL verify Authority based on section 3.2.2.8 and 3.2.2.9 of the EV Guidelines.

Prior to verification to Application Supervisor, the Subordinate CA shall verify the name and title of the application supervisor and the authority to submit a certificate request on behalf of the subscriber based on the EV Guidelines.

The Subordinate CA shall verify, based on section 3.2.2.10 of the EV Guidelines by using a verified communication method, that Application Supervisor has signed Subscriber Agreement and acknowledged that the certificate request submitted by Person in charge of application.

The Subordinate CA may use the contact information of phone number, email address, or postal address verified with one or more of following data sources, based on section 3.2.2.5 of the EV Guidelines.

  1. records provided by the applicable phone company;

  2. a QGIS, QTIS, or QIIS; or

  3. a Verified Professional Letter

Validation for Application with High Risk Status

The Subordinate CA shall verify the certificate request with high risk based on section 3.2.2.12.1 of the EV Guidelines, and the method for "Validation for Application with High Risk Status" defined in Appendix A for OV SSL/TLS Server Certificate is equally applied

In addition, no EV SSL/TLS Server Certificate shall be issued when the Subscriber is listed on any government denial list or prohibited list such as embargo under the laws of the CA’s jurisdiction.

Based on section 3.2.2.7 of the EV Guidelines, the domain names containing mixed character set in compliance with the rules set forth by the domain registrar shall be validated in the same manner of high risk validation method for OV SSL/TLS Server Certificate as high risk status if included in the certificate.

Reusable period of Validation Data The Subordinate CA MAY reuse the documents, data, and previous validation results (including the validation on the subscriber’s authorization or control over the domain name) provided based on section 3.2 of the EV Guidelines for less than 398 days from the day the initial validation completes to issue multiple Certificates, except when the EV Guidelines allows longer period. The Subordinate CA shall again verify the information for the certificate request if the previous validation results are expired.
# Appendix B: 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.
Corporate identification number 12 digits number for identification assigned to corporates and organizations in accordance with regulation of "Commercial Registration Act" (https://www.japaneselawtranslation.go.jp/ja/laws/view/4186), which number is available at http://www.moj.go.jp/MINJI/minji06_00076.html for reference.
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 constitutes 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.).
Subject The Legal Entity identified in a Certificate as the Subject. The Subject is the Subscriber.
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. CRL is a list of revoked certificates. The CA 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.
Certificate Requester A natural person who is the Applicant, employed by the Applicant, an authorized agent who has express authority to represent the Applicant, or the employee or agent of a third party (such as software publisher) who completes and submits a Certificate Request on behalf of the Applicant.
Registration Identifier The unique code assigned to an Applicant by the Incorporating or Registration Agency in such entity’s Jurisdiction of Incorporation or Registration.
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, validation operations, issuance/revocation/discarding operations, operations of responding to inquiries, billing operations, and system maintenance and management operations of the CA.
Backup Site A facility that is separate from the main site for storing important assets of the CA required for certificate issuance and revocation to ensure business continuity during disasters, etc.
Private Key One key of the key pair in public key cryptography that is kept private from third parties other than a subscriber.
Corporate Number 13 digits number for identification assigned, by National Tax Agency, to corporates and other entities which number is available at https://www.houjin-bangou.nta.go.jp/ for reference.
Main Site A facility equipped with assets of the CA required for certificate issuance and revocation.
Escrow As used herein, the term "deposit" 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 and CRL.
Apple Root Certificate Program The requirements which Apple imposes Root CAs to have their certificates trusted and included as the Root CA Certificate in Apple products.
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.
Baseline Requirements for the Issuance and Management of Publicly‐Trusted S/MIME Certificates Requirements for issuing publicly trusted S/MIME certificates which were formulated by the CA/Browser Forum.
ACME Abbreviation for "Automated Certificate Management Environment" and it is a standard protocol for automate 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.
Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (BR) Requirements for issuing publicly trusted TLS Server certificates which were formulated by the CA/Browser Forum.
CA/Browser Forum Organization that consists of the CA that issue publicly-trusted certificates for SSL/TLS communications and the companies that develop applications such as browsers. It creates standards about certificates. The website of the organization is https://cabforum.org/.
Chrome Root Program Policy The requirements which Google imposes Root CAs to have their certificates trusted and included as the Root CA Certificate in Google products.
Extended Validation Certificate (EV Certificate) EV SSL/TLS Server 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.
Guidelines for the Issuance and Management of Extended Validation Certificates (EV Guidelines) Requirements for issuing EV SSL/TLS Server Certificates, which were formulated by the CA/Browser Forum.
Certificate Transparency A scheme standardized in RFC6962 for promptly discovering and detecting fraudulent certificates.
DBA/Tradename Indicates a common name, trade name, shop name, 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 section A.1.1 of BR.
DNS CAA Phone Contact The phone number defined in section A.1.2 of BR.
DNS CA Authorization Resource Record (CAA Record) One of the DNS records defined in RFC8659 and RFC9495 which aims to clarify the certification authority to issue the certificate to a domain name and prevent the issuance of unintended certificates.
DNS TXT Record Email Contact The email address defined in section A.2.1 of BR.
DNS TXT Record Phone Contact The phone number defined in section A.2.2 of BR.
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. 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 sub domain name and a host name are added and is included in a certificate.
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 RFC3647.
Program Requirements - Microsoft Trusted Root Program The requirements which Microsoft imposes Root CAs to have their certificates trusted and included as the Root CA Certificate in Microsoft products.
Mozilla Root Store Policy The requirements which Mozilla imposes Root CAs to have their certificates trusted and included as the Root CA Certificate in Mozilla products.
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.

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.
IP Address 32-bit or 128-bit label that is assigned to a device that uses the Internet Protocol for communications.
ITU-T Telecommunications Standardization Sector of the International Telecommunication Union.
LEI (Legal Entity Identifier) An international identifier assigned by the International Organization for Standardization (ISO) which enables clear and unique identification of legal entities participating in financial transactions.
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 subscriber certificate.
OCSP Abbreviation of "Online Certificate Status Protocol", and is a communication protocol for providing certificate revocation information. The CA is operating an OCSP responder if needed, in addition to publicly disclosing CRL, so that a Relying Party can verify the validity of a certificate.
Organization-validated Strict Generation Certificates of Strict generational Organization-validated type among the S/MIME Certificates issued based on "Baseline Requirements for the Issuance and Management of Publicly‐Trusted S/MIME Certificates" as set forth by the CA/Browser Forum and used for S/MIME signing.
Precertificate Certificate addressed in RFC 6962 of Certificate Transparency.
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".
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.
RSA Public key cryptography developed by Rivest, Shamir, and Adelman.
SHA1/SHA256 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.
Technically Constrained Subordinate CA The Technically Constrained Subordinate CA Certificate set forth in the Baseline Requirements. That is, the Subordinate CA which uses the Subordinate CA Certificate containing Key Usage Extension and Name Constraint Extension in it to constrain the issuance of Subscriber Certificates.
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 C: Profile of Certificate** 1. Root CA Certificates 1-1 SecureSign Root CA11 (Basic Certificate Fields)
version value
Version Version of the encoded certificate

value:INTEGER

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

type:INTEGER

1 (0x01)
signature value
AlgorithmIdentifier

The identifier for the signature algorithm used by the CA to sign this certificate

algorithm

Object ID for the signature algorithm (SHA-1)

type:OID

1.2.840.113549.1.1.5

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 for the country name

type:PrintableString

JP
organizationName Organization-name attribute of certificate issuer

type

Object ID for the organization name

type:OID

2.5.4.10

value

Value for the organization name

type:PrintableString

Japan Certification Services, Inc.
commonName Common-name attribute of certificate issuer

type

Object ID for the common name

type:OID

2.5.4.3

value

Value for the common name

type:PrintableString

SecureSign RootCA11
validity value
Validity Validity period of certificate

notBefore

the date on which the certificate validity period begins

type:UTCTime

090408045647Z

2009年4月8日 04:56:47(GMT)

notAfter

The date on which the certificate validity period ends

type:UTCTime

290408045647Z

2029年4月8日 04:56:47(GMT)
subject value
countryName Country-name attribute of certificate subject

type

Object ID for the country name

type:OID

2.5.4.6

value

Value for the country name

type:PrintableString

JP
organizationName Organization-name attribute of certificate subject

type

Object ID for the organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString

Japan Certification Services, Inc.
commonName Common-name attribute of certificate issuer

type

Object ID for the common name

type:OID

2.5.4.3

value

Valu for the common name

type:PrintableString

SecureSign RootCA11
subjectPublicKeyInfo value
SubjectPublicKeyInfo Subject’s public key information

AlgorithmIdentifier

the identifier for the 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: OID

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 the public key

type OCTET STRING

5BF84D4FB2A586D43AD2F1639AA0BE09F657B7DE
keyUsage (extnId :== 2 5 29 15,critical :== TRUE) keyUsage (extnId :== 2 5 29 15,critical :== TRUE)
KeyUsage Key Usage

type: BIT STRING

00000110 (0x06)

(keyCertSign,cRLSign)

basicConstraints (extnId :== 2 5 29 19,critical :== TRUE) basicConstraints (extnId :== 2 5 29 19,critical :== TRUE)
BasicConstraints Basic Constraints

cA

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

type: BOOLEAN

TRUE
2. SecureSign Root CA12 (RCA12) 3. SecureSign Root CA14 (RCA14) 4. SecureSign Root CA15 (RCA15 > (Basic Certificate Fields)
version value
Version Version of the encoded certificate

type: INTEGER

2 (Ver.3)
serialNumber value
CertificateSerialNumber Serial number of certificate *One of the following values:

type: INTEGER

RCA12:

587887345431707215246142177076162061960426065942

(0x66F9C7C1AFECC251B4ED5397E6E682C32B1C9016)

RCA14:

575790784512929437950770173562378038616896959179

(0x64DB5A0C204EE8D72977C85027A25A27DD2DF2CB)

RCA15:

126083514594751269499665114766174399806381178503

(0x1615C7C3D849A7BE690C8A88EDF070F9DDB73E87)

signature value
AlgorithmIdentifier TThe identifier for the signature algorithm used by the CA to sign this certificate

algorithm

Object ID for the signature algorithm *One of the following values:

type: OID

RCA12:

1.2.840.113549.1.1.11 (sha256WithRSAEncryption)

RCA14, and RCA16:

1.2.840.113549.1.1.12 (sha384WithRSAEncryption)

RCA15:

1.2.840.10045.4.3.3 (ecdsa-with-SHA384)

parameters

Parameters of signature algorithm *Only for RCA12, and RCA14

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 *One of the following values:

type: PrintableString

RCA12:

SecureSign Root CA12

RCA14:

SecureSign Root CA14

RCA15:

SecureSign Root CA15

validity value
Validity Validity period of the certificate

notBefore

The date on which the certificate validity period begins *One of the following values:

type: UTCTime

RCA12:

200408053646Z

(April 8, 2020 14:36:46 JST)

RCA14:

200408070619Z

(April 8, 2020 16:06:19 JST)

RCA15:

200408083256Z

(April 8, 2020 17:32:56 JST)

notAfter

The date on which the certificate validity period ends *One of the following values:

type: UTCTime

RCA12:

400408053646Z

(April 8, 2040 14:36:46 JST)

RCA14:

450408070619Z

(April 8, 2045 16:06:19 JST)

RCA15:

450408083256Z

(April 8, 2045 17:32:56 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 *One of the following values:

type: PrintableString

RCA12:

SecureSign Root CA12

RCA14:

SecureSign Root CA14

RCA15:

SecureSign Root CA15

subjectPublicKeyInfo value
SubjectPublicKeyInfo Subject’s public key information

AlgorithmIdentifier

The identifier for cryptographic algorithm

algorithm

Object ID for the cryptographic algorithm *One of the following values:

type: OID

RCA12, RCA14, and RCA16:

1.2.840.113549.1.1.1 (rsaEncryption)

RCA15:

1.2.840.10045.2.1 (id-ecPublicKey)

parameters

Parameters of cryptographic algorithm *One of the following values:

type: OID

RCA12, RCA14, and RCA16:

NULL

RCA15:

1.3.132.0.34 (secp384r1)

subjectPublicKey

Value of public key *One of the following values:

type: BIT STRING

RCA12:

*Public key of 2048 bit size

RCA14, and RCA16:

*Public key of 4096 bit size

RCA15:

*Public key of 384 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

TRUE
keyUsage (extnId :== 2 5 29 15, critical :== TRUE) value
KeyUsage Key Usage

type: BIT STRING

00000110 (0x06)

(keyCertSign, cRLSign)

subjectKeyIdentifier (extnId :== 2 5 29 14, critical :== FALSE) value
SubjectKeyIdentifier Information of Subject Key Identifier

KeyIdentifier

The identifier for public key *One of the following values:
type: OCTET STRING

RCA12:

5734F374CF044BD525E6F140B62C4CD92DE9A0AD

RCA14:

0693A30A5E286937AA611DEBEBFC2D6F23E4F3A0

RCA15:

EB41C8AEFCD59E5148F5BD8BF4872093412BD3F4

2. Subordinate CA Certificates > 2-1) JCSI$202FTLSSign$202FPublic$202FCA > > (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

669394234770181081919879261157056934939221937491

(0x7540acf59d071d7a7ecafc2fb965a7d11415cd53)

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

Japan Certification Services, Inc.
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

SecureSign RootCA11
validity value
Validity Validity period of the certificate

notBefore

The date on which the certificate validity period begins

type: UTCTime

181011013633Z

(October 11, 2018 1:36:33 GMT)

notAfter

The date on which the certificate validity period ends

type: UTCTime

290408045647Z

(April 8, 2029 4:56:47 GMT)

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

JCSI TLSSign Public CA
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: OID

NULL

subjectPublicKey

Value of public key

type: BIT STRING

*2048bit size of public key
> (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

TRUE

pathLenConstraint

PathLenConstraint

type:INTEGER

0
certificatePolicies (extnId :== 2 5 29 32,critical :== FALSE) value
PolicyInformation Information of the Policy

policyIdentifier

Object ID for the Policy

type:OID

2.5.29.32.0 (anyPolicy)

policyQualifiers

Information of the policy qualifiers

PolicyQualifierID

Classification of 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/jcsi/repository.html
Name Constraints (extnId :== 2.5.29.30,critical :== TRUE) value
Name Constraints Name Constraints

Permitted Names

dNS Name .managedpki.ne.jp
Directory Name O=Cybertrust Japan Co.,Ltd., L=Minato-ku, ST=Tokyo, C=JP

Excluded Names

IP address (IPv4) 0.0.0.0/0.0.0.0
IP address (IPv6) 0:0:0:0:0:0:0:0/0
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: OCTET STRING

http://rtocsp.managedpki.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: OCTET STRING

http://rtcrl.managedpki.ne.jp/
SecureSignAD/SecureSignRootCA11/SSAD-rca.crt
keyUsage (extnId :== 2 5 29 15,critical :== TRUE) value
KeyUsage Key Usage

type: BIT STRING

10000110 (0x86)

(Digital Signature,keyCertSign,cRLSign)

extKeyUsage (extnId :== 2 5 29 37,critical :== FALSE) extKeyUsage (extnId :== 2 5 29 37,critical :== FALSE)
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)
authorityKeyIdentifier (extnId :== 2 5 29 35,critical :== FALSE) authorityKeyIdentifier (extnId :== 2 5 29 35,critical :== FALSE)
AuthorityKeyIdentifier Information of Authority Key Identifier

KeyIdentifier

The identifier for the public key

type: OCTET STRING

5BF84D4FB2A586D43AD2F1639AA0BE09F657B7DE
cRLDistributionPoints (extnId :== 2 5 29 31,critical :== FALSE) cRLDistributionPoints (extnId :== 2 5 29 31,critical :== FALSE)
cRLDistributionPoints CRL Distribution Point

DistributionPoint

CRL Distribution Point

uniformResourceIdentifier

URI of CRL Distribution Point

type: OCTET STRING

http://rtcrl.managedpki.ne.jp/SecureSignAD/SecureSignRootCA11/cdp.crl
subjectKeyIdentifier (extnId :== 2 5 29 14,critical :== FALSE) subjectKeyIdentifier (extnId :== 2 5 29 14,critical :== FALSE)
SubjectKeyIdentifier Subject Key Identifier

KeyIdentifier

The identifier for the public key

type: OCTET STRING

D3342FDDF84C99DE843F051DB9D9F440D9C08BB1
> 2-2) Cybertrust Japan SureServer EV CA G7 (EVCA7) > > 2-3) Cybertrust Japan SureServer EV CA G8 (EVCA8) > > 2-4) Cybertrust Japan SureServer EV CA G9 (EVCA9) > > 2-5) Cybertrust Japan SureServer CA G7 (SSCA7) > > 2-6) Cybertrust Japan SureServer CA G8 (SSCA8) > > (Basic Certificate Fields)
version value
Version Version of the encoded certificate

type: INTEGER

2 (Ver.3)
serialNumber value
CertificateSerialNumber Serial number of certificate *One of the following values:

type: INTEGER

EVCA7:

253871017432188711949194414046884150249969284120

(0x2C77F85B12969E757EAC8921C7155089AE35F418)

EVCA8:

711557647551209168260412389303640762322044180483

(0x7CA3593373BD43AA87416AB0439DAC5D0361D803)

EVCA9:

670330029353397387367279429585581215447244928789

(0x756AA35ABA8847DD5103C33A37B168FA13A4F715)

SSCA7:

128404668628304561596392169718195621015372084939

(0x167DDD4E7ABD348B6A105BC9CA24ACE745F2B6CB)

SSCA8:

442497590356880787032587269713624319867761233890

(0x4D8247384ADF541F88340F4928553224B6C48FE2)

signature value
AlgorithmIdentifier TThe identifier for the signature algorithm used by the CA to sign this certificate

algorithm

Object ID for the signature algorithm *One of the following values:

type: OID

EVCA7, and SSCA7:

1.2.840.113549.1.1.11 (sha256WithRSAEncryption)

EVCA9:

1.2.840.113549.1.1.12 (sha384WithRSAEncryption)

EVCA8, and SSCA8:

1.2.840.10045.4.3.3 (ecdsa-with-SHA384)

parameters

Parameters of signature algorithm *Only for EVCA7, EVCA9, and SSCA7

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 *One of the following values:

type: PrintableString

EVCA7, and SSCA7:

SecureSign Root CA12

EVCA9:

SecureSign Root CA14

EVCA8, and SSCA8:

SecureSign Root CA15

validity value
Validity Validity period of the certificate

notBefore

The date on which the certificate validity period begins *One of the following values:

type: UTCTime

EVCA7:

200622073438Z

(June 22, 2020 16:34:38 JST)

EVCA8:

200622093921Z

(June 22, 2020 18:39:21 JST)

EVCA9:

200622085022Z

(June 22, 2020 17:50:22 JST)

SSCA7:

200622074205Z

(June 22, 2020 16:42:05 JST)

SSCA8:

200622094515Z

(June 22, 2020 18:45:15 JST)

notAfter

The date on which the certificate validity period ends *One of the following values:

type: UTCTime

EVCA7:

300622073438Z

(June 22, 2030 16:34:38 JST)

EVCA8:

300622093921Z

(June 22, 2030 18:39:21 JST)

EVCA9:

300622085022Z

(June 22, 2030 17:50:22 JST)

SSCA7:

300622074205Z

(June 22, 2030 16:42:05 JST)

SSCA8:

300622094515Z

(June 22, 2030 18:45:15 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 *One of the following values:

type: PrintableString

EVCA7:

Cybertrust Japan SureServer EV CA G7

EVCA8:

Cybertrust Japan SureServer EV CA G8

EVCA9:

Cybertrust Japan SureServer EV CA G9

SSCA7:

Cybertrust Japan SureServer CA G7

SSCA8:

Cybertrust Japan SureServer CA G8

subjectPublicKeyInfo value
SubjectPublicKeyInfo Subject’s public key information

AlgorithmIdentifier

The identifier for cryptographic algorithm

algorithm

Object ID for the cryptographic algorithm *One of the following values:

type: OID

EVCA7, EVCA9, and SSCA7:

1.2.840.113549.1.1.1 (rsaEncryption)

EVCA8, and SSCA8:

1.2.840.10045.2.1 (id-ecPublicKey)

parameters

Parameters of cryptographic algorithm *One of the following values:

type: OID

EVCA7, EVCA9, and SSCA7:

NULL

EVCA8, and SSCA8:

1.3.132.0.34 (secp384r1)

subjectPublicKey

Value of public key *One of the following values:

type: BIT STRING

EVCA7, and SSCA7:

*Public key of 2048 bit size

EVCA9:

*Public key of 4096 bit size

EVCA8, and SSCA8:

*Public key of 384 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

TRUE
pathLenConstraint

Path length constraint

type: INTEGER

0
certificatePolicies (extnId :== 2 5 29 32, critical :== FALSE) value
PolicyInformation Information of the Policy

policyIdentifier

Object ID for the Policy *One of the following values:

type: OID

EVCA7, EVCA8, and EVCA9:

1.2.392.200081.1.32.1

SSCA7, and SSCA8:

1.2.392.200081.1.32.2

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_rt/index.html
PolicyInformation Information of the Policy

policyIdentifier

Object ID for the Policy *One of the following values:

type: OID

EVCA7, EVCA8, and EVCA9:

2.23.140.1.1

(CABF Extended Validation)

SSCA7, and SSCA8:

2.23.140.1.2.2

(CABF Organization Validated)

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://rtocsp.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 *One of the following values:

type: IA5String

EVCA7, and SSCA7:

http://rtcrl.cybertrust.ne.jp/SecureSign/rtca12/rtca12.crt

EVCA9:

http://rtcrl.cybertrust.ne.jp/SecureSign/rtca14/rtca14.crt

EVCA8, and SSCA8:

http://rtcrl.cybertrust.ne.jp/SecureSign/rtca15/rtca15.crt

keyUsage (extnId :== 2 5 29 15, critical :== TRUE) value
KeyUsage Key Usage

type: BIT STRING

10000110 (0x86)

(digitalSignature, 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)

authorityKeyIdentifier (extnId :== 2 5 29 35, critical :== FALSE) value
AuthorityKeyIdentifier Information of Authority Key Identifier

KeyIdentifier

The identifier for public key *One of the following values:

type: OCTET STRING

EVCA7, and SSCA7:

5734F374CF044BD525E6F140B62C4CD92DE9A0AD

EVCA9:

0693A30A5E286937AA611DEBEBFC2D6F23E4F3A0

EVCA8, and SSCA8:

EB41C8AEFCD59E5148F5BD8BF4872093412BD3F4

cRLDistributionPoints (extnId :== 2 5 29 31, critical :== FALSE) value
CRLDistributionPoints CRL Distribution Point

DistributionPoint

CRL Distribution Point

uniformResourceIdentifier

URI of CRL Distribution Point *One of the following values:

type: IA5String

EVCA7, and SSCA7:

http://rtcrl.cybertrust.ne.jp/SecureSign/rtca12/cdp.crl

EVCA9:

http://rtcrl.cybertrust.ne.jp/SecureSign/rtca14/cdp.crl

EVCA8, and SSCA8:

http://rtcrl.cybertrust.ne.jp/SecureSign/rtca15/cdp.crl

subjectKeyIdentifier (extnId :== 2 5 29 14, critical :== FALSE) value
SubjectKeyIdentifier Information of Subject Key Identifier

KeyIdentifier

The identifier for public key *One of the following values:

type: OCTET STRING

EVCA7:

7483319BF875CD0DCF8E84E6D28E9AA6794C2AA6

EVCA8:

AEE4FDC16E22F8DFB71383F8E2D143B696B93AC8

EVCA9:

EDB8FA2F3D7D25BEE354B165CE54A8833B92F0C7

SSCA7:

8E3C286393A4E4850F5489DD69B23C52674AB5A4

SSCA8:

3DD29719E5391699EE6BB01B7AC6F3FACAF5F703

3. SSL/TLS Certificates > 3-1) JCSI TLSSign Public CA > > (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 the 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 the common name

type:OID

2.5.4.3

value

Value of common name

type:PrintableString

JCSI TLSSign Public CA
validity value
Validity Validity period of certificate

notBefore

The date on which the certificate validity period begins

type:UTCTime

*The date and time on which the certificate validity period begins

notAfter

The date on which the certificate validity period ends

type:UTCTime

*The date and time 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

JP
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

*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

*Locality name attribute of certificate subject
organizationName Organization name attribute of certificate issuer

type

Object ID for the organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString / UTF8String

*Organization name attribute of certificate subject
commonName Common name attribute of certificate issuer

type

Object ID for the common name

type:OID

2 5 4 3

value

Value of common name

type:PrintableString

* Common name attribute of certificate issuer

* FQDN of the SSL/TLS server

* Note: domain: managedpki.ne.jp
subjectPublicKeyInfo value
SubjectPublicKeyInfo Subject’s public key information

AlgorithmIdentifier

The identifier for the 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: OID

NULL

subjectPublicKey

Value of public key

type: BIT STRING

*The key size is depended 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

1.2.392.200081.1.10.10

policyQualifiers

Information of the policy qualifiers

policyQualifierID

Classification of 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_rt/
PolicyInformation Information of the Policy

policyIdentifier

Object ID for the Policy

type:OID

2.23.140.1.2.2
value value
SubjectAltName Subject Alternative Name

dNSName

dnsName

type: IA5String

* FQDN of the SSL/TLS server

* Note: Domain: .managedpki.ne.jp

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: OCTET STRING

http://jcsitlssignpublicca-ocsp.
managedpki.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: OCTET STRING

http://rtcrl.managedpki.ne.jp/
SecureSignAD/JCSITLSSignPublicCA/SSAD-JCSITLS.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

d3 34 2f dd f8 4c 99 de 84 3f

05 1d b9 d9 f4 40 d9 c0 8b b1

cRLDistributionPoints (extnId :== 2 5 29 31,critical :== FALSE) value
cRLDistributionPoints CRL Distribution Point

DistributionPoint

CRL Distribution Point

uniformResourceIdentifier

URI of CRL Distribution Point

type: OCTET STRING

http://rtcrl.managedpki.ne.jp/
SecureSignAD/JCSITLSSign
PublicCA/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 the public key

type: OCTET STRING

* Hash value of subjectPublicKey
> 3-2) Cybertrust Japan SureServer EV CA G7 (EVCA7) > > 3-3) Cybertrust Japan SureServer EV CA G8 (EVCA8) > > 3-4) Cybertrust Japan SureServer EV CA G9 (EVCA9) > > 3-5) Cybertrust Japan SureServer CA G7 (SSCA7) > > 3-6) Cybertrust Japan SureServer CA G8 (SSCA8) > > (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 TThe identifier for the signature algorithm used by the CA to sign this certificate

algorithm

Object ID for the signature algorithm *One of the following values:

type: OID

EVCA7, and SSCA7:

1.2.840.113549.1.1.11 (sha256WithRSAEncryption)

EVCA9:

1.2.840.113549.1.1.12 (sha384WithRSAEncryption)

EVCA8, and SSCA8:

1.2.840.10045.4.3.3 (ecdsa-with-SHA384)

parameters

Parameters of signature algorithm *Only for EVCA7, EVCA9, and SSCA7

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 *One of the following values:

type: PrintableString

EVCA7:

Cybertrust Japan SureServer EV CA G7

EVCA8:

Cybertrust Japan SureServer EV CA G8

EVCA9:

Cybertrust Japan SureServer EV CA G9

SSCA7:

Cybertrust Japan SureServer CA G7

SSCA8:

Cybertrust Japan SureServer CA G8

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 *Only for EVCA7, EVCA8, and EVCA9

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 for EVCA7, EVCA8, and EVCA9

*present if the jurisdiction incorporation is state/province or locality

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 for EVCA7, EVCA8, and EVCA9

*present if the jurisdiction incorporation is locality

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 *Only for EVCA7, EVCA8, and EVCA9

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 a Government Entity”

businessCategory Business category attribute of certificate subject *Only for EVCA7, EVCA8, and EVCA9

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: Government Entity

(The Subordinate CAs do not issue a certificate to Business: Business Entity or Non-Commercial: Non-Commercial 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

*a single IP address or FQDN of the SSL/TLS server

*IP address only for OV

subjectPublicKeyInfo value
SubjectPublicKeyInfo Subject’s public key information

AlgorithmIdentifier

The identifier for cryptographic algorithm

algorithm

Object ID for the cryptographic algorithm *One of the following values:

type: OID

EVCA7, EVCA9, and SSCA7:

1.2.840.113549.1.1.1 (rsaEncryption)

EVCA8, and SSCA8:

1.2.840.10045.2.1 (id-ecPublicKey)

parameters

Parameters of cryptographic algorithm *One of the following values:

type: OID

EVCA7, EVCA9, and SSCA7:

NULL

EVCA8, and SSCA8:

*One of the following values:

1.2.840.10045.3.1.7 (secp256r1)

1.3.132.0.34 (secp384r1)

subjectPublicKey

Value of public key

type: BIT STRING

*The key size depends on application

*The key size must be at least 2048 bit (EVCA7, SSCA7, and EVCA9) or 256 bit (EVCA8, and SSCA8)

> (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 *One of the following values:

type: OID

EVCA7, EVCA8, and EVCA9:

1.2.392.200081.1.32.1

SSCA7, and SSCA8:

1.2.392.200081.1.32.2

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_rt/index.html
PolicyInformation Information of the Policy

policyIdentifier

Object ID for the Policy *One of the following values:

type: OID

EVCA7, EVCA8, and EVCA9:

2.23.140.1.1

(CABF Extended Validation)

SSCA7, and SSCA8:

2.23.140.1.2.2

(CABF Organization Validated)

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 *One of the following values:

type: IA5String

EVCA7, EVCA8, and EVCA9:

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

SSCA7, and SSCA8:

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 *One of the following values:

type: IA5String

EVCA7:

http://evcrl.cybertrust.ne.jp/SureServer/evcag7/evcag7.crt

EVCA8:

http://evcrl.cybertrust.ne.jp/SureServer/evcag8/evcag8.crt

EVCA9:

http://evcrl.cybertrust.ne.jp/SureServer/evcag9/evcag9.crt

SSCA7:

http://sscrl.cybertrust.ne.jp/SureServer/ovcag7/ovcag7.crt

SSCA8:

http://sscrl.cybertrust.ne.jp/SureServer/ovcag8/ovcag8.crt

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

*IP address only for OV

keyUsage (extnId :== 2 5 29 15, critical :==TRUE) value
KeyUsage Key Usage *One of the following values:
type: BIT STRING

EVCA7, EVCA9, and SSCA7:

10100000 (0xA0)

(digitalSignature, keyEncipherment)

EVCA8, and SSCA8:

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.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 *One of the following values:

type: OCTET STRING

EVCA7:

7483319BF875CD0DCF8E84E6D28E9AA6794C2AA6

EVCA8:

AEE4FDC16E22F8DFB71383F8E2D143B696B93AC8

EVCA9:

EDB8FA2F3D7D25BEE354B165CE54A8833B92F0C7

SSCA7:

8E3C286393A4E4850F5489DD69B23C52674AB5A4

SSCA8:

3DD29719E5391699EE6BB01B7AC6F3FACAF5F703

cRLDistributionPoints (extnId :== 2 5 29 31, critical :== FALSE) value
CRLDistributionPoints CRL Distribution Point

DistributionPoint

CRL Distribution Point

uniformResourceIdentifier

URI of CRL Distribution Point *One of the following values:

type: IA5String

EVCA7:

http://evcrl.cybertrust.ne.jp/SureServer/evcag7/cdp.crl

EVCA8:

http://evcrl.cybertrust.ne.jp/SureServer/evcag8/cdp.crl

EVCA9:

http://evcrl.cybertrust.ne.jp/SureServer/evcag9/cdp.crl

SSCA7:

http://sscrl.cybertrust.ne.jp/SureServer/ovcag7/cdp.crl

SSCA8:

http://sscrl.cybertrust.ne.jp/SureServer/ovcag8/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

SignedCertificateTimestamp

Timestamp list for Certificate Transparency

Timestamp of Certificate Transparency

type: OCTET STRING

*Signed CertificateTimestamp List
4. 5. CRLs > 5-1) SecureSign RootCA11(CA11) > > 5-2) JCSI TLSSign Public CA(JCSICA) > > (Basic Certificate Fields)
version value
Version

1 (Ver.2)

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 the organization name

type:OID

2.5.4.10

value

Value of organization name *One of the following values:

type:PrintableString

Root CA

Japan Certification Services, Inc.

Subordinate CA

Cybertrust Japan Co.,Ltd.

commonName Common-name attribute of CRL issuer

type

Object ID for the common name

type:OID

2.5.4.3

value

Value of common name *One of the following values:

type:PrintableString

Root CA

SecureSign RootCA11

Subordinate CA

JCSI TLSSign Public CA (reference)

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 will be issued

type:UTCTime

*The date by which the next CRL is issued
> (Certificate Extensions)
cRLNumber (extnId :== 2 5 29 20,critical :== FALSE) value
cRLNumber

*Serial number of CRL

*Serial number of CRL
authorityKeyIdentifier (extnId :== 2 5 29 35,critical :== FALSE) value
AuthorityKeyIdentifier Certification Authority Key Identifier

keyIdentifier

the identifier for the public key of CA which issued CRL *One of the following values:

type:OCTET STRING

Root CA

5b f8 4d 4f b2 a5 86 d4 3a d2

f1 63 9a a0 be 09 f6 57 b7 de

Subordinate CA

d3 34 2f dd f8 4c 99 de 84 3f

05 1d b9 d9 f4 40 d9 c0 8b b1

issuingDistributionPoint (extnId :== 2 5 29 28,critical :== FALSE) value
issuingDistributionPoint CRL issuing distribution point

distributionPoint

CRL Distribution Point

uniformResourceIdentifier

URI of CRL is published

type:OCTET STRING

http://rtcrl.managedpki.ne.jp/SecureSignAD/JCSITLSSignPublicCA/cdp.crl

onlyContainsUserCerts

The flag to indicate that CRL contains only for user certs.

type: BOOLEAN

TRUE

onlyContainsCACerts

The flag to indicate that CRL contains only for CA certs.

type: BOOLEAN

FALSE

indirectCRL

The flag to indicate that CRL is indirect CRL.

type:BOOLEAN

FALSE
> (Entry Area)
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
> (Entry Expansion Area)
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 of the certificate occurred.
cRLReason (extnId :== 2 5 29 21,critical :== FALSE) value
CRLReason The reason for the certificate revocation

type: ENUMERATED

*Value of reason code for the revocation
> 5-3) SecureSign Root CA12 (RCA12) > > 5-4) SecureSign Root CA14 (RCA14) > > 5-5) SecureSign Root CA15 (RCA15) > > 5-6) Cybertrust Japan SureServer EV CA G7 (EVCA7) > > 5-7) Cybertrust Japan SureServer EV CA G8 (EVCA8) > > 5-8) Cybertrust Japan SureServer EV CA G9 (EVCA9) > > 5-9) Cybertrust Japan SureServer CA G7 (SSCA7) > > 5-10) Cybertrust Japan SureServer CA G8 (SSCA8) > > (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 *One of the following values:

type: OID

RCA12, EVCA7, and SSCA7

1.2.840.113549.1.1.11 (sha256WithRSAEncryption)

RCA14, and EVCA9:

1.2.840.113549.1.1.12 (sha384WithRSAEncryption)

RCA15, EVCA8, and SSCA8:

1.2.840.10045.4.3.3 (ecdsa-with-SHA384)

parameters

Parameters of signature algorithm *Only for RCA12, RCA14, EVCA7, EVCA9, and SSCA7

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 *One of the following values:

type: PrintableString

RCA12:

SecureSign Root CA12

RCA14:

SecureSign Root CA14

RCA15:

SecureSign Root CA15

EVCA7:

Cybertrust Japan SureServer EV CA G7

EVCA8:

Cybertrust Japan SureServer EV CA G8

EVCA9:

Cybertrust Japan SureServer EV CA G9

SSCA7:

Cybertrust Japan SureServer CA G7

SSCA8:

Cybertrust Japan SureServer CA G8

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)
cRLNumber (extnId :== 2 5 29 20, critical :== FALSE) value
cRLNumber CRL Number

type: INTEGER

*Serial number of CRL
authorityKeyIdentifier (extnId :== 2 5 29 35, critical :== FALSE) value
AuthorityKeyIdentifier Authority Key Identifier

KeyIdentifier

The identifier for public key *One of the following values:

type: OCTET STRING

RCA12:

5734F374CF044BD525E6F140B62C4CD92DE9A0AD

RCA14:

0693A30A5E286937AA611DEBEBFC2D6F23E4F3A0

RCA15:

EB41C8AEFCD59E5148F5BD8BF4872093412BD3F4

EVCA7:

7483319BF875CD0DCF8E84E6D28E9AA6794C2AA6

EVCA8:

AEE4FDC16E22F8DFB71383F8E2D143B696B93AC8

EVCA9:

EDB8FA2F3D7D25BEE354B165CE54A8833B92F0C7

SSCA7:

8E3C286393A4E4850F5489DD69B23C52674AB5A4

SSCA8:

3DD29719E5391699EE6BB01B7AC6F3FACAF5F703

issuingDistributionPoint (extnId :== 2 5 29 28, critical :== TRUE) value
issuingDistributionPoint CRL issuing distribution point *Excluding RCA12, RCA14, RCA15, and RCA16

distributionPoint

CRL Distribution Point

uniformResourceIdentifier

URI of CRL is published *One of the following values:

type: IA5String

EVCA7:

http://evcrl.cybertrust.ne.jp/SureServer/evcag7/cdp.crl

EVCA8:

http://evcrl.cybertrust.ne.jp/SureServer/evcag8/cdp.crl

EVCA9:

http://evcrl.cybertrust.ne.jp/SureServer/evcag9/cdp.crl

SSCA7:

http://sscrl.cybertrust.ne.jp/SureServer/ovcag7/cdp.crl

SSCA8:

http://sscrl.cybertrust.ne.jp/SureServer/ovcag8/cdp.crl

onlyContainsUserCerts

The flag to indicate that CRL contains only for user certs.

type: BOOLEAN

TRUE

onlyContainsCACerts

The flag to indicate that CRL contains only for CA certs.

type: BOOLEAN

FALSE

indirectCRL

The flag to indicate that CRL is indirect CRL.

type: BOOLEAN

FALSE
> (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 of the certificate occurred.
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
6. OCSP Responder Certificates > 6-1) SecureSign RootCA11(CA11) > > 6-2) JCSI TLSSign Public CA(JCSICA) > > (Basic Certificate Fields)
Version value
type:INTEGER 2 (Ver.3)
serialNumber

value

CertificateSerialNumber value
type:INTEGER

669394234770181081919879261157056934939221937491

(0x7540acf59d071d7a7ecafc2fb965a7d11415cd53)

signature

value

AlgorithmIdentifier value
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 value
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 the organization name
type: OID 2.5.4.10
value

Value of organization name

type: PrintableString Japan Certification Services, Inc.
commonName

Common name attribute of certificate issuer

type

Object ID for the common name

type:OID 2.5.4.3

value

Value of common name

type:PrintableString

SecureSign RootCA11

Version

Version of the encoded certificate

type:INTEGER

2 (Ver.3)
serialNumber

value

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 the 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 the organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString

Japan Certification Services, Inc.
commonName

Common name attribute of the certificate issuer

type Object ID for the common name
type:OID 2.5.4.3
value

Value of common name

type:PrintableString SecureSign RootCA11 OCSP Responder
countryName

Country name attribute of the certificate issuer

type

Object ID for the country name

subjectPublicKeyInfo value
parameters Parameters of cryptographic algorithm parameters
type:NULL

subjectPublicKey

Value of public key subjectPublicKey

type: BIT STRING

version

value version
Version

Version of the encoded certificate

Version
type:INTEGER
serialNumber

value

serialNumber
> (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
OCSP No Check Revocation checking of signer’s certificates
Do not check revocation NULL
keyUsage (extnId :== 2 5 29 15,critical :== TRUE) keyUsage (extnId :== 2 5 29 15,critical :== TRUE)
KeyUsage Key Usage

type: BIT STRING

10000000 (0x80)

(digitalSignature)

extKeyUsage (extnId :== 2 5 29 37,critical :== FALSE) extKeyUsage (extnId :== 2.5.29.37,critical :== FALSE)
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) authorityKeyIdentifier (extnId :== 2 5 29 35,critical :== FALSE)
AuthorityKeyIdentifier AuthorityKeyIdentifier

type: OCTET STRING

CA11:

5BF84D4FB2A586D43AD2F1639AA0BE09F657B7DE

subjectKeyIdentifier (extnId :== 2 5 29 14,critical :== FALSE)

JCSICA:

D3342FDDF84C99DE843F051DB9D9F440D9C08BB1

subjectKeyIdentifier (extnId :== 2 5 29 14,critical :== FALSE) Subject Key Identifier
SubjectKeyIdentifier The identifier for the public key

keyIdentifier

type: OCTET STRING

CA11

B94942CCDDD7429F7DA18FE3B608F5C9BA265596

Revocation checking of signer’s certificates

JCSICA

6C79367B36C0E483A2EBCF00A28455A040875122

Do not check revocation

> 6-3) SecureSign Root CA12 (RCA12) > > 6-4) SecureSign Root CA14 (RCA14) > > 6-5) SecureSign Root CA15 (RCA15) > > 6-6) Cybertrust Japan SureServer EV CA G7 (EVCA7) > > 6-7) Cybertrust Japan SureServer EV CA G8 (EVCA8) > > 6-8) Cybertrust Japan SureServer EV CA G9 (EVCA9) > > 6-9) Cybertrust Japan SureServer CA G7 (SSCA7) > > 6-10) Cybertrust Japan SureServer CA G8 (SSCA8) > > (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 TThe identifier for the signature algorithm used by the CA to sign this certificate

algorithm

Object ID for the signature algorithm *One of the following values:

type: OID

RCA12, EVCA7, and SSCA7:

1.2.840.113549.1.1.11 (sha256WithRSAEncryption)

RCA14, and EVCA9:

1.2.840.113549.1.1.12 (sha384WithRSAEncryption)

RCA15, EVCA8, and SSCA8:

1.2.840.10045.4.3.3 (ecdsa-with-SHA384)

parameters

Parameters of signature algorithm *Only for RCA12, RCA14, EVCA7, EVCA9, and SSCA7

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 *One of the following values:

type: PrintableString

RCA12:

SecureSign Root CA12

RCA14:

SecureSign Root CA14

RCA15:

SecureSign Root CA15

EVCA7:

Cybertrust Japan SureServer EV CA G7

EVCA8:

Cybertrust Japan SureServer EV CA G8

EVCA9:

Cybertrust Japan SureServer EV CA G9

SSCA7:

Cybertrust Japan SureServer CA G7

SSCA8:

Cybertrust Japan SureServer CA G8

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 *One of the following values:

type: PrintableString

RCA12:

SecureSign Root CA12 OCSP Responder

RCA14:

SecureSign Root CA14 OCSP Responder

RCA15:

SecureSign Root CA15 OCSP Responder

EVCA7:

Cybertrust Japan SureServer EV CA G7 OCSP Responder

EVCA8:

Cybertrust Japan SureServer EV CA G8 OCSP Responder

EVCA9:

Cybertrust Japan SureServer EV CA G9 OCSP Responder

SSCA7:

Cybertrust Japan SureServer CA G7 OCSP Responder

SSCA8:

Cybertrust Japan SureServer CA G8 OCSP Responder

subjectPublicKeyInfo value
SubjectPublicKeyInfo Subject’s public key information

AlgorithmIdentifier

The identifier for cryptographic algorithm

algorithm

Object ID for the cryptographic algorithm *One of the following values:

type: OID

RCA12, RCA14, EVCA7, EVCA9, and SSCA7:

1.2.840.113549.1.1.1 (rsaEncryption)

RCA15, EVCA8, and SSCA8:

1.2.840.10045.2.1 (id-ecPublicKey)

parameters

Parameters of cryptographic algorithm *One of the following values:

type: OID

RCA12, RCA14, EVCA7, EVCA9, and SSCA7:

NULL

RCA15, EVCA8, and SSCA8:

1.3.132.0.34 (secp384r1)

subjectPublicKey

Value of public key *One of the following values:

type: BIT STRING

RCA12, EVCA7, and SSCA7:

*Public key of 2048 bit size

RCA14, and EVCA9:

*Public key of 4096 bit size

RCA15, EVCA8, and SSCA8:

*Public key of 384 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 *One of the following values:

type: OCTET STRING

RCA12:

5734F374CF044BD525E6F140B62C4CD92DE9A0AD

RCA14:

0693A30A5E286937AA611DEBEBFC2D6F23E4F3A0

RCA15:

EB41C8AEFCD59E5148F5BD8BF4872093412BD3F4

EVCA7:

7483319BF875CD0DCF8E84E6D28E9AA6794C2AA6

EVCA8:

AEE4FDC16E22F8DFB71383F8E2D143B696B93AC8

EVCA9:

EDB8FA2F3D7D25BEE354B165CE54A8833B92F0C7

SSCA7:

8E3C286393A4E4850F5489DD69B23C52674AB5A4

SSCA8:

3DD29719E5391699EE6BB01B7AC6F3FACAF5F703

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
7. JCSI   SSL/TLS Certificate > (Standard Area)
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 TThe 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 the 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 the common name

type:OID

2.5.4.3

value

Value of common name

type:PrintableString

JCSI TLSSign Public CA
validity value
Validity Validity period of certificate

notBefore

The date on which the certificate validity period begins

type:UTCTime

*The date and time on which the certificate validity period begins

notAfter

The date on which the certificate validity period ends

type:UTCTime

*The date and time 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

JP
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

*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

*Locality name attribute of certificate subject
organizationName Organization name attribute of certificate issuer

type

Object ID for the organization name

type:OID

2.5.4.10

value

Value of organization name

type:PrintableString / UTF8String

*Organization name attribute of certificate subject
commonName Common name attribute of certificate issuer

type

Object ID for the common name

type:OID

2 5 4 3

value

Value of common name

type:PrintableString

* Common name attribute of certificate issuer

* FQDN of the SSL/TLS server

* Note: domain: managedpki.ne.jp
subjectPublicKeyInfo value
SubjectPublicKeyInfo Subject’s public key information

AlgorithmIdentifier

The identifier for the 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: OID

NULL

subjectPublicKey

Value of public key

type: BIT STRING

*The key size is depended on application
*The key size must be at least 2048 bit
> (Expansion Area)
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

1.2.392.200081.1.10.10

policyQualifiers

Information of the policy qualifiers

policyQualifierID

Classification of 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_rt/
PolicyInformation Information of the Policy

policyIdentifier

Object ID for the Policy

type:OID

2.23.140.1.2.2
subjectAltName (extnId :==2 5 29 17,critical :== FALSE) value
SubjectAltName Subject Alternative Name

dNSName

dnsName

type: IA5String

* FQDN of the SSL/TLS server

* Note: Domain: .managedpki.ne.jp

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: OCTET STRING

http://jcsitlssignpublicca-ocsp.
managedpki.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: OCTET STRING

http://rtcrl.managedpki.ne.jp/
SecureSignAD/JCSITLSSignPublicCA/SSAD-JCSITLS.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

D3342FDDF84C99DE843F051DB9D9F440D9C08BB1
cRLDistributionPoints (extnId :== 2 5 29 31,critical :== FALSE) value
cRLDistributionPoints CRL Distribution Point
DistributionPoint CRL Distribution Point
uniformResourceIdentifier URI of CRL Distribution Point

type: OCTET STRING

http://rtcrl.managedpki.ne.jp/
SecureSignAD/JCSITLSSign
PublicCA/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 the public key

type: OCTET STRING

* Hash value of subjectPublicKey
> **Appendix D: List of Revoked CAs** Root CAs None. Subordinate CA (Previously issued by JCSI)

Name of CA

SecureSignPublicCA11

Serial Number of CA Certificate

3

Validity Period of CA Certificate

April 9, 2009 to April 8, 2029

Hash value (SHA-1)

8D4E255F55392AB219D20A958D6591A42D284596

Hash value (SHA-256)

D0D672C2547D574AE055D9E78A993DDBCC74044C4253FBFACA573A67D368E1DB

Revocation Date

February 17, 2020 06:04:53 (UTC)

Revocation Reason

Cessation of operation

Root CA

SecureSign RootCA11 (JCSI Root CA)
Subordinate CA (Technically Constrained)

Name of CA

JCSI TLSSign Public CA

Serial Number of CA Certificate

1D0E228D02254C1A492974D4A3481E279008E152

Validity Period of CA Certificate

September 11, 2018 to April 8, 2029

Hash value (SHA-1)

78765DC77359B2811B6D29FFD8AF8FF960668D26

Hash value (SHA-256)

C10FBC46B289E81FAD197DDC7A61482A9846D064BEE84E3C2A7F5DAC2E3894EA

Revocation Date

October 11, 2018 01:50:33 (UTC)

Revocation Reason

Superseded

Root CA

SecureSign RootCA11 (JCSI Root CA)
Subordinate CA | Name of CA | Cybertrust Japan SureServer EV CA G4 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 2637AA218390223237789A9BAD8A7076E622B634 | | Validity Period of CA Certificate | April 9, 2020 to April 9, 2030 | | Hash value (SHA-1) | 5570C3D33BB080E7D35B5AAB3B70EA52011B1688 | | Hash value (SHA-256) | 399B950244EA52E374D2E4DE70A1CB872875F97E35516895B07E8CC5EB5A6B29 | | Revocation Date | June 21, 2020 17:11:38 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA12 | | Name of CA | Cybertrust Japan SureServer EV CA G5 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 3AD8B1A1D7334C9F62463939CBBB2C2CF4A9A438 | | Validity Period of CA Certificate | April 9, 2020 to April 9, 2030 | | Hash value (SHA-1) | 3BC8815266264418A0E7CFD44319DC4812753040 | | Hash value (SHA-256) | 5ED4D96D978FAB1760216B6D7C6C4F636BFAD0CA25AC85BA7AFC459AFE7DA9F2 | | Revocation Date | June 21, 2020 17:32:11 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA15 | | Name of CA | Cybertrust Japan SureServer EV CA G6 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 0498C56281A1A3819A30ADA18BBB4906E24CDE66 | | Validity Period of CA Certificate | June 3, 2020 to June 3, 2030 | | Hash value (SHA-1) | 799D8151CE5D2A951A29CCA646A7B6509BC44143 | | Hash value (SHA-256) | E8DC1CB6EAEC23B16BDF7E1BD57D25AB91975829953B3873483D54A6A465AA34 | | Revocation Date | June 21, 2020 17:22:42 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA14 | | Name of CA | Cybertrust Japan SureServer CA G5 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 79629546ABCD0B6293910AAE16D5594FDE8C3ABB | | Validity Period of CA Certificate | April 9, 2020 to April 9, 2030 | | Hash value (SHA-1) | 29924AB435117BD34627D640B8C6892733E0ED38 | | Hash value (SHA-256) | AAA47419211F74D5C719B8F023E450BC610E0BE9D65A7FDEBD3C9B0642C78B43 | | Revocation Date | June 21, 2020 17:13:23 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA12 | | Name of CA | Cybertrust Japan SureServer CA G6 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 15B79EA71C7B8CB19506AAFF5EF5017E8CD31AAA | | Validity Period of CA Certificate | April 9, 2020 to April 9, 2030 | | Hash value (SHA-1) | 804FCCF74C78FD39CB165EBD95F8384D9F9C8232 | | Hash value (SHA-256) | 7D494CE0DCF09312874C0296D4F8F9E2A7DA21CEE272201E56E905464FA6B3D6 | | Revocation Date | June 21, 2020 17:33:09 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA15 | | Name of CA | Cybertrust Japan SureMail CA G5 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 59562F1F81E6952E9AD89F430028201555B4A266 | | Validity Period of CA Certificate | April 9, 2020 to April 9, 2030 | | Hash value (SHA-1) | 7E1930F1329C8F895BDE50E6B0AD6B691ABD8E6E | | Hash value (SHA-256) | 5285CFADE33A396D22C8FF2368A9143821B3F1B0FF527F8883B36BB8A9E95A47 | | Revocation Date | June 21, 2020 17:15:03 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA12 | | Name of CA | Cybertrust Japan SureMail CA G6 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 40BF947ECB33AB9CDB43DEBCBE9A7A079F1EEFC2 | | Validity Period of CA Certificate | April 9, 2020 to April 9, 2030 | | Hash value (SHA-1) | CD0961FD4B900771F740F697932A21A56DA149B6 | | Hash value (SHA-256) | ED7685BBFCCB13134C04C4ED07F33D7361DC518B381916C402C0EE37B4B21CC0 | | Revocation Date | June 21, 2020 17:34:11 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA15 | | Name of CA | Cybertrust Japan SureCode EV CA G1 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 7AFCFB111FF70F66853C53910CF23FD51722743D | | Validity Period of CA Certificate | April 9, 2020 to April 9, 2036 | | Hash value (SHA-1) | 1A9F73CED9337336FA4F5A6B1B4764AAE3E4A953 | | Hash value (SHA-256) | 0C6F6C6F6AC9508DBE69D4BDDC0C6C4CB52E3A0B54975B3BE483449799E0F3D6 | | Revocation Date | June 21, 2020 17:24:02 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA14 | | Name of CA | Cybertrust Japan SureCode EV CA G2 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 2E0725B935D866072AA61B4BE5DAC81059145ED7 | | Validity Period of CA Certificate | April 9, 2020 to April 9, 2036 | | Hash value (SHA-1) | 5B685C7BB809DBD9A046F18D995977F85546B983 | | Hash value (SHA-256) | B040BDB929A9C292DFD76134E589538045C9D61EBBD139186422F56FAA4FB8E1 | | Revocation Date | June 21, 2020 17:35:06 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA15 | | Name of CA | Cybertrust Japan SureCode CA G1 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 1253A495AA2D9155A2FB649FB19C445512E172A4 | | Validity Period of CA Certificate | April 9, 2020 to April 9, 2036 | | Hash value (SHA-1) | DB4F530FE971742D128253BDACAD707AFD3A22AC | | Hash value (SHA-256) | C0BE67133B36BBEE3A05DC34FCFB866C0EE8EBC3D862B248A7EEC7E035B4A57A | | Revocation Date | June 21, 2020 17:25:14 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA14 | | Name of CA | Cybertrust Japan SureCode CA G2 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 02357E2E4380F68B22CE957CCF484EC34621E47F | | Validity Period of CA Certificate | April 9, 2020 to April 9, 2036 | | Hash value (SHA-1) | CCF09D79D8D571103405CE2425298F887A78C793 | | Hash value (SHA-256) | 6AA7415D875D7B8945AE8B61E2AF2E2E78C98E058B8C2D072D41B2D48483FAA1 | | Revocation Date | June 21, 2020 17:36:01 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA15 | | Name of CA | Cybertrust Japan SureTime CA G1 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 193A4704EF2D1D26D0D11D28FE44088473FD73EC | | Validity Period of CA Certificate | April 9, 2020 to April 9, 2036 | | Hash value (SHA-1) | 4D4F47A322CAFED27EF8E7FCD908B24A2B7EABFD | | Hash value (SHA-256) | AE5ECCCAD770233E9AC5A2CE773CE752EB8DF51D7EA6FFC70BFF687613BD84CE | | Revocation Date | June 21, 2020 17:26:16 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA14 | | Name of CA | Cybertrust Japan SureTime CA G2 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 076495342127D54FF3BFB5E350617FA716125A10 | | Validity Period of CA Certificate | April 9, 2020 to April 9, 2036 | | Hash value (SHA-1) | FA390AB94C7EEA8281F915F7E452CF6FA5B4B738 | | Hash value (SHA-256) | 2B1F4353FAC8EA7269E761C96DDC43AD73334B9717CB5F2426E38DE20E460609 | | Revocation Date | June 21, 2020 17:36:51 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA15 | | Name of CA | Cybertrust Japan SureTime CA G3 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 610BE2A6DFBED34D816E17F762066D8850DE8C04 | | Validity Period of CA Certificate | June 22, 2020 to June 22, 2036 | | Hash value (SHA-1) | EB07FE22E8F17CE7FF797FAF1B854DCED841EDAD | | Hash value (SHA-256) | CC0A0DF79B94888CB630FE07C43CF43E592813AE26D9141D410BAC0A16D7478C | | Revocation Date | September 21, 2022 13:33:19 (JST) | | Revocation Reason | Superseded | | Root CA | SecureSign Root CA14 | | Name of CA | Cybertrust Japan SureTime CA G4 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 4AF6C82119A300E57F8E9E99C0A24E28D6E8F30D | | Validity Period of CA Certificate | June 22, 2020 to June 22, 2036 | | Hash value (SHA-1) | 9E70C71AF24EF3FFE27878D5AA54E2BE5BB619A1 | | Hash value (SHA-256) | FF2D814C8D66794B383EACF5E1F2F44EB767F5C37C9855DC77A989680C6E8D47 | | Revocation Date | September 21, 2022 13:38:55 (JST) | | Revocation Reason | Superseded | | Root CA | SecureSign Root CA15 | | Name of CA | Cybertrust Japan SureMail CA G7 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 438AD46A876954D1F2AA7E8C8AC28200F24270BE | | Validity Period of CA Certificate | June 22, 2020 to June 22, 2030 | | Signature Algorithm | SHA256 with RSA | | Key Size of CA | 2048 bit | | Hash value (SHA-1) | E78CBAC46E1C13595B253492FF82C5B53EC4FD22 | | Hash value (SHA-256) | BE88404D1D6451268E1F90EC93BC2172876B22678E5405EACE95B1CDF35FAD07 | | Revocation Date | April 28, 2023 16:12:38 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA12 | | Name of CA | Cybertrust Japan SureMail CA G8 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 1D3F1E58E0DF9F5DCEA86CA9AFC5CAD5ADDB9C89 | | Validity Period of CA Certificate | June 22, 2020 to June 22, 2030 | | Signature Algorithm | ECDSA with SHA384 | | Key Size of CA | 384 bit | | Hash value (SHA-1) | 15ED815535775C8565E260EFD5827A37087CB15B | | Hash value (SHA-256) | 195FA1E40EDF0B1BDCB2C4F913DD5FD6CCB58891DF3B73E53C7AEB9AC3F86E28 | | Revocation Date | August 21, 2023 12:24:48 (JST) | | Revocation Reason | Superseded | | Root CA | SecureSign Root CA15 | | Name of CA | Cybertrust Japan SureMail CA G8 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 1FA4C422EADA4D67BE7EC31B75024A2DB55C0015 | | Validity Period of CA Certificate | August 21, 2023 to June 22, 2030 | | Signature Algorithm | ECDSA with SHA384 | | Key Size of CA | 384 bit | | Hash value (SHA-1) | 113F753E0D47D761623FC92FC561931D335746B4 | | Hash value (SHA-256) | 8FBD048775F6F4C486CF4960A7BB8B807225E37C74935E5B99CBA9E41383FECA | | Revocation Date | August 20, 2024 19:25:03 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA15 | | Name of CA | Cybertrust Japan SureCode EV CA G3 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 401C0824BBCEA63303FB626F7D613BFF01241FF6 | | Validity Period of CA Certificate | June 22, 2020 to June 22, 2036 | | Signature Algorithm | SHA384 with RSA | | Key Size of CA | 4096 bit | | Hash value (SHA-1) | 6261D96B51BFF7807F38B4A52E4155D89EFEF71E | | Hash value (SHA-256) | 87CC9D3EDF3F8517D922944AA114A5576AB4FD8DF09E35D10FF314C8EA172619 | | Revocation Date | August 20, 2024 19:12:54 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA14 | | Name of CA | Cybertrust Japan SureCode EV CA G4 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 3067E8FBFB2201DE04917E3AE9701115A580F9D1 | | Validity Period of CA Certificate | June 22, 2020 to June 22, 2036 | | Signature Algorithm | ECDSA with SHA384 | | Key Size of CA | 384 bit | | Hash value (SHA-1) | 542AA69A5F38DFD4CD9C41B03048B7BCE10124A7 | | Hash value (SHA-256) | AEEDAB7F871504EE07CEB3ED93AF034394548B1E655F7C759B9646AB78F0CEBB | | Revocation Date | August 20, 2024 19:27:05 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA15 | | Name of CA | Cybertrust Japan SureCode CA G3 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 605809FFFD7AD23CC7793CFC3181DE152DFE1C19 | | Validity Period of CA Certificate | June 22, 2020 to June 22, 2036 | | Signature Algorithm | SHA384 with RSA | | Key Size of CA | 4096 bit | | Hash value (SHA-1) | A50C5F28193A2F2971517BE5DD3C2212AAEE5376 | | Hash value (SHA-256) | A2383AF3FDE129CCFB7865D057D40A1A4BDA70E1E45C53E8BB58681AF62E1B4B | | Revocation Date | August 20, 2024 19:14:30 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA14 | | Name of CA | Cybertrust Japan SureCode CA G4 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 2141B3AAF2EFDF0F9FC1CBE2C6A8AB4E966DA06F | | Validity Period of CA Certificate | June 22, 2020 to June 22, 2036 | | Signature Algorithm | ECDSA with SHA384 | | Key Size of CA | 384 bit | | Hash value (SHA-1) | 7F466C2F01734A4034024DBD9E460515D3B80C76 | | Hash value (SHA-256) | 42A7E8F7E06F2FC1CE417B26AC6F724E7BCC520A3B64ED506C7AA0B6DA25D63E | | Revocation Date | August 20, 2024 19:28:31 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA15 | | Name of CA | Cybertrust Japan SureTime CA G3 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 47C05BCA232CA403ABA01603F0584B6B150ACFFB | | Validity Period of CA Certificate | September 9, 2021 to September 9, 2037 | | Signature Algorithm | SHA384 with RSA | | Key Size of CA | 4096 bit | | Hash value (SHA-1) | 3C050F28F197CE9BBE16EE6551C9530D838D9AD5 | | Hash value (SHA-256) | F8D976C1190F85B54EBD88B45986FCF475D1A58F8CFD1D70B0E40A6346BBA4A6 | | Revocation Date | August 20, 2024 19:15:53 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA14 | | Name of CA | Cybertrust Japan SureTime CA G4 | | :-------------------------------- | :--------------------------------------------------------------- | | Serial Number of CA Certificate | 3E745100E3A15C5D0288B4475F408E516A8337B5 | | Validity Period of CA Certificate | September 9, 2021 to September 9, 2037 | | Signature Algorithm | ECDSA with SHA384 | | Key Size of CA | 384 bit | | Hash value (SHA-1) | F95B7E1CA40A890941A5039DAD81463D92B3A4B7 | | Hash value (SHA-256) | 5022E703CD525D1D45F8CAB522C00B8D371891C9995D28F36E12906B8D1E9EBE | | Revocation Date | August 20, 2024 19:29:50 (JST) | | Revocation Reason | Cessation of operation | | Root CA | SecureSign Root CA15 |