Skip to content

Knowledge Base · Category 18

ACME in depth

9 articles

This chapter explains how TLSPilot obtains certificates from public ACME providers, how it knows when to renew them, what ACME profiles are, how CAA records in DNS restrict which CA may issue, and how the CA validates a challenge. You do not need these details to issue your first certificate, but they help you understand the settings in chapter ACME certificate (AC) and find the cause when a validation fails.

Articles in this category

  1. 18.1

    How ACME works

    ACME (Automatic Certificate Management Environment, RFC 8555) is an open internet protocol.

  2. 18.2

    ARI – ACME Renewal Information

    ARI (ACME Renewal Information, RFC 9773) lets the CA tell TLSPilot when a certificate should be renewed.

  3. 18.3

    ACME profiles

    Some CAs offer several kinds of certificates under one ACME directory, for example with different validity.

  4. 18.4

    CAA records

    This section is DNS background. TLSPilot does not create or check CAA records, but a CAA record that does not fit makes the CA refuse the certificate, and TLSPilot then shows the error of the CA.

  5. 18.5

    Multi-perspective validation

    This section is background. TLSPilot cannot change how the CA validates, but the settings of your DNS, firewall and network decide whether the validation succeeds.

  6. 18.6

    DNS-01

    With DNS-01, you prove control of a name through its public DNS zone (RFC 8555, section 8.4).

  7. 18.7

    DNS-01 challenge delegation (CNAME alias)

    With DNS-01 challenge delegation, the CA validates the names of the certificate through a CNAME record that points into a separate DNS zone, the alias zone.

  8. 18.8

    HTTP-01

    With HTTP-01, you prove control of a name with a file on the web server that the name points to (RFC 8555, section 8.3).

  9. 18.9

    TLS-ALPN-01

    With TLS-ALPN-01, you prove control of a name with a special TLS handshake on port 443 (RFC 8737).