Wer kennt es nicht:
Ich habe die Domain example.com.
Marketing will die Domain fancy.example.com bei einer Agentur hosten, weil Marketing das eben kann.
Die Agentur ist natürlich auch nur Kunde bei einem der großen Cloud-Anbieter, und der möchte für fixe IP-Adressen mehr Geld als für nicht-fixe haben. Die Agentur umgeht das, indem sie uns bittet, fancy.example.com mit einem CNAME auf irgendwas beim Cloud-Anbieter zu versehen. Ist halt billiger.
Für example.com habe ich einen CAA-Record im DNS, in dem die CA, die die Agentur verwendet, nicht enthalten ist. Jetzt könnte ich natürlich diese CA in meinen CAA aufnehmen, aber dann hätte diese CA das Recht, für alles in example.com Zertifikate auszustellen. Nein, das will ich nicht.
Also soll die Agentur-CA nicht an example.com getackert werden, sondern an fancy.example.com. In bind etwa so:
fancy.example.com. CNAME host.bei.cloud-anbieter.
CAA 0 issue "pki.goog"
Das geht aber nicht, bind beschwert sich: “CNAME and other data”. Zu Recht, der RfC verbietet das: Wenn CNAME, dann kein CAA. Nun ist guter Rat teuer.
Doch dafür gibt es seit November 2023 einen RfC, der den HTTPS-Record einführt. Im bind steht dann:
fancy.example.com. HTTPS 0 host.bei.cloud-anbieter.
CAA 0 issue "pki.goog"
Das funktioniert dann, leider scheinbar nur in der Apple-Welt. Safari hat keine Probleme, Chrome und Mac finden fancy.example.com genausowenig wie curl.
Schade!