Last updated: | See all Documentation
ACME (Automatic Certificate Management Environment) : The protocol implemented by Let’s Encrypt. Software compatible with that protocol can use it to communicate with Let’s Encrypt to ask for a certificate. ACME RFC - Wikipedia
Authority Information Access (AIA) : A certificate extension used to indicate to user agents how to obtain information about the issuer of the certificate. It typically specifies the OCSP URI and the issuer URI.
Baseline Requirements (BRs) : A set of technical and policy requirements for CAs. Since all major root programs incorporate the Baseline Requirements, CAs must follow these requirements to be trusted by most browsers.
CA/Browser Forum : A voluntary group of certification authorities, vendors of Internet browser software, operating systems, and other PKI-enabled applications. The CA/Browser Forum publishes the Baseline Requirements. Let’s Encrypt is a member of the CA/Browser Forum. Wikipedia
CAA (Certificate Authority Authorization) : A DNS record that specifies which CAs are allowed to issue certificate for the corresponding domain name. CAA records are checked by CAs, not by browsers. Let’s Encrypt honors CAA records as required by the Baseline Requirements. - Wikipedia
Certificate : A file in a particular format that contains a public key and other data describing when to use that public key. The most common kind of certificate is a leaf certificate. There are also intermediate and root certificates.
Certificate Policy (CP) : A named set of rules that indicates the applicability of a certificate to a particular community and/or class of applications with common security requirements. Specific details of issuance are outlined in a CPS. ISRG Certificate Policy - RFC 3647 - Wikipedia
Certificate Revocation List (CRL) : A method to inform user agents about the revocation status of a certificate. This is a list of the serial numbers of all revoked certificates from a given CA, signed by that CA. Wikipedia
Certificate Signing Request (CSR) : A signed file containing the needed information required by the CA to generated a certificate. Relevant information for Let’s Encrypt are the Common Name, Subject Alternative Names, and Subject Public Key Info. Usually, client applications automatically generate the CSR for the user, although a web hosting provider or device might also generate a CSR. Wikipedia
Certificate Store : A certificate store contains a list of trusted roots. Operating systems (such as Windows, Android or Debian) and web browsers (such as Firefox) maintain a certificate store. Browsers without one rely on the operating systems' certificate store. Certificates provided by Let’s Encrypt are trusted by most certificates stores.
Certificate Transparency (CT) : To improve security, certificates (or precertificates) must be published in Certificate Transparency Logs: https://www.certificate-transparency.org/. Let’s Encrypt generates and publishes precertificates, and includes in the subsequent certificate a list of SCTs for the precertificate. Some browsers, such as Google Chrome, require the presence of this verifiable promise in order to validate the certificate. Wikipedia
Certificate Transparency Log : A component of Certificate Transparency that accepts submissions of certificates and precertificates and incorporates them into a permanent, verifiable, publicly-accessible list.
Certificate chain : A list of intermediate certificates that help a user agent determine that it can trust an end-entity or leaf certificate, by connecting it to a root certificate in its certificate store. Note: the chain is not always unique, and when a website presents a certificate chain leading to one root, the user agent may decide to use another chain to validate the certificate. Wikipedia
Certificate extension : In certificates, most fields are defined by extensions. For instance, Subject Alternative Names and AIA are extensions. The extension mechanism allows creating new fields that were not part of the original X.509 standard.
Certificate issuer : The “Issuer” field of a certificate describes which certificate signed it. For instance, the Issuer field of a Let’s Encrypt end-entity certificate might be “Issuer: C = US, O = Let’s Encrypt, CN = Let’s Encrypt Authority X3”. It commonly contains fields like Common Name, Country, and Organization. The Issuer field always matches some certificate’s Subject field. For self-signed certificates like roots, the Issuer is the same as the Subject. The term “issuer” may also be used to indicate a certificate that issues other certificates (an intermediate or root), or an organization that issues certificates.
Certification Practice Statement (CPS) : A statement of the practices that a certification authority employs in issuing, managing, revoking, and renewing or re-keying certificates. ISRG Certification Practice Statement - RFC 3647 section 3.4 Wikipedia
Common Name (CN) : Part of a certificate’s Subject describing what the certificate is about. For roots and intermediates it’s the human-readable name of the certificate authority. For leaf certificates it’s one of the domain names on the certificate. Note: The common name is limited to 63 characters. It is an obsolete method of indicating a domain name to which the certificate applies, since current Internet standards expect software to check only the Subject Alternative Names in order to determine the applicability of a certificate.
Critical extension : A certificate may contain extensions marked “critical.” This means that software must reject that certificate unless the software understands how to process that extension. This makes it possible to introduce new extensions that are important for security without creating risks for older software.
Cross Signing : An issuing certificate may be signed by more than one root. For example, Let’s Encrypt intermediates are cross signed by IdenTrust, because at launch the Let’s Encrypt root was not yet trusted by certificate stores. Technically, it’s achieved with two issuing certificates, using the same Subject and the same Key-pair, one signed by the private key of a Let’s Encrypt root and the other signed by the private key of an IdenTrust’s root: /certificates. Wikipedia
Domain Name System Security Extensions (DNSSEC) : A mechanism to cryptographically authenticate DNS responses. DNSSEC requires deployment by TLDs, domain name owners, and recursive resolvers in order to take effect. Adoption is currently somewhat low. Wikipedia
Domain-validated certificate : A certificate where the applicant has only proven its control over the domain name (and not the identity of the requesting organization). Let’s Encrypt offers only DV certificates (not OV or EV): FAQ - Wikipedia
ECDSA (Elliptic Curve Digital Signature Algorithm) : A variant of the Digital Signature Algorithm (DSA) which uses elliptic curve cryptography. Wikipedia. Let’s Encrypt supports ECDSA for end-entity or leaf certificates, but not yet for the entire chain: /upcoming-features
EdDSA (Edwards-curve Digital Signature Algorithm) : A modern public-key signature system based on elliptic curves, designed to solve several common implementation issues with elliptic curve cryptography. Certificate Authorities like Let’s Encrypt can’t provide EdDSA certificates yet. Wikipedia
Elliptic Curve Cryptography (ECC) : An type of public-key cryptography based on elliptic curves. ECC uses smaller keys compared to non-EC cryptography while providing equivalent security. Cloudflare - Wikipedia
Extended Validation (EV) : A type of certificate validation for which the CA has verified the legal entity controlling the website. They contain information about that entity. Controls from the CA are more strict than for OV certificates. Let’s Encrypt doesn’t offer EV certificates. Wikipedia
Fully qualified domain name (FQDN)
: The complete domain name of a website. For example,
www.example.com is an FQDN.
HTTP Public Key Pinning (HPKP) : A security mechanism that asks a browser to require that a site’s certificate chain use certain public keys on future loads. Chrome introduced this mechanism to protect against CA compromises, but it caused site outages, leading Chrome to deprecate and remove it. Wikipedia
Intermediate certificate : A certificate signed by a root or another intermediate, and capable of signing other certificates. They are used to sign leaf certificates while keeping the private key of root certificate offline. Intermediates are included in certificate chains. Wikipedia
Internationalized Domain Name (IDN)
: Domain name with characters others than
9 and the hyphen (
-). They can for example contain Arabic, Chinese, Cyrillic, Tamil, Hebrew or Latin alphabet-based characters with diacritics or ligatures. The encoded representation of an IDN domains starts with
xn--. IDNs are supported by Let’s Encrypt: https://letsencrypt.org/2016/10/21/introducing-idn-support.html. Wikipedia - RFC 5890 - RFC 5891
Key-pair : A combination of a private key and public key used to sign or encrypt. The public key is commonly embedded in a certificate, while the private key is stored on its own and should be kept secret. A key pair can be used to encrypt and decrypt, to sign and verify data, or to negotiate secondary keys, depending on the application. Wikipedia
Leaf certificate (end-entity certificate) : Most commonly, a certificate signed by an intermediate, valid for a set of domains and not able to sign other certificates. This is the type of certificate that ACME clients request, and that web servers use. Wikipedia
OCSP (Online Certificate Status Protocol) : A method to check the revocation status of a certificate. In other words, a way to check whether a Certificate Authority indicates that the certificate should no longer be considered valid, even though its expiration date has not yet been reached. This request can create privacy problems because it allows the certificate authority, and Internet service providers, to directly observe who is visiting which sites. Wikipedia
OCSP Must-Staple : A certificate extension, informing the browser that the web server with that certificate must use OCSP stapling. It’s used to require that an up-to-date revocation status of the certificate is confirmed by the web server on every connection, making revocation more reliable. Let’s Encrypt can issue certificates with the OCSP Must-Staple extension upon request. Mozilla Security Blog RFC 7633
OCSP stapling : A way for a web server to send a browser an OCSP response signed by the Certificate Authority, so the browser itself doesn’t need to make a secondary OCSP request to the CA, improving speed and privacy. Also known as TLS Certificate Status Request extension. Wikipedia Cloudflare
Object identifier (OID) : OIDs are unique numeric identifiers standardized by the International Telecommunications Union (ITU) and ISO/IEC. OIDs are used within certificates to define extensions, fields, or policy assertions. Internet standards and Certificate Policy and Certification Practice Statement documents define OID usage. Wikipedia
Organization Validation (OV) : Certificates for which the CA has verified the legal entity of the Subscriber. They contain information about that entity. Let’s Encrypt doesn’t offer OV certificates. Wikipedia
PEM file (.pem) : A format for cryptographic information (originally specified as part of the Privacy Enhanced Mail Internet standards for secure email). A PEM document can represent information such as a private key, a public key, or a digital certificate. These files start with “-----BEGIN " and then a data type. Wikipedia
Personal Information Exchange Files (.pfx) : A file that may contain a leaf certificate, its chain up to the root and the private key of the leaf. See also https://en.wikipedia.org/wiki/PKCS_12. Microsoft Hardware Dev Center
Precertificate : Precertificates are a part of Certificate Transparency. A precertificate is a copy of the certificate that a CA intends to issue, with a critical poison extension added to prevent the precertificate from being accepted by software in the wild. A CA submits a precertificate to CT logs in exchange for SCTs. Since a precertificate is not identical to its corresponding certificate, Certificate Transparency logs may end up containing both. RFC 6962 Section 3.1
Public Suffix List (PSL)
: A list of Public Suffixes maintained by Mozilla, indicating which Internet domains are available for many separate entities to register subdomains. For instance, the list indicates that both
co.uk are Public Suffixes even though
co.uk is not a TLD. Web browsers use the list, among other things, for preventing sites that are likely operated by different entities from sharing web cookies with one another. Let’s Encrypt also uses the list for rate-limit calculations: /rate-limits. https://publicsuffix.org/
Relying Party : The person relying on information in a certificate. For instance, someone who visits an HTTPS web site is a Relying Party.
Revocation : A certificate is valid until its expiration date, unless the CA says it’s been revoked. The certificate may be revoked for various reasons such as the compromise of the private key. Browsers may check if a certificate is revoked using CRL, OCSP, or newer methods like OneCRL and CRLSets. Note that in many situations, revocation doesn’t work. /docs/revoking
Self-signed certificate : A certificate signed by its own private key, with its Subject equal to its Issuer. Self-signed certificates are trusted only due to prior arrangements made in the physical world, such as inclusion on a trusted root list. Root certificates are self-signed. Wikipedia
Server Name Indication (SNI) : A field that a user agent sends to a server during a TLS handshake, specifying the domain name to connect to. This allows the server to answer with the appropriate certificate when multiple domains are hosted behind the same IP. The web server might send a different certificate, and show different content, depending on the name that the client requested by SNI. SNI is not encrypted, but an experimental replacement, ESNI, is. Wikipedia
Signed Certificate Timestamp (SCT) : A signed, verifiable promise to publish a certificate, from a Certificate Transparency log. Browsers that enforce CT check for the presence of SCTs in a site’s certificate, or in the TLS handshake, and refuse to connect to sites that don’t meet their logging requirements. This increases the likelihood that fraudulent or inaccurate certificates will be detected. https://www.certificate-transparency.org/how-ct-works
Staging : Let’s Encrypt provides a staging API to test certificate request without impacting rate limits. Certificates generated by the staging environment are not publicly trusted. The staging environment should be used for testing, debugging, and ACME client development purposes. /docs/staging-environment
Subject Alternative Name (SAN) : A field of a certificate that indicates for which domain(s) the certificate is valid. It replaces the usage of the Common Name, which is now provided for compatibility reasons only. A single certificate may contain many SANs and be valid for many different domain names. Wikipedia https://letsencrypt.org/docs/rate-limits/#names-per-certificate
Subscriber : The person or organization requesting a certificate.
TLS (Transport-Level Security) : The protocol used by HTTPS to encrypt and authenticate web page visits.
Top-Level Domain (TLD)
: Highest level in the hierarchical Domain Name System, such as country-code top-level domains (ccTLDs) like
.cn (China) and generic top-level domains (gTLDs) like
: Certificates valid for subdomains one level deep. For instance, a certificate containing a SAN for
*.example.com is valid for
www.example.com but not for
example.com). A wildcard is indicated by an asterisk character (*) in place of a subdomain. Let’s Encrypt provides Wildcard certificates as of March 2018. Wikipedia