1. INTRODUCTION

1.1 Overview

This Certification Practice Statement (“CPS”) document outlines the certification services practices for Internet Security Research Group (“ISRG”) Public Key Infrastructure (“ISRG PKI”).

ISRG PKI services include, but are not limited to, issuing, managing, validating, revoking, and renewing Certificates in accordance with the requirements of the ISRG Certificate Policy (CP). It is recommended that readers familiarize themselves with the ISRG CP prior to reading this document.

ISRG PKI services are most commonly, but not necessarily exclusively, provided under the brand/trademark “Let’s Encrypt”.

The ISRG PKI conforms to the current version of the guidelines adopted by the Certification Authority/Browser Forum (“CAB Forum”) when issuing publicly trusted certificates, including the Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates (“Baseline Requirements”). CAB Forum documents can be found at https://www.cabforum.org. If there is any conflict between this CPS and a relevant CAB Forum requirement or guideline, then the CAB Forum requirement or guideline shall take precedence.

Other documents related to the behavior and control of the ISRG PKI, such as a Subscriber Agreement and Privacy Policy, can be found at https://letsencrypt.org/repository/.

Per IETF PKIX RFC 3647, this CPS is divided into nine components that cover security controls, practices, and procedures for certification services provided by the ISRG PKI.

The following Certification Authorities are covered under this CPS:

CA TypeDistinguished NameKey Pair Type and ParametersCert SHA-256 FingerprintValidity Period
Root CAC=US,
O=Internet Security Research Group,
CN=ISRG Root X1
RSA, n has 4096 bits, e=6553796:BC:EC:06:26:49:76:F3:
74:60:77:9A:CF:28:C5:A7:
CF:E8:A3:C0:AA:E1:1A:8F:
FC:EE:05:C0:BD:DF:08:C6
Not Before: Jun 4 11:04:38 2015 GMT,
Not After: Jun 4 11:04:38 2035 GMT
Root CAC=US,
O=Internet Security Research Group,
CN=ISRG Root X2
ECDSA, NIST curve P-38469:72:9b:8e:15:a8:6e:fc:
17:7a:57:af:b7:17:1d:fc:
64:ad:d2:8c:2f:ca:8c:f1:
50:7e:34:45:3c:cb:14:70
Not Before: Sept 4 00:00:00 2020 GMT,
Not After: Sept 17 16:00:00 2040 GMT

This work is licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.

1.2 Document name and identification

This is the ISRG Certification Practices Statement. This document was approved for publication by the ISRG Policy Management Authority, and is made available at https://letsencrypt.org/repository/.

The following revisions have been made:

DateChangesVersion
May 5, 2015Original.1.0
September 9, 2015Added/corrected a number of policy URIs, removed LDAP as mechanism for publishing certificate information, removed administrative contact requirement for DV-SSL subscribers, removed mention of web-based revocation option, removed description of customer service center, substantial changes to all of Section 9 regarding legal matters, other minor fixes/improvements.1.1
September 22, 2015Updated serial number description in Section 10.3.1, DV-SSL Certificate Profiles.1.2
March 16, 2016Update root CRL issuance periods, disallow issuance to ‘.mil’ TLD, make NameConstraints extension optional for cross- certification profile, clarify optional NameConstraints contents, clarify that OSCP ResponderID is byname, clarify that OCSP nonce extension is not supported.1.3
May 5, 2016Reference CP v1.2 rather than CP v1.1. Add info about tlsFeature extension, serialNumber in Subject Distinguished Name field.1.4
October 18, 2016Do not require discontinuing use of a private key due to incorrect information in a certificate. Add information about issuance for Internationalized Domain Names. Add information about CA’s CAA identifying domain. Do not require discontinuing use of a private key due to expiration or revocation of a certificate.1.5
April 13, 2017Complete rewrite of CPS.2.0
February 6, 2018Remove restriction on issuing to ‘.mil’ TLD.2.1
March 10, 2018Remove text stating that wildcard certificates are not supported. Clarify that wildcard validation must use DNS Change method.2.2
May 4, 2018Add CT fields to certificate profiles. Specify current Baseline Requirements compliance for all validations. Update certificate expiration notice text. Remove reference loops. Minor cleanup.2.3
September 20, 2018Define Certificate Problem Reports in Section 1.6.1. Add information about submitting Certificate Problem Reports to Section 1.5.2.2.4
November 14, 2018Remove user notice text from end-entity certificate profile in Section 7.1.2.5
July 3, 2019Minor grammatical and capitalization changes.2.6
January 21, 2020Make structure more exactly match RFC 3647 recommendation. Audit use of phrase No Stipulation and eliminate blank sections. Remove restriction on issuance for IP addresses in Section 7.1.5. Update lists of appropriate and prohibited certificate uses in Sections 1.4.1 and 1.4.2. Clarify annual vulnerability assessment requirements in Section 5.4.8.2.7
May 28, 2020Specify in Section 4.9.3 that revocations for key compromise will result in blocking of the public key for future issuance and revocation of other outstanding certificates with the key. Update description of Certificate Transparency submissions.2.8
July 14, 2020Clarify revocation request instructions in Section 4.9.3.2.9
October 27, 2020List ISRG Root X2 in section 1.1. Update Section 3.2.2 to clarify that ISRG never performs domain validation manually. Update Section 9 to eliminate references to third party RAs, as ISRG does not use or allow them.3.0

1.3 PKI participants

1.3.1 Certification authorities

ISRG is a CA that provides services including, but not limited to, issuing, managing, validating, revoking, and renewing publicly-trusted Certificates. These services are performed in accordance with the requirements of the ISRG Certificate Policy (CP) and this CPS. These services are provided to the general public with exceptions as deemed appropriate by ISRG management or in accordance with relevant law.

ISRG PKI services are most commonly, but not necessarily exclusively, provided under the brand/trademark “Let’s Encrypt”.

1.3.2 Registration authorities

ISRG serves as its own RA. RA services are not performed by third parties.

1.3.3 Subscribers

See definition of “Subscriber” in Section 1.6.1 Definitions.

1.3.4 Relying parties

See definition of “Relying Party” in Section 1.6.1 Definitions.

Relying Parties must verify the validity of certificates via CRL or OCSP prior to relying on certificates. CRL and OCSP location information is provided within certificates.

1.3.5 Other participants

Other participants include CAs that cross-sign or issue subordinates to the ISRG PKI.

ISRG PKI vendors and service providers with access to confidential information or privileged systems are required to operate in compliance with the ISRG CP.

1.4 Certificate usage

1.4.1 Appropriate certificate uses

No stipulation.

1.4.2 Prohibited certificate uses

Certificates may not be used:

  • For any application requiring fail-safe performance such as a) the operation of nuclear power facilities b) air traffic control systems c) aircraft navigation systems d) weapons control systems e) any other system in which failure could lead to injury, death, or environmental damage.
  • For software or hardware architectures that provide facilities for interference with encrypted communications, including but not limited to a) active eavesdropping (e.g., Man-in-the-middle attacks) b) traffic management of domain names or internet protocol (IP) addresses that the organization does not own or control. Note that these restrictions shall apply regardless of whether a relying party communicating through the software or hardware architecture has knowledge of its providing facilities for interference with encrypted communications.

Note that Certificates do not guarantee anything regarding reputation, honesty, or the current state of endpoint security. A Certificate only represents that the information contained in it was verified as reasonably correct when the Certificate was issued.

1.5 Policy administration

1.5.1 Organization administering the document

This CPS document is maintained by the ISRG PMA.

1.5.2 Contact person

The ISRG PMA can be contacted at:

Policy Management Authority
Internet Security Research Group
1 Letterman Drive, Suite D4700
San Francisco, CA 94129

Certificate revocation requests can be made via the ACME API. Please see Section 4.9.3 for more information.

Certificate Problem Reports can be submitted via email to:

cert-prob-reports@letsencrypt.org

1.5.3 Person determining CPS suitability for the policy

The ISRG PMA is responsible for determining the suitability of this CPS. The ISRG PMA is informed by results and recommendations received from an independent auditor.

1.5.4 CPS approval procedures

The ISRG PMA approves any revisions to this CPS document after formal review.

1.6 Definitions and acronyms

1.6.1 Definitions

  • ACME Protocol
    • A protocol used for validation, issuance, and management of certificates. The protocol is an open standard managed by the IETF.
  • Applicant
    • An entity applying for a certificate.
  • Baseline Requirements
    • A document published by the CAB Forum which outlines minimum requirements for publicly trusted Certificate Authorities.
  • CAB Forum
    • Certificate Authority / Browser Forum, a group a CAs and browsers which come together to discuss technical and policy issues related to PKI systems. (https://cabforum.org/)
  • Certificate Problem Report
    • Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates.
  • Certificate Repository
  • Cross Certificate
    • A certificate that is used to establish a trust relationship between two Root CAs.
  • Policy and Legal Repository
  • Key Pair
    • A Private Key and its associated Public Key.
  • Precertificate
    • A certificate containing a critical poison extension as defined by RFC 6962 Section 3.1.
  • Private Key
    • The key in a Key Pair that must be kept secret. Used to create digital signatures that can be verified by the corresponding Public Key or to decrypt messages encrypted by the corresponding Public Key.
  • Public Key
    • The only key in a Key Pair that can safely be publicly disclosed. Used by Relying Parties to verify digital signatures from the corresponding private key or to encrypt messages that can only be decrypted by the corresponding private key.
  • Relying Party
    • An entity that relies upon information contained within certificates issued by ISRG PKI services.
  • Root CA
    • The top-level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates.
  • Secure PKI Facilities
    • Facilities designed to protect sensitive PKI infrastructure, including CA private keys.
  • Subscriber
    • An entity that has agreed to a Subscriber Agreement and is using ISRG PKI services.
  • Trusted Contributor
    • A contributor who performs in a Trusted Role. Trusted Contributors may be employees, contractors, or community members. Trusted Contributors must be properly trained and qualified, and have the proper legal obligations in place before performing in a Trusted Role.
  • Trusted Role
    • A role which qualifies a person to access or modify ISRG PKI systems, infrastructure, and confidential information.

1.6.2 Acronyms

  • ACME
    • Automated Certificate Management Environment
  • CA
    • Certificate Authority
  • CAA
    • Certificate Authority Authorization
  • CP
    • Certificate Policy
  • CPS
    • Certification Practice Statement
  • DV
    • Domain Validation
  • FQDN
    • Fully Qualified Domain Name
  • HSM
    • Hardware Security Module
  • IDN
    • Internationalized Domain Name
  • IP
    • Internet Protocol
  • ISRG
    • Internet Security Research Group
  • PKI
    • Public Key Infrastructure
  • PMA
    • Policy Management Authority
  • RA
    • Registration Authority
  • SAN
    • Subject Alternative Name
  • TLD
    • Top Level Domain

1.6.3 References

No references defined at this time.

1.6.4 Conventions

Terms not otherwise defined in this CPS shall be as defined in applicable agreements, user manuals, Certificate Policies and Certification Practice Statements, of the CA.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in these Requirements shall be interpreted in accordance with RFC 2119.