Summary

  • Die Fassung vom 27. Oktober des Entwurfs dns-account-01 befindet sich bis 10. November im IESG Last Call. Jedes ACME-Konto erhält einen eigenen DNS-Prüfnamen, sodass unabhängige Systeme dieselbe Domain über getrennte CNAMEs delegieren können.
  • Der Name entsteht aus den ersten zehn SHA-256-Bytes der Konto-URL in Base32. Ein Schlüsselwechsel erhält ihn; eine geänderte Konto-URL bei einem Serverumzug kann vorbereitete DNS-Einträge entwerten.

Der Engpass heißt _acme-challenge. Beim bestehenden dns-01 aus RFC 8555 sind mehrere TXT-Werte unter diesem Namen möglich. Zwei Teams können jedoch denselben Namen nicht per CNAME gleichzeitig an zwei verschiedene Challenge-Systeme delegieren. Für einen DNS-Namen gibt es nur ein CNAME-Ziel. Wer zwei unabhängige Zertifikatswege braucht, stößt damit auf eine gemeinsame Kontrollstelle.

Der IETF-Entwurf setzt vor _acme-challenge ein kontospezifisches Label. Dafür wird die vollständige ACME-Konto-URL mit SHA-256 gehasht; die ersten zehn Bytes werden als Base32 kodiert. Das veröffentlichte Beispiel lautet _ujmmovf2vn55tgye._acme-challenge.example.org. Jedes Konto kann nun seinen eigenen Namen per CNAME delegieren. Der Server folgt dem Verweis zum TXT-Eintrag und vergleicht dessen Wert mit dem Hash der Schlüsselautorisierung für die Challenge.

Abschnitt 3.5 legt den Preis offen: Schema, Host, Port und Pfad der URL beeinflussen das Label. Die Rotation des Kontoschlüssels lässt es bestehen. Ändert ein ACME-Dienst bei einem Umzug hingegen die Konto-URL, müssen zuvor eingerichtete Prüfnamen womöglich neu angelegt werden. Der Entwurf empfiehlt stabile Kennungen und die weitere Annahme alter kid-URLs bei nötigen Änderungen. Laut IETF-Datatracker steht Fassung 04 im Last Call; angestrebt ist ein Proposed Standard.

Eine öffentliche Übersicht der Implementierungen und ein dokumentierter Dienstumzug mit beibehaltenen Konto-URLs fehlen noch.