### Example PEM Encoded Certificate

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

An example of a PEM-encoded X.509 certificate, demonstrating the typical 'MII' prefix. This format is derived from DER encoding and then Base64.

```Text
-----BEGIN CERTIFICATE-----

MIIFajCCBFKgAwIBAgISA6HJW9qjaoJoMn8iU8vTuiQ2MA0GCSqGSIb3DQEBCwUA
...
```

--------------------------------

### Example Let's Encrypt Account ID URL Format

Source: https://letsencrypt.org/docs/account-id

This example demonstrates the standard URL format used for Let's Encrypt account IDs. This format is consistent and can be found in client logs or responses.

```Text
https://acme-v02.api.letsencrypt.org/acme/acct/12345678
```

--------------------------------

### Example CAA Record Configurations

Source: https://letsencrypt.org/docs/caa

Presents practical examples of CAA records. The first demonstrates a simple record allowing Let's Encrypt to issue certificates. The second set showcases more advanced configurations, including restricting validation methods (DNS-01), defining separate permissions for wildcard issuance, and enforcing issuance via a specific ACME account URI.

```DNS Configuration
example.org         CAA 0 issue "letsencrypt.org"
```

```DNS Configuration
example.org         CAA 0 issue "myca.org;validationmethods=dns-01"
example.org         CAA 0 issuewild "myca.org"
example.org         CAA 128 issue "otherca.com;accounturi=https://otherca.com/acct/123456"
```

--------------------------------

### ACME Protocol Link Header for Intermediate Certificates

Source: https://letsencrypt.org/docs/integration-guide

Describes the 'Link: rel="up"' header used in the ACME protocol to dynamically determine the correct intermediate certificate, advising against hardcoding the intermediate certificate.

```APIDOC
Link: rel="up" (RFC 8555, Section 7.4.2)
```

--------------------------------

### Integer Binary Encoding Examples in BER/DER

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

Illustrates how various decimal integer values are represented in binary according to BER/DER two's complement encoding, including positive, negative, multi-byte values, and examples related to the shortest form rule.

```Binary
00110010 (== decimal 50)
```

```Binary
10011100 (== decimal -100)
```

```Binary
10000000 00000000 00000000 00000000 00000001 (== decimal -549755813887)
```

```Binary
00000000 11111111
```

```Binary
10000000 (== decimal -128)
```

```Binary
11111111 10000000 (== decimal -128, but an invalid encoding)
```

--------------------------------

### Fully Qualified Domain Name (FQDN)

Source: https://letsencrypt.org/docs/glossary

The complete domain name of a website, including all labels up to the top-level domain. For example, `www.example.com` is an FQDN.

```APIDOC
FQDN:
  Full Name: Fully qualified domain name
  Description: The complete domain name of a website. For example, `www.example.com` is an FQDN.
```

--------------------------------

### ACME Protocol Link Header for Terms of Service

Source: https://letsencrypt.org/docs/integration-guide

Describes the 'Link: rel="terms-of-service"' header used in the ACME protocol to dynamically determine the current Terms of Service URL, advising against hardcoding the ToS URL.

```APIDOC
Link: rel="terms-of-service" (RFC 8555, Section 7.3.3)
```

--------------------------------

### ASN.1 IMPLICIT Tagging Example and Hexadecimal Encoding

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

Demonstrates an ASN.1 encoding instruction using IMPLICIT tagging for a UTF8String, showing how it is defined and its compact hexadecimal byte representation for the string 'hi'. IMPLICIT encoding uses fewer bytes.

```ASN.1
[5] IMPLICIT UTF8String
```

```Hexadecimal
85 02 68 69
```

--------------------------------

### BER Encoded Integer Example (Hexadecimal)

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

Demonstrates a concrete example of an INTEGER value encoded using Basic Encoding Rules (BER) in hexadecimal. The sequence '02 03 01 00 01' breaks down into a type tag for INTEGER, a length of 3 bytes, and the actual integer value.

```APIDOC
Hexadecimal Sequence: 02 03 01 00 01
  - Interpretation:
    - Tag: 02 (Corresponds to INTEGER type)
    - Length: 03 (Indicates the value is 3 bytes long)
    - Value: 01 00 01 (The actual three-byte integer value)
```

--------------------------------

### BER Encoding Examples for Various String Types

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

Illustrates the BER encoding for different string types: PrintableString, IA5String, and UTF8String, highlighting how their encodings differ primarily by tag and character set support.

```Hexadecimal
13 02 68 69
```

```Hexadecimal
16 02 68 69
```

```Hexadecimal
0c 04 f0 9f 98 8e
```

--------------------------------

### ASN.1 EXPLICIT Tagging Example and Hexadecimal Encoding

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

Illustrates an ASN.1 encoding instruction using EXPLICIT tagging for a UTF8String, detailing its definition and the more verbose hexadecimal byte representation for the string 'hi', highlighting the additional wrapping. EXPLICIT encoding uses more bytes.

```ASN.1
[5] EXPLICIT UTF8String
```

```Hexadecimal
A5 04 0C 02 68 69
```

--------------------------------

### GeneralName Encoding Example: dNSName

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

Presents the hexadecimal encoding for a GeneralName object containing the dNSName 'example.com'. The encoding uses tag number 2 (82), indicating a context-specific, implicitly tagged IA5String, followed by its length (0b) and the ASCII bytes of the domain name.

```Hex
82 0b 65 78 61 6d 70 6c 65 2e 63 6f 6d
```

--------------------------------

### BER and DER Encoding Examples for UTCTime

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

Shows the encoding of a specific date and time (December 15, 2019, 19:02:10 PST) in both BER and DER for UTCTime, emphasizing DER's stricter requirements for UTC and 'Z' form.

```Hexadecimal
17 11 31 39 31 32 31 35 31 39 30 32 31 30 2d 30 38 30 30
```

```Hexadecimal
17 0d 31 39 31 32 31 36 30 33 30 32 31 30 5a
```

--------------------------------

### Encoding a SEQUENCE OF INTEGER (7, 8, 9) in BER/DER

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

Demonstrates the BER/DER encoding of a SEQUENCE OF INTEGER containing the values 7, 8, and 9. This example highlights that SEQUENCE OF uses the same tag and encoding structure as a regular SEQUENCE.

```Hexadecimal
30 09 02 01 07 02 01 08 02 01 09
```

--------------------------------

### Revoke Let's Encrypt Certificate using Certbot and Private Key

Source: https://letsencrypt.org/docs/revoking

This command revokes a Let's Encrypt certificate using Certbot. It requires the path to the certificate file (`--cert-path`) and the corresponding private key file (`--key-path`). The `--reason` flag specifies the reason for revocation, in this case, `keyCompromise`, indicating that the private key has been compromised.

```shell
certbot revoke --cert-path /PATH/TO/cert.pem --key-path /PATH/TO/privkey.pem --reason keyCompromise
```

--------------------------------

### ASN.1 OBJECT IDENTIFIER (OID) Definition

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

Illustrates the definition of an ASN.1 OBJECT IDENTIFIER (OID), assigning a meaningful name to a specific OID value. The example defines id-pkix with its hierarchical numerical components.

```ASN.1
id-pkix  OBJECT IDENTIFIER  ::=
         { iso(1) identified-organization(3) dod(6) internet(1)
                    security(5) mechanisms(5) pkix(7) }
```

--------------------------------

### Revoke Let's Encrypt Certificate with Issuing Account (Certbot)

Source: https://letsencrypt.org/docs/revoking

This command revokes a Let's Encrypt certificate using the Certbot client, assuming control of the original account that issued the certificate. It requires the path to the certificate file.

```Bash
certbot revoke --cert-path /etc/letsencrypt/archive/${YOUR_DOMAIN}/cert1.pem
```

--------------------------------

### Let's Encrypt Certificate Revocation Reason Codes

Source: https://letsencrypt.org/docs/revoking

Defines the valid reason codes that Let's Encrypt subscribers should select when revoking a certificate, along with their specific use cases and implications for the revocation process.

```APIDOC
Revocation Reason Codes:
- unspecified (RFC 5280 CRLReason #0):
  Description: Default reason when others do not apply.
  Usage: Must be used if no other specific reason is applicable.
- keyCompromise (RFC 5280 CRLReason #1):
  Description: Private key of the certificate is believed to be compromised.
  Usage: Choose when an unauthorized person has had access to the private key.
  Note: Let's Encrypt may ignore the requested reason and set to 'keyCompromise' if the request is signed using the Certificate private key.
- superseded (RFC 5280 CRLReason #4):
  Description: A new certificate is requested to replace an existing one.
  Usage: Choose when replacing an active certificate.
- cessationOfOperation (RFC 5280 CRLReason #5):
  Description: No longer own all domain names in the certificate or discontinuing website.
  Usage: Choose when domains are no longer owned or website is discontinued.
  Note: Let's Encrypt may ignore the requested reason and set to 'cessationOfOperation' if the request is from a different authorized account demonstrating control over all identifiers.
```

--------------------------------

### ASN.1 TBSCertificate Definition with Tagging Examples

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

Defines the structure of a TBSCertificate using ASN.1, illustrating the application of explicit and implicit tagging for various fields, including optional unique identifiers and extensions, as per RFC 5280. This snippet shows how tags like [0], [1] IMPLICIT, and [2] IMPLICIT are used.

```ASN.1
TBSCertificate  ::=  SEQUENCE  {
     version         [0]  Version DEFAULT v1,
     serialNumber         CertificateSerialNumber,
     signature            AlgorithmIdentifier,
     issuer               Name,
     validity             Validity,
     subject              Name,
     subjectPublicKeyInfo SubjectPublicKeyInfo,
     issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version MUST be v2 or v3
     subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version MUST be v2 or v3
     extensions      [3]  Extensions OPTIONAL
                          -- If present, version MUST be v3 --  }
```

--------------------------------

### Encoding AlgorithmIdentifier with sha256WithRSAEncryption and NULL parameters

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

Illustrates the BER/DER encoding of an AlgorithmIdentifier. This specific example encodes the OID for sha256WithRSAEncryption (1.2.840.113549.1.1.11) with its parameters field set to NULL, as required by RFC 8017 for this algorithm.

```Hexadecimal
30 0d 06 09 2a 86 48 86 f7 0d 01 01 0b 05 00
```

--------------------------------

### ASN.1 CHOICE Type Definition for Time

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

Illustrates the ASN.1 CHOICE type, which allows a field to contain exactly one of several specified types. The example defines a Time type that can be either UTCTime or GeneralizedTime.

```ASN.1
Time ::= CHOICE {
     utcTime        UTCTime,
     generalTime    GeneralizedTime }
```

--------------------------------

### Encoding an OID (1.2.840.113549.1.1.11) in BER/DER

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

Demonstrates the BER/DER encoding of the Object Identifier (OID) 1.2.840.113549.1.1.11, which represents sha256WithRSAEncryption. This example illustrates the base-128 encoding and the special handling of the first two components (40*X+Y).

```Hexadecimal
06 09 2a 86 48 86 f7 0d 01 01 0b
```

--------------------------------

### GeneralName Encoding Example: rfc822Name

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

Provides the hexadecimal encoding for a GeneralName object containing the rfc822Name 'a@example.com'. The encoding uses tag number 1 (81), indicating a context-specific, implicitly tagged IA5String, followed by its length (0d) and the ASCII bytes of the email address.

```Hex
81 0d 61 40 65 78 61 6d 70 6c 65 2e 63 6f 6d
```

--------------------------------

### Let's Encrypt Rate Limit: Consecutive Authorization Failures per Hostname per Account

Source: https://letsencrypt.org/docs/rate-limits

Explains a specific rate limit that applies to consecutive authorization failures per hostname per account, designed to prevent clients from getting stuck in validation loops.

```APIDOC
Description: Similar to 'Authorization Failures per Hostname per Account' but applies only to consecutive failures.
Purpose: Designed to prevent clients from getting stuck indefinitely in a loop of failed validations.
```

--------------------------------

### Sapling Certificate Transparency Log Endpoints

Source: https://letsencrypt.org/docs/ct-logs

Details for various instances of the Sapling Certificate Transparency log, including their names, URIs, public keys, log IDs, and the start and end dates of their operational windows. These logs are used for testing purposes by Let's Encrypt and other certificate authorities.

```APIDOC
Sapling CT Log Details:
  - Name: Sapling 2022h2
    URI: https://sapling.ct.letsencrypt.org/2022h2
    Public Key: MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE6m0gtMM2pcVTxVjkztm/ByNrF32xacdVnbsYwlzwtqN0vOwqcXLtPkfYqH+q93hlJwEBsX1MnRXDdlMHkkmZJg==
    Log ID: 23:2D:41:A4:CD:AC:87:CE:D9:F9:43:F4:68:C2:82:09:5A:E0:9D:30:D6:2E:2F:A6:5D:DC:3B:91:9C:2E:46:8F
    Window Start: 2022-06-15T00:00Z
    Window End: 2023-01-15T00:00Z
  - Name: Sapling 2023h1
    URI: https://sapling.ct.letsencrypt.org/2023h1
    Public Key: MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE09jAcGbw5CDCK2Kg0kkmmDydfDfZAA8K64BufU37yx3Jcy/ePy1EjAi2wUPVJ0xsaNMCU37mh+fBV3+K/cSG8A==
    Log ID: C1:83:24:0B:F1:A4:50:C7:6F:BB:00:72:69:DC:AC:3B:E2:2A:48:05:D4:db:E0:49:66:C3:C8:ab:C4:47:B0:0C
    Window Start: 2022-12-15T00:00Z
    Window End: 2023-07-15T00:00Z
  - Name: Sapling 2023h2
    URI: https://sapling.ct.letsencrypt.org/2023h2
    Public Key: MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEbdCykRsTPRgfjKVQvINRLJk3gy+2qNKOU48bo/sWO0ko75S92C+PBDxsqMEd0YpCYYLogCt2LAK/U4H7UwHsjA==
    Log ID: ED:AB:9D:1D:DD:83:73:95:9F:F5:2A:88:E4:6B:B4:BC:C3:C4:CC:4D:76:8A:60:CC:FF:4E:36:2D:7F:B8:D6:68
    Window Start: 2023-06-15T00:00Z
    Window End: 2024-01-15T00:00Z
  - Name: Sapling 2024h1
    URI: https://sapling.ct.letsencrypt.org/2024h1
    Public Key: MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE1Yn4OKJQuwEwo1/BeVBh1NYkQBnS8sYmMfQr/VdXOGqPcbwcpw0TtjJBYmn8FA+ZT7hnt7OfF4RTjLNW3bWOkw==
    Log ID: AA:6C:B0:C5:C9:F4:C4:9D:8D:8E:A9:0C:39:17:E0:D7:0A:D9:22:10:BF:05:7F:41:50:93:82:CC:35:0C:98:46
    Window Start: 2023-12-15T00:00Z
    Window End: 2024-07-15T00:00Z
  - Name: Sapling 2024h2
    URI: https://sapling.ct.letsencrypt.org/2024h2
    Public Key: MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWipy8ZdRGs2Y5tBb8h8c4UUREnT/YMbm+FEUQBBScf85txhGRHNN/sNN0L/KDiGu/GsrOBCkDruDfHkD42eZXQ==
    Log ID: 85:1B:AE:8E:EE:33:C1:B9:87:3F:C4:9C:7A:7C:27:65:66:3B:6B:80:63:03:04:0A:EC:A6:C1:11:A5:AB:E9:D7
    Window Start: 2024-06-15T00:00Z
    Window End: 2025-01-15T00:00Z
  - Name: Sapling 2025h1
    URI: https://sapling.ct.letsencrypt.org/2025h1
    Public Key: MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0orejUR5RSyoqJ0Hyu2gAwO6d9OPGtKgqQwdBMNGkKY1Bms1vzrHaUD5LDEvjB7Ug/ThaXz9eQH03w3jFii0uw==
    Log ID: 21:E5:1A:44:D8:B9:E7:54:0E:A7:FB:E0:BA:D7:77:36:15:60:66:84:D1:5A:EB:33:E6:45:B4:E9:55:F3:88:83
    Window Start: 2024-12-15T00:00Z
    Window End: 2025-07-15T00:00Z
```

--------------------------------

### OCTET STRING Encoding Example

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

Illustrates the hexadecimal encoding of an OCTET STRING containing the bytes 03, 02, 06, and A0. The first byte (04) signifies an OCTET STRING tag, followed by the length (04) and then the actual bytes.

```Hex
04 04 03 02 06 A0
```

--------------------------------

### Extract SPKI Hash from Private Key using OpenSSL

Source: https://letsencrypt.org/docs/revoking

This command extracts the SubjectPublicKeyInfo (SPKI) hash from a private key file. It takes the private key in PEM format as input and outputs its DER-encoded public key, which is then piped to `openssl sha256` to compute the hash. This hash can be used to find all certificates associated with the private key in Certificate Transparency logs.

```shell
openssl pkey -outform DER -in /PATH/TO/privkey.pem -pubout | openssl sha256
```

--------------------------------

### Validate Domain Control for Revocation without Issuance (Certbot)

Source: https://letsencrypt.org/docs/revoking

This Certbot command initiates a manual challenge to validate domain control, typically used when revoking a certificate issued by a compromised account. By including a non-existent domain, it prevents actual certificate issuance while still performing validation for existing domains. Users must follow instructions and skip validation for the non-existent domain.

```Bash
certbot certonly --manual --preferred-challenges=dns -d ${YOUR_DOMAIN} -d nonexistent.${YOUR_DOMAIN}
```

--------------------------------

### Revoke Downloaded Let's Encrypt Certificate (Certbot)

Source: https://letsencrypt.org/docs/revoking

After validating domain control and downloading a certificate (e.g., from crt.sh), this Certbot command revokes the specified certificate. This method is used when the original issuing account is not available but domain control has been re-established and validated.

```Bash
certbot revoke --cert-path /PATH/TO/downloaded-cert.pem
```

--------------------------------

### ASN.1 GeneralName CHOICE Definition (RFC 5280)

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

Defines the ASN.1 structure for 'GeneralName' as a CHOICE type, allowing it to hold various other types. This example from RFC 5280 shows how context-specific tags ([0] through [8]) are used to distinguish between different choices, even when underlying types (like IA5String for rfc822Name and dNSName) are the same.

```APIDOC
GeneralName ::= CHOICE {
     otherName                       [0]     OtherName,
     rfc822Name                      [1]     IA5String,
     dNSName                         [2]     IA5String,
     x400Address                     [3]     ORAddress,
     directoryName                   [4]     Name,
     ediPartyName                    [5]     EDIPartyName,
     uniformResourceIdentifier       [6]     IA5String,
     iPAddress                       [7]     OCTET STRING,
     registeredID                    [8]     OBJECT IDENTIFIER }
```

--------------------------------

### Sunlight CT Log Specifications

Source: https://letsencrypt.org/docs/ct-logs

This section provides the structured details for Let's Encrypt's experimental Certificate Transparency (CT) logs, including Twig, Sycamore, and Willow. Each log entry specifies its name, URI, public key, unique log ID, and the start and end dates of its operational window. These logs are for testing purposes, and SCTs generated from them should not be used in publicly trusted certificates.

```APIDOC
CT Log Entry Structure:
  Name: string (e.g., "Twig 2025h1b")
  URI: string (URL of the log)
  Public Key: string (Base64 encoded public key)
  Log ID: string (Base64 encoded log identifier)
  Window Start: string (ISO 8601 datetime, e.g., "2024-12-17T00:00Z")
  Window End: string (ISO 8601 datetime, e.g., "2025-06-17T00:00Z")

Example Log Entries:
  Twig 2025h1b:
    URI: https://twig.ct.letsencrypt.org/2025h1b
    Public Key: MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE/d6uF9Yw5/3Lo4nJIdWqY0D9H/v/J/WHWqgl8gmTa6AKiBo5CFddHwlU3wj+pgaQm2OhzV2MnXZCOpbLxyk8LA==
    Log ID: lZC9hfLPxQZJmKurW7JsLnoXZwKRHBO2i0gF4euUJ+8=
    Window Start: 2024-12-17T00:00Z
    Window End: 2025-06-17T00:00Z
  Twig 2025h2b:
    URI: https://twig.ct.letsencrypt.org/2025h2b
    Public Key: MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE1WZDmBaw9OoQTk8Yf/IvYkXPw6R6A+uBwHf1L4OrI4gsf/g5s9qtFEF6/NhG3R0+nxfha3apbUjdtNWln9yvkg==
    Log ID: wF0gVDhcss+yF5INLw3Hg1JhR7GqT++Xynjh8LuE/O0=
    Window Start: 2025-06-17T00:00Z
    Window End: 2025-12-16T00:00Z
  Sycamore 2025h1b:
    URI: https://sycamore.ct.letsencrypt.org/2025h1b
    Public Key: MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAELnRI9kk9Ahd4T2qNIrqLPvf5lO44NBYwD9lwoV9MqerizPLRDEjzLw2GXa7MonZEXhcMABNHgViY6kb1LeBDJg==
    Log ID: TgJ3oMtvarf2feceaghbLRgMKXeCS/tMK72dLNQR874=
    Window Start: 2024-12-18T00:00Z
    Window End: 2025-06-18T00:00Z
  Sycamore 2025h2b:
    URI: https://sycamore.ct.letsencrypt.org/2025h2b
    Public Key: MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEocuurm/JTMcynwKIeUHntdBm8OuLHcK6HgWD5wkE6JCcsPx1i1jAnULV8TSrzdzb8YSIx+VgFp+/YmqGUMHE5w==
    Log ID: 94/yCGmtl2pDc7SsqLOyAxSOFO3mi+FBU1uhNot7qAY=
    Window Start: 2025-06-18T00:00Z
    Window End: 2025-12-17T00:00Z
  Willow 2025h1b:
    URI: https://willow.ct.letsencrypt.org/2025h1b
    Public Key: MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEbNmWXyYsF2pohGOAiNELea6UL4/XioI3w6ChE5Udlos0HUqM7KOHIP9qBuWCVs6VAdtDXrvanmxKq52Whh2+2w==
    Log ID: IX7IijpQPODOtMQx74xNVMHVjB9SuiP0KekrE2jAgWE=
    Window Start: 2024-12-19T00:00Z
    Window End: 2025-06-19T00:00Z
  Willow 2025h2c:
    URI: https://willow.ct.letsencrypt.org/2025h2c
    Public Key: MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEaUvzqBm/C9pNUsVI1jqpms5OkW3Kk+Eb3/veW6P3ogOItkqqEvkZfU7zBbsvm1j1Ep003iNUGFOrilPl5TpCRg==
    Log ID: kqECxXwi2rGMzCrnH9TMWcBdJR2hbHPiKBvT8LBImIc=
    Window Start: 2025-06-19T00:00Z
    Window End: 2025-12-18T00:00Z
```

--------------------------------

### BER/DER BIT STRING Encoding Example

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

Demonstrates the encoding of an 18-bit string (011011100101110111) into its hexadecimal representation. The first byte indicates the number of unused bits (03 for 3 bytes total, 6 unused bits), followed by the encoded data. It notes that unused bits must be zero in DER but can be any value in BER.

```Hex
03 04 06 6e 5d c0
```

--------------------------------

### Demonstrate PEM 'MII' Prefix from DER Bytes

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

A shell command using `xxd` and `base64` to demonstrate how the DER bytes 0x30 0x82 0x00 (representing SEQUENCE, long length, and a small length value) are encoded into 'MII' via Base64, proving the explanation.

```Shell
xxd -r -p <<<308200 | base64
```

--------------------------------

### Let's Encrypt Common Causes of Validation Failures

Source: https://letsencrypt.org/docs/rate-limits

Explains typical reasons for validation failures with HTTP-01, TLS-ALPN-01, and DNS-01 methods, recommending the staging environment for troubleshooting.

```APIDOC
Troubleshooting Recommendations:
  - Use staging environment for testing to avoid consuming production limits.

Common Causes of Validation Failures:
  - HTTP-01 & TLS-ALPN-01: Network or firewall configurations preventing validation servers from reaching your server.
  - DNS-01: Missed steps or typos during initial setup, typically related to creating CNAME records for client-managed DNS.
```

--------------------------------

### Let's Encrypt Account Registration Limits Overview

Source: https://letsencrypt.org/docs/rate-limits

Details the rate limits applied when subscribers request new accounts via the new-account API endpoint, emphasizing that exceeding these limits is rare and recommending single accounts for large integrators.

```APIDOC
Applies to: new-account API endpoint
Recommendation: Large integrators should use one account for many customers.
```

--------------------------------

### Basic CAA Record Syntax

Source: https://letsencrypt.org/docs/caa

Illustrates the fundamental structure of a CAA record, comprising flags, a tag, and a value. Flags define record behavior, the tag specifies the type of authorization (e.g., `issue`, `issuewild`), and the value contains the CA identifier along with optional parameters.

```DNS Configuration
CAA <flags> <tag> <value>
```

--------------------------------

### Let's Encrypt Rate Limit: New Certificates per Exact Set of Hostnames

Source: https://letsencrypt.org/docs/rate-limits

Describes the rate limit for issuing certificates for an exact set of hostnames, including the maximum certificates allowed and the refill rate. It also highlights common causes for hitting this limit, recommends using the staging environment for testing, and suggests workarounds. Overrides are not offered for this limit.

```APIDOC
Exact Set of Hostnames Definition: A specific list of hostnames requested for a certificate (e.g., '[example.com, login.example.com]' for 'example.com' and 'login.example.com').
Limit: Up to 5 certificates can be issued per exact same set of hostnames every 7 days. This is a global limit. The ability to request new certificates for the same exact set of hostnames refills at a rate of 1 certificate every 34 hours.
Common Causes: Reinstalling your client multiple times for troubleshooting, or deleting ACME client’s configuration data upon application deployment.
Recommendation: Use the staging environment for testing or troubleshooting, as it has significantly higher limits.
Workaround: If the limit is hit, change the set of hostnames (e.g., by adding 'blog.example.com') to request additional certificates. Note that these new orders are not considered renewals and are subject to 'New Orders per Account' and 'New Certificates per Registered Domain' limits.
Overrides: Not offered for this limit.
```

--------------------------------

### New Certificate Orders per Account Limit

Source: https://letsencrypt.org/docs/rate-limits

Explains that each certificate request creates a new order, with a single certificate supporting up to 100 hostnames. Recommends using fewer hostnames per certificate for performance reasons.

```APIDOC
Order Creation: Each certificate request creates a new order.
Hostnames per Certificate: Up to 100 hostnames per single certificate.
Performance Note: Fewer hostnames per certificate is better for performance.
```

--------------------------------

### Staging Root CA: Pretend Pear X1 Details

Source: https://letsencrypt.org/docs/staging-environment

Details for the '(STAGING) Pretend Pear X1' root certificate used in the Let's Encrypt staging environment. This certificate is not present in standard browser/client trust stores and is intended for testing purposes only. It specifies the certificate's subject and key type.

```APIDOC
Root CA: Pretend Pear X1
  Subject: O = (STAGING) Internet Security Research Group, CN = (STAGING) Pretend Pear X1
  Key type: RSA 4096
```

--------------------------------

### Let's Encrypt Rate Limit: New Certificates per Registered Domain

Source: https://letsencrypt.org/docs/rate-limits

Explains the global rate limit for issuing new certificates per registered domain, defining what constitutes a registered domain and the maximum certificates allowed within a period. It also covers the refill rate and the process for requesting an override.

```APIDOC
Registered Domain Definition: Generally, the part of the domain purchased from your domain name registrar (e.g., 'example.com' from 'www.example.com', 'example.co.uk' from 'new.blog.example.co.uk'). Identified using the Public Suffix List.
Limit: Up to 50 certificates can be issued per registered domain every 7 days. This is a global limit. The ability to issue new certificates for the same registered domain refills at a rate of 1 certificate every 202 minutes.
Overrides: To exceed this limit, you must request an override for the specific registered domain or an account via the provided form.
```

--------------------------------

### ASN.1 ANY Type Definition for AttributeValue

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

Demonstrates the ASN.1 ANY type, indicating that a value can be of any type, often constrained by external definitions. This example shows AttributeValue defined as ANY, with its specific type determined by AttributeType. Note that ANY is a deprecated feature from ASN.1 1988.

```ASN.1
   AttributeTypeAndValue ::= SEQUENCE {
     type     AttributeType,
     value    AttributeValue }

   AttributeType ::= OBJECT IDENTIFIER

   AttributeValue ::= ANY -- DEFINED BY AttributeType
```

--------------------------------

### New Account Registrations per IP Address Limit

Source: https://letsencrypt.org/docs/rate-limits

Specifies the limit of 10 new accounts per IP address every 3 hours, with a refill rate of 1 account every 18 minutes. Notes that overrides are not offered for this specific limit.

```APIDOC
Limit: 10 accounts per IP address every 3 hours
Refill Rate: 1 account every 18 minutes
Overrides: Not offered
```

--------------------------------

### ACME HTTP-01 Challenge File Placement and Protocol

Source: https://letsencrypt.org/docs/challenge-types

Describes the required file path and content for the ACME HTTP-01 challenge, where the ACME client places a file containing a token and account key thumbprint for validation by Let's Encrypt servers. This challenge operates on port 80 and supports redirects under specific conditions.

```APIDOC
HTTP-01 Challenge File Structure:
  Path: http://<YOUR_DOMAIN>/.well-known/acme-challenge/<TOKEN>
  Content: <TOKEN>.<ACCOUNT_KEY_THUMBPRINT>

Validation Details:
  - Protocol: HTTP
  - Port: 80 (mandatory)
  - Redirects: Supported (up to 10 deep) to http:/https: on ports 80/443. No IP address redirects.
  - HTTPS Redirects: Certificate validation is skipped.
```

--------------------------------

### Root Program Definition

Source: https://letsencrypt.org/docs/glossary

Defines a Root Program as an organization's policies for deciding which certificates to include in its certificate store, thereby determining which CAs are trusted by its software.

```APIDOC
Root Program:
  Description: The policies an organization uses to decide which certificates to include in its certificate store, and thereforce which CAs are trusted by their software.
```

--------------------------------

### New Account Registrations per IPv6 Range Limit

Source: https://letsencrypt.org/docs/rate-limits

Specifies the limit of 500 new accounts per /48 IPv6 subnet every 3 hours, with a refill rate of 1 account every 22 seconds. Notes that overrides are not offered for this specific limit.

```APIDOC
Limit: 500 accounts per /48 IPv6 subnet every 3 hours
Refill Rate: 1 account every 22 seconds
Overrides: Not offered
```

--------------------------------

### Let's Encrypt Rate Limit: New Orders per Account

Source: https://letsencrypt.org/docs/rate-limits

Details the rate limit for new certificate orders per account, including the maximum number of orders allowed within a specific timeframe and the refill rate. It also provides information on how to request an override for this limit.

```APIDOC
Limit: Up to 300 new orders can be created by a single account every 3 hours. The ability to create new orders refills at a rate of 1 order every 36 seconds.
Overrides: To exceed this limit, you must request an override for a specific account via the provided form.
```

--------------------------------

### PEM File Format Definition

Source: https://letsencrypt.org/docs/glossary

Describes the PEM file format, originally for Privacy Enhanced Mail, used for cryptographic information like private keys, public keys, or digital certificates. Identifies the characteristic "-----BEGIN " header.

```APIDOC
PEM file (.pem):
  Description: 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.
```

--------------------------------

### Let's Encrypt Certificate Issuance Limits Overview

Source: https://letsencrypt.org/docs/rate-limits

Describes the rate limits applied when subscribers request new certificates using the new-order API endpoint, noting that these limits are more commonly hit by large hosting providers or organizations.

```APIDOC
Applies to: new-order API endpoint
Commonly hit by: Large hosting providers or organizations issuing many certificates.
```

--------------------------------

### Let's Encrypt Rate Limit: Authorization Failures per Hostname per Account

Source: https://letsencrypt.org/docs/rate-limits

Details the rate limit for authorization failures per hostname per account, explaining what constitutes a failed authorization and the consequences of exceeding the limit. It also provides common causes for validation failures and recommends using the staging environment for troubleshooting. Overrides are not offered for this limit.

```APIDOC
Authorization Definition: An authorization is generated for each hostname in an order. All authorizations must be successfully validated for a certificate to be issued. A failed authorization means Let’s Encrypt’s attempts to validate control of the hostname have failed.
Limit: Up to 5 authorization failures per hostname can be incurred by one account every hour. The ability to incur authorization failures refills at a rate of 1 per hostname every 12 minutes. Once exceeded, this limit prevents any new orders for the same hostname by the same account until it resets.
Recommendation: Before troubleshooting, set your client to use the staging environment, which has significantly higher limits.
Common Causes:
  - HTTP-01 and TLS-ALPN-01 methods: Usually stem from network or firewall configurations preventing Let’s Encrypt validation servers from reaching your server.
  - DNS-01 method: Often results from missed steps or typos during initial setup, typically requiring CNAME record creation in your main DNS zone.
Overrides: Not offered for this limit.
```

--------------------------------

### PFX File Format Definition

Source: https://letsencrypt.org/docs/glossary

Defines the PFX file format, which can contain a leaf certificate, its chain up to the root, and the private key of the leaf certificate.

```APIDOC
Personal Information Exchange Files (.pfx):
  Description: A file that may contain a leaf certificate, its chain up to the root and the private key of the leaf.
```

--------------------------------

### Define a Point Data Structure Across Languages

Source: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der

Compares the definition of a simple 'point' data structure across C, Go, and ASN.1, illustrating how ASN.1 provides a language-independent definition for data formats like those used in HTTPS certificates. This demonstrates ASN.1's role in defining structures that can be implemented or generated in various programming languages.

```C
struct point {
  int x, y;
  char label[10];
};
```

```Go
type point struct {
  x, y int
  label string
}
```

```ASN.1
Point ::= SEQUENCE {
  x INTEGER,
  y INTEGER,
  label UTF8String
}
```

--------------------------------

### Staging Root CA: Bogus Broccoli X2 Details

Source: https://letsencrypt.org/docs/staging-environment

Details for the '(STAGING) Bogus Broccoli X2' root certificate used in the Let's Encrypt staging environment. Like other staging roots, it is not in standard trust stores and is for testing only. This entry includes its subject, key type, and notes its cross-signing by Pretend Pear X1.

```APIDOC
Root CA: Bogus Broccoli X2
  Subject: O = (STAGING) Internet Security Research Group, CN = (STAGING) Bogus Broccoli X2
  Key type: ECDSA P-384
```

--------------------------------

### Cross-signing of Issuing Certificates

Source: https://letsencrypt.org/docs/glossary

Explains how an issuing certificate can be signed by multiple roots, exemplified by Let's Encrypt intermediates being cross-signed by IdenTrust to establish trust before the Let's Encrypt root was widely trusted. This process involves two issuing certificates with the same Subject and Key-pair, each signed by a different root's private key.

```APIDOC
Cross-signing:
  Description: 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. See also: /certificates/.
```

--------------------------------

### Let's Encrypt ACME v2 Staging Environment URL

Source: https://letsencrypt.org/docs/staging-environment

The base URL for interacting with the Let's Encrypt ACME v2 staging environment, used for testing certificate issuance and renewal processes without affecting production rate limits.

```Text
https://acme-staging-v02.api.letsencrypt.org/directory
```

--------------------------------

### Certbot Staging Environment Flags

Source: https://letsencrypt.org/docs/staging-environment

Flags used with Certbot to direct certificate requests to the Let's Encrypt staging environment, enabling testing without consuming production rate limits or issuing trusted certificates.

```CLI
--test-cert
--dry-run
```

--------------------------------

### Let's Encrypt Classic Certificate Profile Properties

Source: https://letsencrypt.org/docs/profiles

The classic profile is the default for all orders not requesting a specific profile, maintaining the validation process and certificate properties from previous years. It is recommended for subscribers who prefer a stable, established approach. This snippet details the specific properties and their values for the classic profile, including footnotes for clarity.

```APIDOC
Pending Authorization Lifetime: 7 days
Authorization Reuse Period: 30 days
Order Lifetime: 7 days
Certificate Common Name: Yes*
Key Encipherment KU: Yes†
TLS Client Auth EKU: Yes‡
Subject Key ID: Yes
Validity Period: 90 days
Revocation Information: CRL
Max Names: 100
Identifier Types: DNS

*: If the CSR submitted at finalize time requests a specific Common Name that corresponds to a dNSName Subject Alternative Name, that request is honored. If the the CSR does not request a specific Common Name, the first dNSName Subject Alternative Name requested will be promoted into the Subject Common Name. If either the requested name or the to-be-promoted name is too long to fit in the Common Name field (64+ characters), the Common Name will be left empty.
†: Only included for certificates with RSA public keys.
‡: Until February 11, 2026. See deprecation timeline information for a full timeline.
```

--------------------------------

### Let's Encrypt Authorization Failure Limits

Source: https://letsencrypt.org/docs/rate-limits

Details the maximum number of consecutive authorization failures allowed per hostname for an account, the refill rate, and the consequences of exceeding this limit. It also provides a table showing the time to pause based on daily failure rates and notes that overrides are not offered.

```APIDOC
Authorization Failures per Hostname:
  Limit: Up to 3,600 consecutive failures per hostname per account
  Refill Rate: 1 per hostname per day
  Reset Condition: Successful authorization for that hostname
  Consequence: Account prevented from requesting new certificates for that hostname
  Self-Service Portal: Link provided in error for unpausing issuance
  Overrides: Not offered

Failure Rate vs. Time to Pause:
  Failures per Day | Time to Pause
  -----------------|--------------
  1                | ∞ (never paused)
  2                | 3,600 days (9.86 years)
  5                | 900 days (2.46 years)
  10               | 400 days (1.10 years)
  15               | 257 days (8.45 months)
  20               | 189 days (6.22 months)
  30               | 124 days (4.08 months)
  40               | 92 days (3.03 months)
  120              | 30 days
```

--------------------------------

### Certificate Profile Definition

Source: https://letsencrypt.org/docs/glossary

Defines a Profile as a collection of properties affecting certificate validation and content, referencing further documentation for details.

```APIDOC
Profile:
  Description: A Profile is a collection of properties which affect both the validation of and final contents of a certificate.
```

--------------------------------

### Retrieve Let's Encrypt Account ID with Certbot (v1.23.0+)

Source: https://letsencrypt.org/docs/account-id

Use the `certbot show_account` subcommand to quickly find your Let's Encrypt account ID. This method is recommended for Certbot versions 1.23.0 and newer.

```Bash
certbot show_account
```

--------------------------------

### RSA Algorithm Definition

Source: https://letsencrypt.org/docs/glossary

Defines RSA as a public-key algorithm used for encryption and digitally signing certificates.

```APIDOC
RSA:
  Description: A public-key algorithm used for encryption and to digitally sign certificates.
```

--------------------------------

### Let's Encrypt Staging Environment API Rate Limits

Source: https://letsencrypt.org/docs/staging-environment

Detailed rate limits for various endpoints within the Let's Encrypt ACME v2 staging environment, designed to allow extensive testing without impacting production limits. These limits apply per IP and include burst capacities.

```APIDOC
Overall Requests Limits:
Endpoint: /acme/new-nonce
  Requests per IP (per second): 20
  Burst Capacity: 10

Endpoint: /acme/new-account
  Requests per IP (per second): 5
  Burst Capacity: 15

Endpoint: /acme/new-order
  Requests per IP (per second): 20
  Burst Capacity: 40

Endpoint: /acme/revoke-cert
  Requests per IP (per second): 10
  Burst Capacity: 100

Endpoint: /acme/renewal-info
  Requests per IP (per second): 1000
  Burst Capacity: 100

Endpoint: /acme/*
  Requests per IP (per second): 20
  Burst Capacity: 20

Endpoint: /directory
  Requests per IP (per second): 40
  Burst Capacity: 40
```