### 4.1.1 Who can submit a certificate application

### 4.1.2 Enrollment process and responsibilities Prior to the issuance of a Certificate, the CA SHALL obtain the following documentation from the Applicant: 1. A certificate request, which may be electronic; and 2. An executed Subscriber Agreement or Terms of Use, which may be electronic. The CA SHOULD obtain any additional documentation the CA determines necessary to meet these Requirements. Prior to the issuance of a Certificate, the CA SHALL obtain from the Applicant a certificate request in a form prescribed by the CA and that complies with these Requirements. One certificate request MAY suffice for multiple Certificates to be issued to the same Applicant, subject to the aging and updating requirement in [Section 4.2.1](#421-performing-identification-and-authentication-functions), provided that each Certificate is supported by a valid, current certificate request signed by the appropriate Applicant Representative on behalf of the Applicant. The certificate request MAY be made, submitted and/or signed electronically. The certificate request MUST contain a request from, or on behalf of, the Applicant for the issuance of a Certificate, and a certification by, or on behalf of, the Applicant that all of the information contained therein is correct.

### 4.2.1 Performing identification and authentication functions The certificate request MAY include all factual information about the Applicant to be included in the Certificate, and such additional information as is necessary for the CA to obtain from the Applicant in order to comply with these Requirements and the CA's Certificate Policy and/or Certification Practice Statement. In cases where the certificate request does not contain all the necessary information about the Applicant, the CA SHALL obtain the remaining information from the Applicant or, having obtained it from a reliable, independent, third-party data source, confirm it with the Applicant. The CA SHALL establish and follow a documented procedure for verifying all data requested for inclusion in the Certificate by the Applicant. Applicant information MUST include, but not be limited to, at least one Fully-Qualified Domain Name or IP address to be included in the Certificate's `subjectAltName` extension. [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) limits the validity period of Subscriber Certificates. The CA MAY use the documents and data provided in [Section 3.2](#32-initial-identity-validation) to verify certificate information, or may reuse previous validations themselves, provided that the CA obtained the data or document from a source specified under [Section 3.2](#32-initial-identity-validation) or completed the validation itself within the maximum number of days prior to issuing the Certificate, as defined in the following table: Table: Subject Identity Information validation data reuse periods | __Certificate issued on or after__ | __Certificate issued before__ | __Maximum data reuse period__ | | -- | -- | -- | | | March 15, 2026 | 825 days | | March 15, 2026 | | 398 days | For validation of Domain Names and IP Addresses according to [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) and [Section 3.2.2.5](#3225-authentication-for-an-ip-address), any data, document, or completed validation used MUST be obtained within the maximum number of days prior to issuing the Certificate, as defined in the following table: Table: Domain Name and IP Address validation data reuse periods | __Certificate issued on or after__ | __Certificate issued before__ | __Maximum data reuse period__ | | -- | -- | -- | | | March 15, 2026 | 398 days | | March 15, 2026 | March 15, 2027 | 200 days | | March 15, 2027 | March 15, 2029 | 100 days | | March 15, 2029 | | 10 days | In no case may a prior validation be reused if any data or document used in the prior validation was obtained more than the maximum time permitted for reuse of the data or document prior to issuing the Certificate. After the change to any validation method specified in the Baseline Requirements or EV Guidelines, a CA may continue to reuse validation data or documents collected prior to the change, or the validation itself, for the period stated in [Section 4.2.1](#421-performing-identification-and-authentication-functions) unless otherwise specifically provided in a ballot. The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate's approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements. If a Delegated Third Party fulfills any of the CA's obligations under this section, the CA SHALL verify that the process used by the Delegated Third Party to identify and further verify High Risk Certificate Requests provides at least the same level of assurance as the CA's own processes.

### 4.2.2 Approval or rejection of certificate applications CAs SHALL NOT issue certificates containing Internal Names or Reserved IP Addresses, as such names cannot be validated according to [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) or [Section 3.2.2.5](#3225-authentication-for-an-ip-address).

### 4.2.3 Time to process certificate applications

### 4.3.1 CA actions during certificate issuance

### 4.3.2 Notification to subscriber by the CA of issuance of certificate

### 4.4.1 Conduct constituting certificate acceptance

### 4.4.2 Publication of the certificate by the CA

### 4.4.3 Notification of certificate issuance by the CA to other entities

### 4.5.1 Subscriber private key and certificate usage See [Section 9.6.3](#963-subscriber-representations-and-warranties), provisions 2. and 4.

### 4.5.2 Relying party public key and certificate usage

### 4.6.1 Circumstance for certificate renewal

### 4.6.2 Who may request renewal

### 4.6.3 Processing certificate renewal requests

### 4.6.4 Notification of new certificate issuance to subscriber

### 4.6.5 Conduct constituting acceptance of a renewal certificate

### 4.6.6 Publication of the renewal certificate by the CA

### 4.6.7 Notification of certificate issuance by the CA to other entities

### 4.7.1 Circumstance for certificate re-key

### 4.7.2 Who may request certification of a new public key

### 4.7.3 Processing certificate re-keying requests

### 4.7.4 Notification of new certificate issuance to subscriber

### 4.7.5 Conduct constituting acceptance of a re-keyed certificate

### 4.7.6 Publication of the re-keyed certificate by the CA

### 4.7.7 Notification of certificate issuance by the CA to other entities

### 4.8.1 Circumstance for certificate modification

### 4.8.2 Who may request certificate modification

### 4.8.3 Processing certificate modification requests

### 4.8.4 Notification of new certificate issuance to subscriber

### 4.8.5 Conduct constituting acceptance of modified certificate

### 4.8.6 Publication of the modified certificate by the CA

### 4.8.7 Notification of certificate issuance by the CA to other entities

### 4.9.1 Circumstances for revocation

### 4.9.2 Who can request revocation The Subscriber, RA, or Issuing CA can initiate revocation. Additionally, Subscribers, Relying Parties, Application Software Suppliers, and other third parties may submit Certificate Problem Reports informing the issuing CA of reasonable cause to revoke the certificate.

### 4.9.3 Procedure for revocation request The CA SHALL provide a process for Subscribers to request revocation of their own Certificates. The process MUST be described in the CA's Certificate Policy or Certification Practice Statement. The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and Certificate Problem Reports. The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in Section 1.5.2 of their CPS.

### 4.9.4 Revocation request grace period

### 4.9.5 Time within which CA must process the revocation request Within 24 hours after receiving a Certificate Problem Report, the CA SHALL investigate the facts and circumstances related to a Certificate Problem Report and provide a preliminary report on its findings to both the Subscriber and the entity who filed the Certificate Problem Report. After reviewing the facts and circumstances, the CA SHALL work with the Subscriber and any entity reporting the Certificate Problem Report or other revocation-related notice to establish whether or not the certificate will be revoked, and if so, a date which the CA will revoke the certificate. The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation MUST NOT exceed the time frame set forth in [Section 4.9.1.1](#4911-reasons-for-revoking-a-subscriber-certificate). The date selected by the CA SHOULD consider the following criteria: 1. The nature of the alleged problem (scope, context, severity, magnitude, risk of harm); 2. The consequences of revocation (direct and collateral impacts to Subscribers and Relying Parties); 3. The number of Certificate Problem Reports received about a particular Certificate or Subscriber; 4. The entity making the complaint (for example, a complaint from a law enforcement official that a Web site is engaged in illegal activities should carry more weight than a complaint from a consumer alleging that they didn't receive the goods they ordered); and 5. Relevant legislation.

### 4.9.6 Revocation checking requirement for relying parties **Note**: Following certificate issuance, a certificate may be revoked for reasons stated in [Section 4.9](#49-certificate-revocation-and-suspension). Therefore, relying parties should check the revocation status of all certificates that contain a CDP or OCSP pointer.

### 4.9.7 CRL issuance frequency CRLs MUST be available via a publicly-accessible HTTP URL (i.e., "published"). Within twenty-four (24) hours of issuing its first Certificate, the CA MUST generate and publish either: - a full and complete CRL; OR - partitioned (i.e., "sharded") CRLs that, when aggregated, represent the equivalent of a full and complete CRL. CAs issuing Subscriber Certificates: 1. MUST update and publish a new CRL at least every: - seven (7) days if all Certificates include an Authority Information Access extension with an id-ad-ocsp accessMethod ("AIA OCSP pointer"); or - four (4) days in all other cases; 2. MUST update and publish a new CRL within twenty-four (24) hours after recording a Certificate as revoked. CAs issuing CA Certificates: 1. MUST update and publish a new CRL at least every twelve (12) months; 2. MUST update and publish a new CRL within twenty-four (24) hours after recording a Certificate as revoked. CAs MUST continue issuing CRLs until one of the following is true: - all Subordinate CA Certificates containing the same Subject Public Key are expired or revoked; OR - the corresponding Subordinate CA Private Key is destroyed.

### 4.9.8 Maximum latency for CRLs (if applicable)

### 4.9.9 On-line revocation/status checking availability The validity interval of an OCSP response is the difference in time between the `thisUpdate` and `nextUpdate` field, inclusive. For purposes of computing differences, a difference of 3,600 seconds shall be equal to one hour, and a difference of 86,400 seconds shall be equal to one day, ignoring leap-seconds. A certificate serial is "assigned" if: - a Certificate or Precertificate with that serial number has been issued by the Issuing CA; or - a Precertificate with that serial number has been issued by a Precertificate Signing Certificate, as defined in [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile), associated with the Issuing CA. A certificate serial is "unassigned" if it is not "assigned". The following SHALL apply for communicating the status of Certificates and Precertificates which include an Authority Information Access extension with an id-ad-ocsp accessMethod. OCSP responders operated by the CA SHALL support the HTTP GET method, as described in RFC 6960 and/or RFC 5019. The CA MAY process the Nonce extension (`1.3.6.1.5.5.7.48.1.2`) in accordance with RFC 8954. For the status of a Subscriber Certificate or its corresponding Precertificate: - Effective 2025-01-15, an authoritative OCSP response MUST be available (i.e. the responder MUST NOT respond with the "unknown" status) starting no more than 15 minutes after the Certificate or Precertificate is first published or otherwise made available. - For OCSP responses with validity intervals less than sixteen hours, the CA SHALL provide an updated OCSP response prior to one-half of the validity period before the nextUpdate. - For OCSP responses with validity intervals greater than or equal to sixteen hours, the CA SHALL provide an updated OCSP response at least eight hours prior to the nextUpdate, and no later than four days after the thisUpdate. For the status of a Subordinate CA Certificate, the CA SHALL provide an updated OCSP response at least every twelve months, and within 24 hours after revoking the Certificate. The following SHALL apply for communicating the status of *all* Certificates for which an OCSP responder is willing or required to respond. OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST either: 1. be signed by the CA that issued the Certificates whose revocation status is being checked, or 2. be signed by an OCSP Responder which complies with the OCSP Responder Certificate Profile in [Section 7.1.2.8](#7128-ocsp-responder-certificate-profile). OCSP responses for Subscriber Certificates MUST have a validity interval greater than or equal to eight hours and less than or equal to ten days. If the OCSP responder receives a request for the status of a certificate serial number that is "unassigned", then the responder SHOULD NOT respond with a "good" status. If the OCSP responder is for a CA that is not Technically Constrained in line with [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) or [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile), the responder MUST NOT respond with a "good" status for such requests.

### 4.9.10 On-line revocation checking requirements No Stipulation.

### 4.9.11 Other forms of revocation advertisements available No Stipulation.

### 4.9.12 Special requirements re key compromise See [Section 4.9.1](#491-circumstances-for-revocation).

### 4.9.13 Circumstances for suspension The Repository MUST NOT include entries that indicate that a Certificate is suspended.

### 4.9.14 Who can request suspension Not applicable.

### 4.9.15 Procedure for suspension request Not applicable.

### 4.9.16 Limits on suspension period Not applicable.

### 4.10.1 Operational characteristics Revocation entries on a CRL or OCSP Response MUST NOT be removed until after the Expiry Date of the revoked Certificate.

### 4.10.2 Service availability The CA SHALL operate and maintain its CRL and optional OCSP capability with resources sufficient to provide a response time of ten seconds or less under normal operating conditions. The CA SHALL maintain an online 24x7 Repository that application software can use to automatically check the current status of all unexpired Certificates issued by the CA. The CA SHALL maintain a continuous 24x7 ability to respond internally to a high-priority Certificate Problem Report, and where appropriate, forward such a complaint to law enforcement authorities, and/or revoke a Certificate that is the subject of such a complaint.

### 4.10.3 Optional features

### 4.12.1 Key escrow and recovery policy and practices

### 4.12.2 Session key encapsulation and recovery policy and practices Not applicable.