4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

4.1 Certificate application

4.1.1 Who can submit a certificate application

Anyone may submit an application for a certificate via the ACME protocol. Issuance will depend on proper validation and compliance with ISRG policies.

4.1.2 Enrollment process and responsibilities

The enrollment process involves the following steps, in no particular order:

• Generating a key pair using secure methods
• Submitting a request for a certificate containing all necessary information, including the public key
• Agreeing to the relevant Subscriber Agreement

4.2 Certificate application processing

4.2.1 Performing identification and authentication functions

ISRG performs all identification and authentication functions in accordance with the ISRG CP. This includes validation per CPS Section 3.2.2.

ISRG checks for relevant CAA records prior to issuing certificates. The CA acts in accordance with CAA records if present. The CA’s CAA identifying domain is ‘letsencrypt.org’.

4.2.2 Approval or rejection of certificate applications

Approval requires successful completion of validation per Section 3.2.2 as well as compliance with all CA policies.

Certificates containing a new gTLD under consideration by ICANN will not be issued. The CA Server will periodically be updated with the latest version of the Public Suffix List and will consult the ICANN domains section for every requested DNS identifier. CA server will not validate or issue for DNS identifiers that do not have a Public Suffix in the ICANN domains section. The Public Suffix List is updated when new gTLDs are added, and never includes new gTLDs before they are resolvable.

ISRG maintains a list of high-risk domains and blocks issuance of certificates for those domains. Requests for removal from the high-risk domains list will be considered, but will likely require further documentation confirming control of the domain from the Applicant, or other proof as deemed necessary by ISRG management.

4.2.3 Time to process certificate applications

No stipulation.

4.3 Certificate issuance

4.3.1 CA actions during certificate issuance

Certificates issued by the Root CA require an individual authorized by ISRG to deliberately issue a direct command in order for the Root CA to perform a certificate signing operation.

The source of a certificate request is confirmed before issuance. CA processes are protected from unauthorized modification during certificate issuance. Issued certificates are stored in a database and then made available to the Subscriber.

4.3.2 Notification to subscriber by the CA of issuance of certificate

End-entity certificates are made available to Subscribers via the ACME protocol as soon after issuance as reasonably possible. Typically this happens within a few seconds.

4.4 Certificate acceptance

4.4.1 Conduct constituting certificate acceptance

See ISRG CP Section 4.4.1.

4.4.2 Publication of the certificate by the CA

All root and intermediate certificates are made available publicly via the Certificate Repository.

All end-entity certificates are made available to Subscribers via the ACME protocol.

For each end-entity certificate issuance, ISRG signs a Precertificate and submits it to a selection of Certificate Transparency logs. Upon successful submission, ISRG will attempt to issue a certificate that matches the Precertificate (per RFC 6962 Section 3.1) and embeds at least two of the resulting Signed Certificate Timestamps (SCTs). ISRG submits the resulting final certificate to a selection of Certificate Transparency logs on a best-effort basis.

ISRG does not guarantee issuance of a final certificate for every Precertificate.

4.4.3 Notification of certificate issuance by the CA to other entities

See Section 4.4.2.

4.5 Key pair and certificate usage

4.5.1 Subscriber private key and certificate usage

Subscribers are obligated to generate Key Pairs using reasonably trustworthy systems.

Subscribers are obligated to take reasonable measures to protect their Private Keys from unauthorized use or disclosure (which constitutes compromise). Subscribers must discontinue use of any Private Keys that are known or suspected to have been compromised.

Certificates must be used in accordance with their intended purpose, which is outlined in this CPS and the associated CP. Subscribers must cease use of certificates being used outside of their intended purpose.

4.5.2 Relying party public key and certificate usage

Relying Parties must fully evaluate the context in which they are relying on certificates and the information contained in them, and decide to what extent the risk of reliance is acceptable. If the risk of relying on a certificate is determined to be unacceptable, then Relying Parties should not use the certificate or should obtain additional assurances before using the certificate.

ISRG does not warrant that any software used by Relying Parties to evaluate or otherwise handle certificates does so properly.

Relying Parties ignoring certificate expiration, revocation data provided via OCSP or CRL, or other pertinent information do so at their own risk.

4.6 Certificate renewal

Certificate renewal requests are treated as applications for new certificates.

4.6.1 Circumstance for certificate renewal

No stipulation.

4.6.2 Who may request renewal

No stipulation.

4.6.3 Processing certificate renewal requests

No stipulation.

4.6.4 Notification of new certificate issuance to subscriber

No stipulation.

4.6.5 Conduct constituting acceptance of a renewal certificate

No stipulation.

4.6.6 Publication of the renewal certificate by the CA

No stipulation.

4.6.7 Notification of certificate issuance by the CA to other entities

No stipulation.

4.7 Certificate re-key

Certificate re-key requests are treated as applications for new certificates.

4.7.1 Circumstance for certificate re-key

No stipulation.

4.7.2 Who may request certification of a new public key

No stipulation.

4.7.3 Processing certificate re-keying requests

No stipulation.

4.7.4 Notification of new certificate issuance to subscriber

No stipulation.

4.7.5 Conduct constituting acceptance of a re-keyed certificate

No stipulation.

4.7.6 Publication of the re-keyed certificate by the CA

No stipulation.

4.7.7 Notification of certificate issuance by the CA to other entities

No stipulation.

4.8 Certificate modification

Certificate modification requests are treated as applications for new certificates.

4.8.1 Circumstance for certificate modification

No stipulation.

4.8.2 Who may request certificate modification

No stipulation.

4.8.3 Processing certificate modification requests

No stipulation.

4.8.4 Notification of new certificate issuance to subscriber

No stipulation.

4.8.5 Conduct constituting acceptance of modified certificate

No stipulation.

4.8.6 Publication of the modified certificate by the CA

No stipulation.

4.8.7 Notification of certificate issuance by the CA to other entities

No stipulation.

4.9 Certificate revocation and suspension

Certificate revocation permanently ends the certificate’s operational period prior to its stated validity period.

4.9.1 Circumstances for revocation

ISRG will follow the ISRG CP and revoke a certificate in accordance with Section 4.9.1.1 and Section 4.9.1.2 of the ISRG CP.

ISRG maintains a continuous (24x7x365) ability to accept and respond to revocation requests and related inquiries.

4.9.2 Who can request revocation

Anyone can revoke any certificate via the ACME API if they can sign the revocation request with the private key associated with the certificate. No other information is required in such cases. A number of ACME clients support this functionality.

Anyone can revoke any certificate via the ACME API if they can demonstrate control over all domains covered by the certificate. No other information is required in such cases. A number of ACME clients support this functionality.

Subscribers can revoke certificates belonging to their accounts via the ACME API if they can sign the revocation request with the associated account private key. No other information is required in such cases. A number of ACME clients support this.

Certificates may be administratively revoked by ISRG if it is determined that the Subscriber has failed to meet obligations under the CP, this CPS, the relevant Subscriber Agreement, or any other applicable agreement, regulation, or law. Certificates may also be administratively revoked at the discretion of ISRG management.

4.9.3 Procedure for revocation request

Revocation requests may be made at any time via the ACME API. Successful revocation requests with a reason code of keyCompromise will result in the affected key being blocked for future issuance and all currently valid certificates with that key will be revoked.

Requests for revocation may also be made by emailing cert-prob-reports@letsencrypt.org. ISRG will respond to such requests within 24 hours, though an investigation into the legitimacy of the request may take longer.

An investigation into whether revocation or other appropriate action is warranted will be based on at least the following criteria:

1. The nature of the alleged problem;
2. The number of Certificate Problem Reports received about a particular Certificate or Subscriber;
3. The entity making the complaint; and
4. Relevant legislation.

4.9.4 Revocation request grace period

There is no grace period for a revocation request. A revocation request must be made as soon as circumstances requiring revocation are confirmed.

4.9.5 Time within which CA must process the revocation request

Investigation into a revocation request will begin within 24 hours of receiving the request.

Once a decision has been made to revoke a certificate, revocation will be carried out within 24 hours.

4.9.6 Revocation checking requirement for relying parties

Relying Parties who cannot or choose not to check revocation status, but decide to rely on a certificate anyway, do so at their own risk.

See Section 4.5.2.

4.9.7 CRL issuance frequency (if applicable)

ISRG will issue updated CRLs for intermediate certificates with a frequency greater than or equal to that required by the ISRG CP.

ISRG does not issue CRLs for end-entity certificates.

4.9.8 Maximum latency for CRLs (if applicable)

When a CRL is requested by a Relying Party the time to receive a response will be less than ten seconds under normal operating conditions.

4.9.9 On-line revocation/status checking availability

Revocation information for all certificates is made available via OCSP. OCSP responses are available at all times (24x7x365) if possible.

4.9.10 On-line revocation checking requirements

See Section 4.9.6.

4.9.11 Other forms of revocation advertisements available

ISRG allows for OCSP stapling.

4.9.12 Special requirements re key compromise

No stipulation.

4.9.13 Circumstances for suspension

ISRG does not suspend certificates.

4.9.14 Who can request suspension

Not applicable.

4.9.15 Procedure for suspension request

Not applicable.

4.9.16 Limits on suspension period

Not applicable.

4.10 Certificate status services

4.10.1 Operational characteristics

CRL entries for intermediate certificates will remain in place until the certificates expire. ISRG does not provide CRLs for end-entity certificates.

OCSP responses will be made available for all unexpired certificates.

4.10.2 Service availability

All certificate status services are made available at all times (24x7x365) if possible.

4.10.3 Optional features

No stipulation.

4.11 End of subscription

A Subscriber’s subscription ends once all of Subscriber’s ISRG certificates have expired or been revoked.

Prior to expiration of a Subscriber’s certificate, ISRG may send Subscriber a notice regarding upcoming Certificate expiration if a contact email address was provided.

4.12 Key escrow and recovery

4.12.1 Key escrow and recovery policy and practices

Not applicable.

4.12.2 Session key encapsulation and recovery policy and practices

Not applicable.