6. Message Transport (Nachrichtenübertragung)

Die Kommunikation zwischen ACME-Clients und ACME-Servern erfolgt über HTTPS, wobei JSON Web Signature (JWS) [RFC7515] verwendet wird, um einige zusätzliche Sicherheitseigenschaften für Nachrichten bereitzustellen, die vom Client an den Server gesendet werden. HTTPS bietet Server-Authentifizierung und Vertraulichkeit. Mit einigen ACME-spezifischen Erweiterungen bietet JWS Authentifizierung der Client-Anforderungsnutzlast, Replay-Schutz und Integrität der HTTPS-Anforderungs-URL.

6.1. HTTPS Requests (HTTPS-Anforderungen)

Jede ACME-Funktion wird durch eine Reihe von HTTPS-Anforderungen des Clients an den Server [RFC2818] ausgeführt, die JSON-Nachrichten [RFC8259] tragen. Die Verwendung von HTTPS ist ERFORDERLICH (REQUIRED). Jeder Unterabschnitt von Abschnitt 7 unten beschreibt das Nachrichtenformat, das für diese Funktion verwendet wird, und die Reihenfolge, in der Nachrichten gesendet werden.

In den meisten HTTPS-Transaktionen, die ACME verwendet, ist der ACME-Client der HTTPS-Client und der ACME-Server der HTTPS-Server. Der ACME-Server agiert als Client bei der Validierung von Herausforderungen: als HTTP-Client bei der Validierung von 'http-01'-Herausforderungen, als DNS-Client bei der Validierung von 'dns-01' usw.

ACME-Server SOLLTEN (SHOULD) bei der Konfiguration ihrer TLS-Implementierung den Empfehlungen von [RFC7525] folgen. ACME-Server, die TLS 1.3 unterstützen, KÖNNEN (MAY) Clients erlauben, Early Data (0-RTT) zu senden. Dies ist sicher, da das ACME-Protokoll selbst in allen Fällen, in denen es benötigt wird, Replay-Schutz enthält (siehe Abschnitt 6.5). Daher gibt es keine Einschränkungen dafür, welche ACME-Daten in 0-RTT übertragen werden können.

ACME-Clients MÜSSEN (MUST) das User-Agent-Headerfeld gemäß [RFC7231] senden. Dieses Headerfeld SOLLTE (SHOULD) neben dem Namen und der Version der zugrunde liegenden HTTP-Client-Software auch den Namen und die Version der ACME-Software enthalten.

ACME-Clients SOLLTEN (SHOULD) das Accept-Language-Headerfeld gemäß [RFC7231] senden, um die Lokalisierung von Fehlermeldungen zu ermöglichen.

ACME-Server, die allgemein zugänglich sein sollen, müssen Cross-Origin Resource Sharing (CORS) verwenden, damit sie von browserbasierten Clients zugänglich sind [W3C.REC-cors-20140116]. Solche Server SOLLTEN (SHOULD) das Access-Control-Allow-Origin-Headerfeld auf den Wert „*" setzen.

Binäre Felder in JSON-Objekten, die von ACME verwendet werden, werden mit der base64url-Kodierung gemäß Abschnitt 5 von [RFC4648] kodiert, entsprechend dem in JSON Web Signature in Abschnitt 2 von [RFC7515] angegebenen Profil. Diese Kodierung verwendet einen URL-sicheren Zeichensatz. Nachgestellte '='-Zeichen MÜSSEN (MUST) entfernt werden. Kodierte Werte, die nachgestellte '='-Zeichen enthalten, MÜSSEN (MUST) als falsch kodiert abgelehnt werden.

6.2. Request Authentication (Anforderungsauthentifizierung)

Alle ACME-Anforderungen mit einem nicht leeren Körper MÜSSEN (MUST) ihre Nutzlast in einem JSON Web Signature (JWS) [RFC7515]-Objekt einschließen, das mit dem privaten Schlüssel des Kontos signiert ist, sofern nicht anders angegeben. Der Server MUSS (MUST) das JWS validieren, bevor er die Anforderung verarbeitet. Das Einschließen des Anforderungskörpers in ein JWS bietet Authentifizierung der Anforderung.

JWS-Objekte, die als ACME-Anforderungskörper gesendet werden, MÜSSEN (MUST) die folgenden zusätzlichen Kriterien erfüllen:

• Das JWS MUSS (MUST) die flache JSON-Serialisierung (Flattened JSON Serialization) [RFC7515] verwenden

• Das JWS DARF NICHT (MUST NOT) mehrere Signaturen haben

• Die JWS Unencoded Payload Option (JWS Unencoded Payload Option) [RFC7797] DARF NICHT (MUST NOT) verwendet werden

• Der JWS Unprotected Header (JWS Unprotected Header) [RFC7515] DARF NICHT (MUST NOT) verwendet werden

• Die JWS-Nutzlast DARF NICHT (MUST NOT) getrennt werden

• Der JWS Protected Header MUSS (MUST) die folgenden Felder enthalten:

  • „alg" (Algorithmus, Algorithm)

    • Dieses Feld DARF NICHT (MUST NOT) „none" oder einen Message Authentication Code (MAC)-Algorithmus enthalten (z. B. Algorithmen, bei denen die Beschreibung im Algorithmusregister MAC/HMAC erwähnt).

  • „nonce" (definiert in Abschnitt 6.5)

  • „url" (definiert in Abschnitt 6.4)

  • „jwk" (JSON Web Key) oder „kid" (Key ID), wie unten beschrieben

ACME-Server MÜSSEN (MUST) den Signaturalgorithmus „ES256" [RFC7518] implementieren und SOLLTEN (SHOULD) den Signaturalgorithmus „EdDSA" [RFC8037] mit der Variante „Ed25519" (angegeben durch „crv") implementieren.

Die Felder „jwk" und „kid" schließen sich gegenseitig aus. Der Server MUSS (MUST) Anforderungen ablehnen, die beide enthalten.

Für newAccount-Anforderungen sowie revokeCert-Anforderungen, die durch den Zertifikatsschlüssel authentifiziert werden, MUSS (MUST) ein „jwk"-Feld vorhanden sein. Dieses Feld MUSS (MUST) den öffentlichen Schlüssel enthalten, der dem privaten Schlüssel entspricht, der zum Signieren des JWS verwendet wurde.

Für alle anderen Anforderungen wird die Anforderung mit einem bestehenden Konto signiert, und es MUSS (MUST) ein „kid"-Feld vorhanden sein. Dieses Feld MUSS (MUST) die Konto-URL enthalten, die durch POST an die newAccount-Ressource empfangen wurde.

Wenn ein Client ein JWS sendet, das mit einem Algorithmus signiert ist, den der Server nicht unterstützt, MUSS (MUST) der Server den Statuscode 400 (Bad Request) und einen Fehler vom Typ „urn:ietf:params:acme:error:badSignatureAlgorithm" zurückgeben. Das mit dem Fehler zurückgegebene Problemdokument MUSS (MUST) ein „algorithms"-Feld enthalten, das ein Array der unterstützten „alg"-Werte enthält. Weitere Details zur Fehlerantwortstruktur finden Sie in Abschnitt 6.7.

Wenn der Server den Signaturalgorithmus „alg" unterstützt, aber den öffentlichen Schlüssel „jwk" nicht unterstützt oder ablehnt, MUSS (MUST) der Server den Statuscode 400 (Bad Request) und einen Fehler vom Typ „urn:ietf:params:acme:error:badPublicKey" zurückgeben. Die Details des Problemdokuments SOLLTEN (SHOULD) den Grund für die Ablehnung des öffentlichen Schlüssels beschreiben; einige Beispielgründe sind:

• „alg" ist „RS256", aber der Modulus „n" ist zu klein (z. B. 512 Bit)

• „alg" ist „ES256", aber „jwk" enthält keinen gültigen P-256-öffentlichen Schlüssel

• „alg" ist „EdDSA" und „crv" ist „Ed448", aber der Server unterstützt nur „EdDSA" mit „Ed25519"

• Der entsprechende private Schlüssel ist bekanntermaßen kompromittiert

Da Client-Anforderungen in ACME JWS-Objekte in der flachen JSON-Serialisierung tragen, MÜSSEN sie das Content-Type-Headerfeld auf „application/jose+json" setzen. Wenn eine Anforderung diese Anforderung nicht erfüllt, MUSS (MUST) der Server mit dem Statuscode 415 (Unsupported Media Type) antworten.

6.3. GET and POST-as-GET Requests (GET- und POST-as-GET-Anforderungen)

Beachten Sie, dass die Authentifizierung über einen signierten JWS-Anforderungskörper bedeutet, dass Anforderungen ohne Entitätskörper nicht authentifiziert sind, insbesondere GET-Anforderungen. Außer in den in diesem Abschnitt beschriebenen Fällen MUSS (MUST) der Server, wenn er eine GET-Anforderung erhält, den Statuscode 405 (Method Not Allowed) und einen Fehler vom Typ „malformed" zurückgeben.

Wenn ein Client eine Ressource vom Server abrufen möchte (was sonst mit GET erfolgen würde), MUSS (MUST) er eine POST-Anforderung mit einem JWS-Körper wie oben beschrieben senden, wobei die Nutzlast des JWS eine Zeichenkette mit null Oktetten ist. Mit anderen Worten, das „payload"-Feld des JWS-Objekts MUSS (MUST) vorhanden und auf die leere Zeichenkette („") gesetzt sein.

Diese werden als „POST-as-GET"-Anforderungen bezeichnet. Beim Empfang einer Anforderung mit einer null langen (und damit nicht-JSON) Nutzlast MUSS (MUST) der Server den Absender authentifizieren und alle Zugriffssteuerungsregeln überprüfen. Andernfalls MUSS (MUST) der Server diese Anforderung so behandeln, als hätte sie dieselbe Semantik wie eine GET-Anforderung an dieselbe Ressource.

Der Server MUSS (MUST) GET-Anforderungen an die Verzeichnis- und newNonce-Ressourcen (siehe Abschnitt 7.1) sowie POST-as-GET-Anforderungen an diese Ressourcen zulassen. Dies ermöglicht es Clients, sich in das ACME-Authentifizierungssystem einzuführen.

6.4. Request URL Integrity (Anforderungs-URL-Integrität)

In Bereitstellungen ist es üblich, dass die Entität, die TLS für HTTPS beendet, sich von der Entität unterscheidet, die den logischen HTTPS-Server betreibt, mit einer „Anforderungsrouting"-Schicht dazwischen. Beispielsweise könnte eine ACME-CA ein Content Delivery Network haben, das TLS-Verbindungen von Clients beendet, damit es Client-Anforderungen auf Denial-of-Service (DoS)-Schutz überprüfen kann.

Diese Vermittler können auch nicht signierte Anforderungswerte in HTTPS-Anforderungen ändern, wie z. B. die Anforderungs-URL und Headerfelder. ACME verwendet JWS, um einen Integritätsmechanismus bereitzustellen, der verhindert, dass Vermittler die Anforderungs-URL in eine andere ACME-URL ändern.

Wie in Abschnitt 6.2 beschrieben, tragen alle ACME-Anforderungsobjekte einen „url"-Headerparameter in ihrem Protected Header. Dieser Headerparameter kodiert die URL, an die der Client die Anforderung richtet. Beim Empfang eines solchen Objekts in einer HTTP-Anforderung MUSS (MUST) der Server den „url"-Headerparameter mit der Anforderungs-URL vergleichen. Wenn sie nicht übereinstimmen, MUSS (MUST) der Server die Anforderung als nicht autorisiert ablehnen.

Mit Ausnahme der Verzeichnisressource werden alle ACME-Ressourcen über URLs adressiert, die der Server dem Client bereitstellt. In POST-Anforderungen an diese Ressourcen MUSS (MUST) der Client den „url"-Headerparameter auf die genaue Zeichenkette setzen, die der Server bereitgestellt hat (ohne URL-Neukodierung durchzuführen). Der Server SOLLTE (SHOULD) eine entsprechende Zeichenkettengleichheitsprüfung durchführen, indem er für jede Ressource die dem Client bereitgestellte URL-Zeichenkette konfiguriert und die Ressource prüfen lässt, ob die Anforderung dieselbe Zeichenkette in ihrem „url"-Headerparameter hat. Wenn die Zeichenkettengleichheitsprüfung fehlschlägt, MUSS (MUST) der Server die Anforderung als nicht autorisiert ablehnen.

6.4.1. "url" (URL) JWS Header Parameter ("url" (URL) JWS-Headerparameter)

Der „url"-Headerparameter gibt die URL [RFC3986] an, für die dieses JWS-Objekt bestimmt ist. Der „url"-Headerparameter MUSS (MUST) im Protected Header des JWS enthalten sein. Der Wert des „url"-Headerparameters MUSS (MUST) eine Zeichenkette sein, die die Ziel-URL darstellt.

6.5. Replay Protection (Replay-Schutz)

Um ACME-Ressourcen vor möglichen Replay-Angriffen zu schützen, haben ACME-POST-Anforderungen einen obligatorischen Anti-Replay-Mechanismus. Dieser Mechanismus basiert darauf, dass der Server eine Liste der von ihm ausgestellten Nonces pflegt und verlangt, dass jede signierte Anforderung eines Clients eine solche Nonce enthält.

ACME-Server stellen Clients Nonces über das HTTP Replay-Nonce-Headerfeld bereit, wie in Abschnitt 6.5.1 beschrieben. Der Server MUSS (MUST) ein Replay-Nonce-Headerfeld in jede erfolgreiche Antwort auf eine POST-Anforderung aufnehmen und SOLLTE (SHOULD) es auch in Fehlerantworten bereitstellen.

Jedes von einem ACME-Client gesendete JWS MUSS (MUST) einen „nonce"-Headerparameter in seinem Protected Header enthalten, dessen Inhalt wie in Abschnitt 6.5.2 definiert ist. Als Teil der JWS-Validierung MUSS (MUST) der ACME-Server überprüfen, ob der Wert des „nonce"-Headers ein Wert ist, den der Server zuvor in einem Replay-Nonce-Headerfeld bereitgestellt hat. Sobald ein Nonce-Wert in einer ACME-Anforderung erscheint, MUSS (MUST) der Server ihn als ungültig behandeln, als ob er nie ausgestellt worden wäre.

Wenn der Server eine Anforderung aufgrund eines nicht akzeptablen (oder fehlenden) Nonce-Werts ablehnt, MUSS (MUST) er den HTTP-Statuscode 400 (Bad Request) mit dem ACME-Fehlertyp „urn:ietf:params:acme:error:badNonce" angeben. Eine Fehlerantwort mit dem Fehlertyp „badNonce" MUSS (MUST) ein Replay-Nonce-Headerfeld enthalten, das eine frische Nonce enthält, die der Server bei einem Wiederholungsversuch der ursprünglichen Abfrage akzeptieren wird (und möglicherweise bei anderen Anforderungen, gemäß der Nonce-Bereichsrichtlinie des Servers). Beim Empfang einer solchen Antwort SOLLTE (SHOULD) der Client die Anforderung mit der neuen Nonce wiederholen.

Die genaue Methode zur Generierung und Verfolgung von Nonces liegt im Ermessen des Servers. Beispielsweise kann ein Server für jede Antwort einen zufälligen 128-Bit-Wert generieren, eine Liste der ausgestellten Nonces führen und Nonces bei Verwendung aus dieser Liste entfernen.

Abgesehen von den oben genannten Einschränkungen bezüglich der in „badNonce"-Antworten ausgestellten Nonces schränkt ACME nicht ein, wie Server den Bereich von Nonces einschränken. Clients KÖNNEN (MAY) davon ausgehen, dass Nonces einen breiten Bereich haben, z. B. indem sie einen einzigen Nonce-Pool für alle Anforderungen verwenden. Bei der Wiederholung als Reaktion auf einen „badNonce"-Fehler MUSS (MUST) der Client jedoch die in der Fehlerantwort bereitgestellte Nonce verwenden. Server SOLLTEN den Bereich von Nonces so weit setzen, dass Wiederholungen selten erforderlich sind.

6.5.1. Replay-Nonce (Replay-Nonce-Headerfeld)

Das Replay-Nonce-HTTP-Headerfeld enthält einen vom Server generierten Wert, den der Server verwenden kann, um nicht autorisierte Wiederholungen in zukünftigen Client-Anforderungen zu erkennen. Der Server MUSS (MUST) die im Replay-Nonce-Headerfeld bereitgestellten Werte so generieren, dass sie für jede Nachricht mit hoher Wahrscheinlichkeit eindeutig und für jeden außer dem Server unvorhersehbar sind. Beispielsweise ist die zufällige Generierung von Replay-Nonces akzeptabel.

Der Wert des Replay-Nonce-Headerfelds MUSS (MUST) eine Oktettenfolge sein, die gemäß der in Abschnitt 2 von [RFC7515] beschriebenen base64url-Kodierung kodiert ist. Clients MÜSSEN (MUST) ungültige Replay-Nonce-Werte ignorieren. Die ABNF [RFC5234] für das Replay-Nonce-Headerfeld lautet:

base64url = ALPHA / DIGIT / "-" / "_"

Replay-Nonce = 1*base64url

Das Replay-Nonce-Headerfeld SOLLTE NICHT (SHOULD NOT) in HTTP-Anforderungsnachrichten enthalten sein.

6.5.2. "nonce" (Nonce) JWS Header Parameter ("nonce" (Nonce) JWS-Headerparameter)

Der „nonce"-Headerparameter stellt einen eindeutigen Wert bereit, der es dem Prüfer des JWS ermöglicht, zu erkennen, wann eine Wiederholung aufgetreten ist. Der „nonce"-Headerparameter MUSS (MUST) im Protected Header des JWS enthalten sein.

Der Wert des „nonce"-Headerparameters MUSS (MUST) eine Oktettenfolge sein, die gemäß der in Abschnitt 2 von [RFC7515] beschriebenen base64url-Kodierung kodiert ist. Wenn der Wert des „nonce"-Headerparameters gemäß dieser Kodierung ungültig ist, MUSS (MUST) der Prüfer das JWS als fehlerhaft ablehnen.

6.6. Rate Limits (Ratenbegrenzungen)

ACME-Server KÖNNEN (MAY) die Ressourcenerstellung ratenbegrenzen, um eine faire Nutzung zu gewährleisten und Missbrauch zu verhindern. Sobald eine Ratenbegrenzung überschritten wird, MUSS (MUST) der Server mit einem Fehler vom Typ „urn:ietf:params:acme:error:rateLimited" antworten. Darüber hinaus SOLLTE (SHOULD) der Server ein Retry-After-Headerfeld [RFC7231] senden, das angibt, wann die aktuelle Anforderung möglicherweise wieder erfolgreich sein wird. Wenn mehrere Ratenbegrenzungen vorhanden sind, ist dies der Zeitpunkt, zu dem alle Ratenbegrenzungen die aktuelle Anforderung mit genau denselben Parametern erneut zulassen würden.

Zusätzlich zum menschenlesbaren „detail"-Feld der Fehlerantwort KANN (MAY) der Server einen oder mehrere Links im Link-Headerfeld [RFC8288] senden, die den Linkrelationstyp „help" verwenden, um auf Dokumentation über die ausgelöste spezifische Ratenbegrenzung zu verweisen.

6.7. Errors (Fehler)

Fehler können auf der HTTP-Ebene und in Herausforderungsobjekten gemeldet werden, wie in Abschnitt 8 definiert. ACME-Server KÖNNEN (MAY) Antworten mit HTTP-Fehlerantwortcodes (4XX oder 5XX) zurückgeben. Wenn ein Client beispielsweise eine Anforderung mit einer in diesem Dokument nicht erlaubten Methode einreicht, KANN (MAY) der Server den Statuscode 405 (Method Not Allowed) zurückgeben.

Wenn der Server mit einem Fehlerstatus antwortet, SOLLTE (SHOULD) er zusätzliche Informationen über ein Problemdokument [RFC7807] bereitstellen. Um automatische Reaktionen auf Fehler zu erleichtern, definiert dieses Dokument die folgenden Standardtoken für das „type"-Feld (innerhalb des ACME-URN-Namensraums „urn:ietf:params:acme:error:"):

Typ	Beschreibung
accountDoesNotExist	Das in der Anforderung angegebene Konto existiert nicht
alreadyRevoked	Das in der Anforderung zum Widerruf angegebene Zertifikat wurde bereits widerrufen
badCSR	Der CSR ist nicht akzeptabel (z. B. wegen zu kurzem Schlüssel)
badNonce	Der Client hat eine nicht akzeptable Anti-Replay-Nonce gesendet
badPublicKey	Das JWS wurde mit einem öffentlichen Schlüssel signiert, den der Server nicht unterstützt
badRevocationReason	Der angegebene Widerrufsgrund ist vom Server nicht erlaubt
badSignatureAlgorithm	Das JWS wurde mit einem Algorithmus signiert, den der Server nicht unterstützt
caa	Ein Certification Authority Authorization (CAA)-Eintrag verbietet der CA die Ausstellung des Zertifikats
compound	Spezifische Fehlerbedingungen sind im „subproblems"-Array angegeben
connection	Der Server konnte keine Verbindung zum Validierungsziel herstellen
dns	Bei der DNS-Abfrage während der Identifikatorvalidierung ist ein Problem aufgetreten
externalAccountRequired	Die Anforderung muss einen Wert für das Feld „externalAccountBinding" enthalten
incorrectResponse	Die empfangene Antwort stimmt nicht mit den Anforderungen der Herausforderung überein
invalidContact	Die Kontakt-URL des Kontos ist ungültig
malformed	Die Anforderungsnachricht ist fehlerhaft
orderNotReady	Die Anforderung versucht, eine Bestellung abzuschließen, die noch nicht bereit ist
rateLimited	Die Anforderung überschreitet eine Ratenbegrenzung
rejectedIdentifier	Der Server stellt für diesen Identifikator kein Zertifikat aus
serverInternal	Der Server hat einen internen Fehler festgestellt
tls	Der Server hat während der Validierung einen TLS-Fehler erhalten
unauthorized	Dem Client fehlt die ausreichende Autorisierung
unsupportedContact	Die Kontakt-URL des Kontos verwendet ein nicht unterstütztes Protokollschema
unsupportedIdentifier	Der Identifikator ist ein nicht unterstützter Typ
userActionRequired	Besuchen Sie die „instance"-URL und führen Sie dort die angegebene Aktion durch

Diese Liste ist nicht erschöpfend. Server KÖNNEN (MAY) Fehler zurückgeben, deren „type"-Feld auf andere URIs als die oben definierten gesetzt ist. Server DÜRFEN NICHT (MUST NOT) den ACME-URN-Namensraum für Fehler verwenden, die nicht im entsprechenden IANA-Register aufgeführt sind (siehe Abschnitt 9.6). Clients SOLLTEN (SHOULD) das „detail"-Feld aller Fehler anzeigen.

Im Rest dieses Dokuments verwenden wir die Token aus der obigen Tabelle, um auf Fehlertypen zu verweisen, anstatt den vollständigen URN. Beispielsweise bezieht sich „ein Fehler vom Typ 'badCSR'" auf ein Fehlerdokument, dessen „type"-Wert „urn:ietf:params:acme:error:badCSR" ist.

6.7.1. Subproblems (Teilprobleme)

Manchmal muss eine CA auf eine Anforderung mit mehreren Fehlern antworten. Darüber hinaus muss eine CA möglicherweise Fehler bestimmten Identifikatoren zuordnen. Beispielsweise kann eine newOrder-Anforderung mehrere Identifikatoren enthalten, für die die CA keine Zertifikate ausstellen kann. In diesem Fall KANN (MAY) das ACME-Problemdokument ein „subproblems"-Feld enthalten, das ein JSON-Array von Problemdokumenten enthält, von denen jedes ein „identifier"-Feld enthalten KANN (MAY). Wenn vorhanden, MUSS (MUST) das „identifier"-Feld einen ACME-Identifikator enthalten (Abschnitt 9.7.7).

Das „identifier"-Feld DARF NICHT (MUST NOT) auf der obersten Ebene eines ACME-Problemdokuments erscheinen. Es darf nur in Teilproblemen erscheinen. Teilprobleme müssen nicht alle denselben Typ haben, und sie müssen nicht mit dem Typ der obersten Ebene übereinstimmen.

ACME-Clients KÖNNEN (MAY) das „identifier"-Feld eines Teilproblems als Hinweis verwenden, dass die Operation erfolgreich wäre, wenn dieser Identifikator weggelassen würde. Wenn eine Bestellung beispielsweise zehn DNS-Identifikatoren enthält und die newOrder-Anforderung ein Problemdokument mit zwei Teilproblemen zurückgibt (die auf zwei dieser Identifikatoren verweisen), KANN (MAY) der ACME-Client eine weitere Bestellung einreichen, die nur die acht Identifikatoren enthält, die nicht im Problemdokument aufgeführt sind.

HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
Link: `https://example.com/acme/directory`;rel="index"

{
    "type": "urn:ietf:params:acme:error:malformed",
    "detail": "Some of the identifiers requested were rejected",
    "subproblems": [
        {
            "type": "urn:ietf:params:acme:error:malformed",
            "detail": "Invalid underscore in DNS name \"_example.org\"",
            "identifier": {
                "type": "dns",
                "value": "_example.org"
            }
        },
        {
            "type": "urn:ietf:params:acme:error:rejectedIdentifier",
            "detail": "This CA will not issue for \"example.net\"",
            "identifier": {
                "type": "dns",
                "value": "example.net"
            }
        }
    ]
}

---