<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-acme-ari-08" number="9773" consensus="true" submissionType="IETF" category="std" updates="" obsoletes="" symRefs="true" sortRefs="true" xml:lang="en" tocInclude="true" indexInclude="true"> <front> <title abbrev="ACMEARI">Automated Certificate Management Environment (ACME)ARI">ACME Renewal Information (ARI)Extension</title><seriesInfo value="draft-ietf-acme-ari-08" stream="IETF" status="standard" name="Internet-Draft"/>Extension</title> <seriesInfo name="RFC" value="9773"/> <author initials="A."surname="Gable"><organization>Internetsurname="Gable"> <organization>Internet Security ResearchGroup</organization><address><postal><street/> </postal><email>aaron@letsencrypt.org</email> </address></author><date/> <area>Security Area (sec)</area> <workgroup>ACME Working Group</workgroup> <keyword>Internet-Draft</keyword>Group</organization> <address> <email>aaron@letsencrypt.org</email> </address> </author> <date month="May" year="2025"/> <area>SEC</area> <workgroup>acme</workgroup> <keyword>certificate</keyword> <keyword>CA</keyword> <keyword>x509</keyword> <keyword>pki</keyword> <keyword>webpki</keyword> <keyword>renew</keyword> <keyword>replace</keyword> <abstract> <t>This document specifies how anACMEAutomated Certificate Management Environment (ACME) server may provide suggestions to ACME clients as to when they should attempt to renew their certificates. This allows servers to mitigate loadspikes,spikes and ensures that clients do not make false assumptions about appropriate certificate renewal periods.</t> </abstract><note><name>Current Implementations</name> <t>Draft note: this section will be removed by the editor before final publication.</t> <t>Let's Encrypt's <eref target="https://github.com/letsencrypt/boulder">Boulder</eref> software fully implements the server side of an earlier version of this draft, and that implementation is deployed in both the <eref target="https://acme-v02.api.letsencrypt.org/directory">Production</eref> and <eref target="https://acme-staging-v02.api.letsencrypt.org/directory">Staging</eref> environments. Google Trust Services has <eref target="https://security.googleblog.com/2023/05/google-trust-services-acme-api_0503894189.html">done the same</eref>. Client implementations include <eref target="https://github.com/go-acme/lego">Lego</eref>, <eref target="https://github.com/eggsampler/acme">eggsampler</eref>, <eref target="https://github.com/mholt/acmez">ACMEz</eref>, and <eref target="https://github.com/win-acme/win-acme">win-acme</eref>.</t> </note></front> <middle> <section anchor="introduction"><name>Introduction</name> <t>Most ACME <xref target="RFC8555"/> clients today choose when to attempt to renew a certificate in one of threeways. Theyways:</t> <ol> <li>they may be configured to renew at a specific interval (e.g., via<tt>cron</tt>), theycron),</li> <li>they may parse the issued certificate to determine its expiration date and renew a specific amount of time before then,or theyor</li> <li>they may parse the issued certificate and renew when some percentage of its validity period haspassed. Thepassed.</li> </ol> <t>The first twotechniquescreate significant barriers against the issuing Certification Authority (CA) changing certificate lifetimes. All threetechniquesways may lead to load clustering for the issuing CA due totheits inabilityof the issuing CAto schedule renewal requests.</t> <t>Allowing issuing CAs to suggest a period in which clients should renew their certificates enables dynamic time-based load balancing. This allows a CA to better respond to exceptional circumstances. Forexample, aexample:</t> <ul> <li>a CA could suggest that clients renew prior to a mass-revocation event to mitigate the impact of the revocation,or aor</li> <li>a CA could suggest that clients renew earlier than they normally would to reduce the size of an upcoming mass-renewalspike.</t>spike.</li></ul> <t>This document specifies the ACME Renewal Information(ARI),(ARI) extension, a mechanism by which ACME servers may provide suggested renewal windows to ACMEclients,clients and by which ACME clients may inform ACME servers that they have successfully renewed and replaced a certificate.</t> </section> <section anchor="conventions-and-definitions"><name>Conventions and Definitions</name><t>The<t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xreftarget="RFC2119"/><xreftarget="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <t>Throughout this document, the word "renewal" and its variants are taken to encompass any combination of "Renewal", "Re-Key", and "Modification" as defined in <xref target="RFC3647"/>.</t> <t>This document assumes that the certificates being issued by the ACME server are in compliance with <xreftarget="RFC5280"/>, andtarget="RFC5280"/> and, inparticularparticular, contain the Authority Key Identifier extension and the keyIdentifier field within that extension.</t> </section> <section anchor="extensions-to-the-directory-object"><name>Extensions to the Directory Object</name> <t>An ACME serverwhichthat wishes to provide renewal information <bcp14>MUST</bcp14> include a new field,<tt>renewalInfo</tt>,"<tt>renewalInfo</tt>", in its directory object.</t> <table> <thead> <tr> <th>Field</th> <th>URL in Value</th> </tr> </thead> <tbody> <tr> <td>renewalInfo</td> <td>Renewalinfo</td>information</td> </tr> </tbody> </table> <sourcecodetype="json"><![CDATA[HTTP/1.1type="json"><![CDATA[ HTTP/1.1 200 OK Content-Type: application/json { "newNonce": "https://acme.example.com/new-nonce", "newAccount": "https://acme.example.com/new-account", "newOrder": "https://acme.example.com/new-order", "newAuthz": "https://acme.example.com/new-authz", "revokeCert": "https://acme.example.com/revoke-cert", "keyChange": "https://acme.example.com/key-change", "renewalInfo": "https://acme.example.com/renewal-info", "meta": { "termsOfService": "https://example.com/acme/terms", "website": "https://example.com/acme/docs", "caaIdentities": ["example.com"], "externalAccountRequired": false } }]]> </sourcecode>]]></sourcecode> </section> <section anchor="getting-renewal-information"><name>Getting Renewal Information</name> <section anchor="the-renewalinfo-resource"><name>The"renewalInfo"RenewalInfo Resource</name> <t>The"<tt>renewalInfo</tt>"RenewalInfo resource is a new resource type introduced to the ACME protocol. This new resource allows clients to query the server for suggestions on when they should renew certificates.</t> <t>To request the suggested renewal information for a certificate, the client sends an unauthenticated GET request to a path under the server's <tt>renewalInfo</tt> URL.</t> <t>The path component is a unique identifier for the certificate in question. The unique identifier is constructed by concatenating thebase64url-encodingbase64url encoding <xref target="RFC4648"/> of the<tt>keyIdentifier</tt>keyIdentifier field of the certificate's Authority Key Identifier (AKI) <xref target="RFC5280"/> extension,a literal period,the period character ".", and thebase64url-encodingbase64url encoding of the DER-encoded Serial Number field (without the tag and length bytes). All trailing "<tt>=</tt>" charactersMUST<bcp14>MUST</bcp14> be stripped from both parts of the unique identifier.</t><t>Thus<t>Thus, the full request URL is constructed as follows (split onto multiple lines for readability), where the "<tt>||</tt>" operator indicates string concatenation and therenewalInfo<tt>renewalInfo</tt> URL is taken from the Directory object:</t> <sourcecodetype="text"><![CDATA[urltype=""><![CDATA[ url = renewalInfo || '/' || base64url(AKI keyIdentifier) || '.' || base64url(Serial)]]> </sourcecode>]]></sourcecode> <t>For example, to request renewal information for the end-entity certificate given in Appendix A, the client would make the request as follows:</t> <olspacing="compact">spacing="normal"> <li>The<tt>keyIdentifier</tt>keyIdentifier field of the certificate's AKI extension has the hexadecimal bytes <tt>69:88:5B:6B:87:46:40:41:E1:B3:7B:84:7B:A0:AE:2C:DE:01:C8:D4</tt> as its ASN.1 Octet String value. The base64url encoding of those bytes is <tt>aYhba4dGQEHhs3uEe6CuLN4ByNQ=</tt>.</li> <li>The certificate's Serial Number field has the hexadecimal bytes <tt>00:87:65:43:21</tt> as its DER encoding (note the leading zero byte to ensure the serial number remains positive despite the leading 1 bit in <tt>0x87</tt>). The base64url encoding of those bytes is <tt>AIdlQyE=</tt>.</li> <li>Stripping the trailing padding characters and concatenating with the separator, the unique identifier is therefore <tt>aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE</tt>, and the client makes the request:</li> </ol> <sourcecodetype="text"><![CDATA[GETtype=""><![CDATA[ GET /renewal-info/aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE HTTP/1.1 Host: acme.example.com Accept: application/json]]> </sourcecode>]]></sourcecode> </section> <section anchor="renewalinfo-objects"><name>RenewalInfo Objects</name> <t>The structure of an ACME<tt>renewalInfo</tt> resourceRenewalInfo object is as follows:</t><t><tt>suggestedWindow</tt><dl spacing="normal" newline="true"> <dt><tt>suggestedWindow</tt> (object,required): Arequired):</dt><dd>A JSON object with two keys, "<tt>start</tt>" and "<tt>end</tt>", whose values are timestamps, encoded in the format specified in <xref target="RFC3339"/>, which bound the window of time in which the CA recommends renewing thecertificate.</t> <t><tt>explanationURL</tt>certificate.</dd> <dt><tt>explanationURL</tt> (string,optional): Aoptional):</dt><dd>A URL pointing to a pagewhichthat may explain why the suggested renewal window has its current value. For example, it may be a page explaining the CA's dynamic load-balancingstrategy,strategy or a page documenting which certificates are affected by amass revocationmass-revocation event. Clients <bcp14>SHOULD</bcp14> provide this URL to their operator, ifpresent.</t>present.</dd> </dl> <sourcecodetype="json"><![CDATA[HTTP/1.1type="json"><![CDATA[ HTTP/1.1 200 OK Content-Type: application/json Retry-After: 21600 { "suggestedWindow": { "start": "2025-01-02T04:00:00Z", "end": "2025-01-03T04:00:00Z" }, "explanationURL": "https://acme.example.com/docs/ari" }]]> </sourcecode>]]></sourcecode> <t>Clients <bcp14>MUST</bcp14> attempt renewal at a time of their choosing based on the suggested renewal window. The following algorithm is <bcp14>RECOMMENDED</bcp14> for choosing a renewal time:</t> <olspacing="compact"> <li>Query thespacing="normal"> <li>Make a <tt>renewalInfo</tt>resourcerequest to get a suggested renewal window.</li> <li>Select a uniform random time within the suggested window.</li> <li>If the selected time is in the past, attempt renewal immediately.</li> <li>Otherwise, if the client can schedule itself to attempt renewal at exactly the selected time, do so.</li> <li>Otherwise, if the selected time is before the next time that the client would wake up normally, attempt renewal immediately.</li> <li>Otherwise, sleep until the time indicated by the<tt>Retry-After</tt>Retry-After header and return to Step 1.</li> </ol> <t>In all cases, renewal attempts are subject to the client's existing error backoff and retry intervals.</t> <t>In particular, cron-based clients may find they need to increase their run frequency to check ARI more frequently. Those clients will need to store information about failures so that increasing their run frequency doesn't lead to retrying failures without proper backoff. Typical information stored should include: number of failures for a given order (defined by the set of names on theorder),order) and time of the most recent failure.</t> <t>A RenewalInfo object in which the <tt>end</tt> timestamp equals or precedes the <tt>start</tt> timestamp is invalid. ServersMUST NOT<bcp14>MUST NOT</bcp14> serve such a response, and clientsMUST<bcp14>MUST</bcp14> treat one as though they failed to receive any response from the server (e.g., retry at an appropriate interval, renew on a fallback schedule, etc.).</t> </section> <section anchor="schedule-for-checking-the-renewalinfo-resource"><name>Schedule forcheckingChecking the RenewalInforesource</name>Resource</name> <t>ClientsSHOULD<bcp14>SHOULD</bcp14> fetch a certificate's RenewalInfo immediately after issuance.</t> <t>During the lifetime of a certificate, the renewal information needs to be fetched frequently enough that clients learn about changes in the suggested window quickly, but without overwhelming the server. This protocol uses the Retry-After header <xref target="RFC9110"/> to indicate to clients how often to retry. Note that in other HTTP applications, Retry-After often indicates the minimum time to wait before retrying a request. In this protocol, it indicates the desired(i.e.(i.e., both requested minimum and maximum) amount of time to wait.</t> <t>ClientsMUST NOT<bcp14>MUST NOT</bcp14> check a certificate's RenewalInfo after the certificate has expired. ClientsMUST NOT<bcp14>MUST NOT</bcp14> check a certificate's RenewalInfo after they consider the certificate to be replaced (for instance, after a new certificate for the same identifiers has been received and configured).</t> <section anchor="server-choice-of-retry-after"><name>ServerchoiceChoice of Retry-After</name> <t>Servers set the Retry-After header based on their requirements on how quickly to perform a revocation. For instance, a server that needs to revoke certificates within 24 hours of notification of a problem might choose to reserve twelve hours for investigation, six hours for clients to fetchRenewalInfo,updated RenewalInfo objects, and six hours for clients to perform a renewal. Setting a small value for Retry-After means that clients can respond morequickly,quickly but also incurs more load on the server. Servers should estimate their expected load based on the number of clients, keeping in mind that third parties may also monitorRenewalInfo<tt>renewalInfo</tt> endpoints.</t> </section> <section anchor="client-handling-of-retry-after"><name>ClienthandlingHandling of Retry-After</name> <t>After an initial fetch of a certificate's RenewalInfo, clientsMUST<bcp14>MUST</bcp14> fetch it again as soon as possible after the time indicated in the Retry-After header (backoff on errors takes priority, though). ClientsMUST<bcp14>MUST</bcp14> set reasonable limits on their checking interval. For example, values under one minute could be treated as if they were one minute, and values over one day could be treated as if they were one day.</t> </section> <section anchor="error-handling"><name>Errorhandling</name>Handling</name> <t>Temporary errors include, for instance:</t> <ul spacing="compact"> <li>Connection timeout</li> <li>Request timeout</li> <li>5xx HTTP errors</li> </ul> <t>On receiving a temporary error, clientsSHOULD<bcp14>SHOULD</bcp14> do exponential backoff with a capped number of tries. If all tries are exhausted, clientsMUST<bcp14>MUST</bcp14> treat the request as a long-term error.</t><t>Long term<t>Examples of long-term errorsinclude, for instance:</t>include:</t> <ul spacing="compact"> <li>Retry-After is invalid or not present</li> <li>RenewalInfo object is invalid</li> <li>DNS lookup failure</li> <li>Connection refused</li> <li>Non-5xx HTTP error</li> </ul> <t>On receiving along termlong-term error, clientsMUST perform<bcp14>MUST</bcp14> make the nextRenewalInfo fetch<tt>renewalInfo</tt> request as soon as possible after six hours have passed (or some other locally configured default).</t> </section> </section> </section> <section anchor="extensions-to-the-order-object"><name>Extensions to the Order Object</name> <t>In order to convey information regarding which certificate requests represent renewals of previous certificates, a new field is added to the Order object:</t><t><tt>replaces</tt><dl spacing="normal" newline="true"> <dt><tt>replaces</tt> (string,optional): Aoptional):</dt><dd>A string uniquely identifying apreviously-issuedpreviously issued certificatewhichthat this order is intended to replace. This unique identifier is constructed in the same way as the path component for GET requests describedabove.</t>above.</dd> </dl> <t>Clients <bcp14>SHOULD</bcp14> include this field inNew OrdernewOrder requests if there is a clear predecessor certificate, as is the case for most certificate renewals. Clients <bcp14>SHOULD NOT</bcp14> include this field if the ACMEServerserver has not indicated that it supports this protocol by advertising the <tt>renewalInfo</tt> resource in its Directory.</t> <sourcecodetype="text"><![CDATA[POSTtype=""><![CDATA[ POST /new-order HTTP/1.1 Host: acme.example.com Content-Type: application/jose+json { "protected": base64url({ "alg": "ES256", "kid": "https://acme.example.com/acct/evOfKhNU60wg", "nonce": "5XJ1L3lEkMG7tR6pA00clA", "url": "https://acme.example.com/new-order" }), "payload": base64url({ "identifiers": [ { "type": "dns", "value": "acme.example.com" } ], "replaces": "aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE" }), "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g" }]]> </sourcecode>]]></sourcecode> <t>Servers <bcp14>SHOULD</bcp14> check that the identified certificate and theNew OrdernewOrder request correspond to the same ACME Account, that they share at least one identifier, and that the identified certificate has not already been marked as replaced by a different Order that is not "invalid". Correspondence checks beyond this (such as requiring exact identifier matching) are left up toServerserver policy. If any of these checks fail, theServerserver <bcp14>SHOULD</bcp14> reject thenew-ordernewOrder request. If theServerserver rejects the request because the identified certificate has already been marked as replaced, it <bcp14>MUST</bcp14> return an HTTP 409 (Conflict) with a problem document of type "alreadyReplaced" (seeSection 7.4).</t><xref target="acme-error-types"/>).</t> <t>If theServerserver accepts anew-ordernewOrder request with a "replaces" field, it <bcp14>MUST</bcp14> reflect that field in the response and in subsequent requests for the corresponding Order object.</t> <t>This replacement information may serve many purposes, including but not limited to:</t> <ulspacing="compact">spacing="normal"> <li>grantingNew OrdernewOrder requestswhichthat arrive during the suggested renewal window of their identified predecessor certificate higher priority orallowallowing them to bypass rate limits, if theServer'sserver's policy uses such;</li> <li>tracking the replacement of certificateswhichthat have been affected by a compliance incident, so that they can be revoked immediately after they are replaced; and</li> <li>tying together certificates issued under the same contract with an entity identified by External Account Binding.</li> </ul> </section> <section anchor="security-considerations"><name>Security Considerations</name> <t>The extensions to the ACME protocol described in this documentbuildsbuild upon theSecurity Considerationssecurity considerations and threat model defined in <xreftarget="RFC8555"/>, Section 10.1.</t>target="RFC8555" section="10.1"/>.</t> <t>This document specifies that<tt>renewalInfo</tt>RenewalInfo resources are exposed and accessed via unauthenticated GET requests, a departure fromRFC8555'sthe requirement in RFC 8555 that clients send POST-as-GET requests to fetch resources from the server. This is because the information contained in<tt>renewalInfo</tt>RenewalInfo resources is not consideredconfidential,confidential and because allowing<tt>renewalInfo</tt>RenewalInfo resources to be easily cached is advantageous to shed the load from clientswhichthat do not respect the Retry-After header. As always, servers should take measures to ensure that unauthenticated requests for renewal information cannot result in denial-of-service attacks. These measures might include ensuring that a cache does not include superfluous request headers or query parameters in its cache key, instituting IP-based rate limits, or other general best-practice measures.</t> <t>Note that this protocol could exhibit undesired behavior in the presence of significant clock skew between the ACME client and server. For example, if a server places the suggested renewal window wholly in the past to encourage a client to renew immediately, a client with a sufficiently slow clock might nonetheless see the window as being in the future. Similarly, a serverwhichthat wishes to schedule renewals very precisely may have difficulty doing so if some clients have skewed clocks (or do no implement ARI at all). Server operators should take this concern into account when setting suggested renewal windows. However, many other protocols (including TLS handshakes themselves) fall apart with sufficient clock skew, so this is not unique to this protocol.</t> </section> <sectionanchor="iana-considerations"><name>IANAanchor="iana-considerations"> <name>IANA Considerations</name> <sectionanchor="acme-resource-type"><name>ACMEanchor="acme-resource-type"> <name>ACME Resource Type</name> <t>IANAwill addhas added the following entry to the "ACME Resource Types" registry within the "Automated Certificate Management Environment (ACME) Protocol" registry group at <ereftarget="https://www.iana.org/assignments/acme">https://www.iana.org/assignments/acme</eref>:</t>target="https://www.iana.org/assignments/acme" brackets="angle"/>:</t> <table> <thead> <tr> <th>Field Name</th> <th>Resource Type</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>renewalInfo</td><td>Renewal Info<td>RenewalInfo object</td> <td>This document</td> </tr> </tbody> </table></section> <sectionanchor="acme-renewal-info-object-fields"><name>ACME Renewal Infoanchor="acme-renewalinfo-object-fields"> <name>ACME RenewalInfo Object Fields</name> <t>IANAwill addhas added the following new registry to the "Automated Certificate Management Environment (ACME) Protocol" registry group at <ereftarget="https://www.iana.org/assignments/acme">https://www.iana.org/assignments/acme</eref>:</t> <t>Registry Name: ACME Renewal Infotarget="https://www.iana.org/assignments/acme" brackets="angle"/>:</t> <dl spacing="normal" newline="true"> <dt>Registry Name:</dt><dd>ACME RenewalInfo ObjectFields</t> <t>Registration Procedure: Specification Required.Fields</dd> <dt>Registration Procedure:</dt><dd>Specification Required (see <xref target="RFC8126"/>). The designated expert should ensure that any new fields added to this registry carry useful and unique information that does not better belong elsewhere in the ACMEprotocol.</t> <t>Template:</t> <ul spacing="compact"> <li>Field name: Theprotocol.</dd> <dt>Template:</dt> <dd> <dl spacing="compact" newline="false"> <dt>Field name:</dt><dd>The string to be used as a field name in the JSONobject</li> <li>Field type: Theobject</dd> <dt>Field type:</dt><dd>The type of value to be provided, e.g., string, boolean, array ofstring</li> <li>Reference: Wherestring</dd> <dt>Reference:</dt><dd>Where this field isdefined</li> </ul> <t>Initial contents:</t>defined</dd> </dl> </dd> <dt>Initial contents:</dt> <dd> <table> <thead> <tr> <th>Field Name</th> <th>Fieldtype</th>Type</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>suggestedWindow</td> <td>object</td> <td>This document</td> </tr> <tr> <td>explanationURL</td> <td>string</td> <td>This document</td> </tr> </tbody></table></section></table> </dd> </dl> </section> <sectionanchor="acme-order-object-fields"><name>ACMEanchor="acme-order-object-fields"> <name>ACME Order Object Fields</name> <t>IANAwill addhas added the following entry to the "ACME Order Object Fields" registry within the "Automated Certificate Management Environment (ACME) Protocol" registry group at <ereftarget="https://www.iana.org/assignments/acme">https://www.iana.org/assignments/acme</eref>:</t>target="https://www.iana.org/assignments/acme" brackets="angle"/>:</t> <table> <thead> <tr> <th>Field Name</th> <th>Field Type</th> <th>Configurable</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>replaces</td> <td>string</td> <td>true</td> <td>This document</td> </tr> </tbody></table></section></table> </section> <sectionanchor="acme-error-types"><name>ACMEanchor="acme-error-types"> <name>ACME Error Types</name> <t>IANAwill addhas added the following entry to the "ACME Error Types" registry within the "Automated Certificate Management Environment (ACME) Protocol" registry group at <ereftarget="https://www.iana.org/assignments/acme">https://www.iana.org/assignments/acme</eref>:</t>target="https://www.iana.org/assignments/acme" brackets="angle"/>:</t> <table> <thead> <tr> <th>Type</th> <th>Description</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>alreadyReplaced</td> <td>The request specified a predecessor certificatewhichthat has already been marked as replaced</td> <td>This document</td> </tr> </tbody></table></section></table> </section> </section> </middle> <back> <references><name>References</name> <references><name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3339.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8555.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/> </references> <references><name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3647.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> </references> </references> <section anchor="appendix-a-example-certificate" numbered="false"><name>Appendix A. Example Certificate</name> <sourcecodetype="text"><![CDATA[-----BEGINtype=""><![CDATA[ -----BEGIN CERTIFICATE----- MIIBQzCB66ADAgECAgUAh2VDITAKBggqhkjOPQQDAjAVMRMwEQYDVQQDEwpFeGFt cGxlIENBMCIYDzAwMDEwMTAxMDAwMDAwWhgPMDAwMTAxMDEwMDAwMDBaMBYxFDAS BgNVBAMTC2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEeBZu 7cbpAYNXZLbbh8rNIzuOoqOOtmxA1v7cRm//AwyMwWxyHz4zfwmBhcSrf47NUAFf qzLQ2PPQxdTXREYEnKMjMCEwHwYDVR0jBBgwFoAUaYhba4dGQEHhs3uEe6CuLN4B yNQwCgYIKoZIzj0EAwIDRwAwRAIge09+S5TZAlw5tgtiVvuERV6cT4mfutXIlwTb +FYN/8oCIClDsqBklhB9KAelFiYt9+6FDj3z4KGVelYM5MdsO3pK -----END CERTIFICATE-----]]> </sourcecode>]]></sourcecode> </section> <section anchor="acknowledgments"numbered="false"><name>Acknowledgments</name>numbered="false"> <name>Acknowledgments</name> <t>My thanks toRoland Shoemaker and Jacob Hoffman-Andrews<contact fullname="Roland Shoemaker"/> and <contact fullname="Jacob Hoffman-Andrews"/> for coming up with the initial idea of ARI and for helping me learn the IETF process. Thanks also toSamantha Frank, Matt Holt, Ilari Liusvaara, and Wouter Tinus<contact fullname="Samantha Frank"/>, <contact fullname="Matt Holt"/>, <contact fullname="Ilari Liusvaara"/>, and <contact fullname="Wouter Tinus"/> for contributing client implementations, and toFreddy Zhang<contact fullname="Freddy Zhang"/> for contributing an independent server implementation. Finally, thanks toRob Stradling, Andrew Ayer, and J.C. Jones<contact fullname="Rob Stradling"/>, <contact fullname="Andrew Ayer"/>, and <contact fullname="J.C. Jones"/> for providing meaningful feedback and suggestionswhichthat significantly improved this specification.</t> </section> </back> </rfc>