Выпуск Code Signing сертификата-Требования CAB Forum для верификации организации Украина ☎ +380672576220 

☎ +380443834054
☎ +380672576220
Ukrainian Symantec Partner
Ukrainian DigiCert Partner
Контакты
Правила выпуска Code Signing сертификатов
для верификации автора и защиты кода от изменения

Переход на сайт по продаже сертификатов SSL и подписи кода документов почты CSR
pKey
Установка
SSL
Цепочка
SSL
Проверка
SSL
Seal
SSL
Экспорт-Импорт
Конвертер
Code Sign
сертификаты
Email Smime
сертификаты
PDF и Word
сертификаты
База
знаний

Правила CodeSign сертификатов
Помощь
Index
1. Scope
2. Purpose
3. References
4. Definitions
5. Abbreviations and Acronyms
6. Conventions
7. Certificate Warranties and Representations
7.1Certificate Beneficiaries
7.2 Certificate Warranties
7.3 Applicant Warranty
8. Community and Applicability
8.1 Compliance
8.2 Certificate Policies
8.2.1 Implementation
8.2.2 Disclosure
8.3 Commitment to Comply
8.4 Trust model
9. Certificate Content and Profile
9.1 Issuer Information
9.2 Subject Information
9.2.1 Subject Alternative Name Extension
9.2.2 Subject Common Name Field
9.2.3 Subject Domain Component Field
9.2.4 Subject Distinguished Name Fields
9.2.5 Reserved
9.2.6 Subject Organizational Unit Field
9.2.7 Reserved
9.2.8 Other Subject Attributes
9.3 Certificate Policy Identification
9.3.1 Certificate Policy Identifiers
9.3.2 Root CA Requirements
9.3.3 Subordinate CA Certificates
9.3.4 Subscriber Certificates
9.4 Maximum Validity Period
9.5 Subscriber Public Key
9.6 Certificate Serial Number
9.7 Reserved
9.8 Reserved
10. Certificate Request
10.1 Documentation Requirements
10.2 Certificate Request
10.2.1 General
10.2.2 Request and Certification
10.2.3 Information Requirements
10.2.4 Subscriber Private Key
10.3 Subscriber Agreement
10.3.1 General
10.3.2 Agreement Requirements
10.3.3 Service Agreement Requirements for Signing Authorities
11. Verification Practices
11.1 Verification of Organizational Applicants
11.1.1 Organization Identity and Address
11.1.2 DBA/Tradename
11.1.3 Requester Authority
11.2 Verification of Individual Applicants
11.2.1 Individual Identity
11.2.2 Authenticity of Identity
11.3 Age of Certificate Data
11.4 Denied List
11.5 High Risk Certificate Requests
11.6 Data Source Accuracy
11.7 Processing High Risk Applications
11.8 Due Diligence
12. Certificate Issuance by a Root CA
13. Certificate Revocation and Status Checking
13.1 Revocation
13.1.1 Revocation Request
13.1.2 Certificate Problem Reporting
13.1.3 Investigation
13.1.4 Response
13.1.5 Reasons for Revoking a Subscriber Certificate
13.1.6 Reasons for Revoking a Subordinate CA Certificate
13.1.7 Certificate Revocation Date
13.2 Certificate Status Checking
14. Employees and Third Parties
14.1 Trustworthiness and Competence
14.2 Delegation of Functions to Registration Authorities and Subcontractors
14.2.1 General
14.2.2 Compliance Obligation
14.2.3 Allocation of Liability
15. Data Records
16. Data Security and Private Key Protection
16.1 Timestamp Authority Key Protection
16.2 Signing Service Requirements
16.3 Subscriber Private Key Protection
17. Audit (39)
17.1 Eligible Audit Schemes
17.2 Audit Period
17.3 Audit Report
17.4 Pre-Issuance Readiness Audit
17.5 Audit of Delegated Functions
17.6 Auditor Qualifications
17.7 Key Generation Ceremony
18. Liability and Indemnification
Appendix A - Minimum Cryptographic Algorithm and Key Size Requirements
Appendix B - Certificate Extensions (Normative)
Appendix C - User Agent Verification (Normative)
Appendix D - High Risk Regions of Concern

We are an Authorized Reseller for DigiCert™ SSL a WebTrust Certified
SSL Certificate Authority.

11. Verification Practices

11.1 Verification of Organizational Applicants

Prior to issuing a Code Signing Certificate to an Organizational Applicant, the Issuer MUST:

1. Verify the Subject’s legal identity, including any DBA proposed for inclusion in a Certificate, in accordance with Section 11.1.1 and 11.1.2 of this document,

2. Verify the Subject’s address in accordance with Section 11.1.1 of this document,

3. Verify the Certificate Requester’s authority to request a Code Signing Certificate and the authenticity of the Certificate Request using a Reliable Method of Communication in accordance with BR Section 3.2.5., and

4. If the Subject’s or Subject’s Affiliate’s, Parent Company’s, or Subsidiary Company’s date of formation, as indicated by either a QIIS or QGIS, was less than three years prior to the date of the Certificate Request, verify the identity of the Certificate Requester.

11.1.1 Organization Identity and Address

As specified in BR Section 3.2.2.1. The CA MUST also obtain, whenever available, a specific Registration Identifier assigned to the Applicant by a government agency in the jurisdiction of the Applicant’s legal creation, existence, or recognition.

11.1.2 DBA/Tradename

As specified in BR Section 3.2.2.2.

11.1.3 Requester Authority

As specified in BR Section 3.2.5.

11.2 Verification of Individual Applicants

Prior to issuing a Code Signing Certificate to an Individual Applicant, the CA MUST:

1. Verify the Subject’s identity under Section 11.2.1 of this document, and

2. Verify the authenticity of the identity under Section 11.2.2 of this document.

11.2.1 Individual Identity

The CA MUST verify the Applicant’s identity using one of the following processes:

1. The CA MUST obtain a legible copy, which discernibly shows the Requester’s face, of at least one currently valid government-issued photo ID (passport, driver’s license, military ID, national ID, or equivalent document type). The CA MUST inspect the copy for any indication of alteration or falsification. The CA MUST also verify the address of the Requester using (i) a government-issued photo ID, (ii) a QIIS or QGIS, or (iii) an access code to activate the Certificate where the access code was physically mailed to the Requester; OR

2. The CA MUST have the Requester digitally sign the Certificate Request using a valid personal Certificate that was issued under one of the following adopted standards: Qualified Certificates issued pursuant to ETSI TS 101 862, IGTF, Adobe Signing Certificate issued under the AATL or CDS program, the Kantara identity assurance framework at level 2, NIST SP 800-63 at level 2, or the FBCA CP at Basic or higher assurance.

11.2.2 Authenticity of Identity

The CA MUST verify the authenticity of the Certificate Request using one of the following:

1. Having the Requester provide a photo of the Requester holding the submitted government- issued photo ID where the photo is of sufficient quality to read both the name listed on the photo ID and the issuing authority; OR

2. Having the CA perform an in-person or web camera-based verification of the Requester where an employee or contractor of the CA can see the Requester, review the Requester’s photo ID, and confirm that the Requester is the individual identified in the submitted photo ID; OR

3. Having the CA obtain an executed Declaration of Identity of the Requester that includes at least one unique biometric identifier (such as a fingerprint or handwritten signature). The CA MUST confirm the document’s authenticity directly with the Verifying Person using contact information confirmed with a QIIS or QGIS; OR

4. Verifying that the digital signature used to sign the Request under Section 11.2.1(2) is a valid signature and originated from a Certificate issued at the appropriate level of assurance as evidenced by the certificate chain. Acceptable verification under this section includes validation that the Certificate was issued by a CA qualified by the entity responsible for adopting, enforcing, or maintaining the adopted standard and chains to an intermediate certificate or root certificate designated as complying with such standard.

11.3 Age of Certificate Data

As specified in BR Section 3.3.1.

11.4 Denied List

As specified in BR Section 4.1.1.

11.5 High Risk Certificate Requests

In addition to the proceduresSHOULD required by BR Section 4.2.1, prior to issuing a Code Signing

Certificate, each CA check at least one database containing information about known or suspected producers, publishers, or distributors of Suspect Code, as identified or indicated by an Anti-Malware Organization and any database of deceptive names maintained by an Application Software Provider. The CA MUST determine whether the entity is identified as requesting a Code Signing Certificate from a High Risk Region of Concern. The CA MUST also maintain and check an internal database listing Certificates revoked due to Signatures on Suspect Code and previous certificate requests rejected by the CA.

A CA identifying a high risk application under this section MUST follow the additional procedures defined in Section 11.7 of this document to ensure that the applicant will protect its Private Keys and not sign Suspect Code.

[These requirements do not specify a particular database and leave the decision of qualifying databases to the implementers.]

11.6 Data Source Accuracy

As specified in BR Section 3.2.2.7.

11.7 Processing High Risk Applications

CAs MUST not issue new or replacement Code Signing Certificates to an entity that the CA determined intentionally signed Suspect Code. The CA MUST keep meta-data about the reason for revoking a Code Signing Certificate as proof that the Code Signing Certificate was not revoked because the Applicant was intentionally signing Suspect Code.

CAs MAY issue new or replacement Code Signing Certificates to an entity who is the victim of a documented Takeover Attack, resulting in either a loss of control of their code-signing service or loss of the Private Key associated with their Code Signing Certificate.

If the CA is aware that the Applicant was the victim of a Takeover Attack, the CA MUST verify that the Applicant is protecting its Code Signing Private Keys under Section 16.3(1) or Section 16.3(2). The CA MUST verify the Applicant’s compliance with Section 16.3(1) or Section 16.3(2) (i) through technical means that confirm the Private Keys are protected using the method described in 16.3(1) or 16.3.2(2) or (ii) by relying on a report provided by the Applicant that is signed by an auditor who is approved by the CA and who has IT and security training or is a CISA.

Documentation of a Takeover Attack MAY include a police report (validated by the CA) or public news report that admits that the attack took place. The Subscriber MUST provide a report from an auditor with IT and security training or a CISA that provides information on how the Subscriber was storing and using Private keys and how the intended solution for better security meets the guidelines for improved security.

Except where issuance is expressly authorized by the Application Software Supplier, CAs MUST not issue new Code Signing Certificates to an entity where the CA is aware that the entity has been the victim of two Takeover Attacks or where the CA is aware that entity breached a requirement under this Section to protect Private Keys under either Section 16.3(1) or 16.3(2).

11.8 Due Diligence

1.The results of the verification processes and procedures outlined in these Requirements are intended to be viewed both individually and as a group. Thus, after all of the verification processes and procedures are completed, the CA MUST have a person who is not responsible for the collection of information review all of the information and documentation assembled in support of the Code Signing Certificate application and look for discrepancies or other details requiring further explanation.

2.The CA MUST obtain and document further explanation or clarification from Applicant and other sources of information, as necessary, to resolve those discrepancies or details that require further explanation.

3.The CA MUST refrain from issuing a Code Signing Certificate until all of the information and documentation assembled in support of the Certificate is such that issuance of the Certificate will not communicate factual information that the CA knows, or with the exercise of due diligence should discover from the assembled information and documentation, to be inaccurate. If satisfactory explanation and/or additional documentation are not received within a reasonable time, the CA MUST decline the Certificate request and SHOULD notify the Applicant accordingly. 


 DV SSL OV Сертификаты подтверждающие только Домен OV SSL OV Сертификаты подтверждающие Домен и Организацию EV SSL EV Зеленые усиленные сертификаты с указанием названия Организации подтверждают Домен и Организацию WC SSL wildcard Сертификаты защищающие все субдомены. Класс DV OV и EV SAN SSL SAN Мульти доменные  сертификаты защищающие несколько FQDN Доменов. Класс DV OV и EV PRO SSL SGC PRO сертификаты с технологией  Server Gated Cryptography. Класс  OV и EV CodeSign Сертификаты для подписи приложений и програмного кода MS, Java. Класс  OV и EV Email Сертификаты для подписи емаил smime. Класс  DV OV PDF Сертификаты для подписи документов PDF. Класс  OV PV Wi-Fi Сертификаты DigiCert для IoT и Wi Fi IoT Сертификаты DigiCert для IIoT ALL Все сертификаты Symantec Familie: Symantec, thawte, GeoTrust, DigiCert Купить сертификат

NO russia - мы не осблуживаем резидентов из россии Copyright © 1997-2018 adgrafics