Zertifikate via DNS-API für Subdomains klappt nicht

  • Hallo,


    scheitere gerade daran für Subdomains Zertifikate auszustellen, der API-Zugriff scheint aber korrekt konfiguriert zu sein, da ein Versuch nur mit der Hauptdomain erfolgreich war.


    Ziel ist es einen ejabberd-Server auf meinem Kubernetes-Cluster zu Hause zur Verfügung zu stellen.


    Folgende DNS-Einstellungen habe ich vorgenommen:

    xmpp A 83.142.91.142 # zeigt auf meine IP zuhause
    conference CNAME xmpp.meinedomain.de
    proxy CNAME xmpp.meinedomain.de
    pubsub CNAME xmpp.meinedomain.de
    upload CNAME xmpp.meinedomain.de
    _stun._tcp
    SRV 10 5 3478 xmpp.meinedomain.de
    _stun._udp
    SRV 10 5 3478 xmpp.meinedomain.de
    _stuns._tcp
    SRV 10 5 5349 xmpp.meinedomain.de

    _xmpp-client._tcp
    SRV 10 5 5222 xmpp.meinedomain.de

    _xmpp-server._tcp
    SRV 10 5 5269 xmpp.meinedomain.de

    _xmpps-client._tcp
    SRV 10 5 443 xmpp.meinedomain.de



    Hier noch ein paar Konfis und Logs:


    ingress.yml

    kubectl -n ejabberd-ns events --watch

  • 2ter Post da ich wg. Zeichenbegrenzung aufteilen musste



    kubectl -n ejabberd-ns describe orders.acme.cert-manager.io ejabberd-meinedomain-tls-1-769472745

    kubectl -n ejabberd-ns describe secrets ejabberd-meinedomain-tls-rn4v9

    Sollte ich noch etwas schuldig geblieben sein bitte einfach Bescheid geben... werde natürlich versuchen alles notwendige zur Problemlösung zur Verfügung zu stellen

  • Womit beantragst du die Zertifikate?


    Wichtig ist, dass die DNS Zonen bei Netcup nur alle 10 Minuten refreshen. In den gängigen LE Clients wie certbot, acme etc lässt sich eine Waittime einstellen. 600 Sekunden ist hier ein guter Wert.

  • Womit beantragst du die Zertifikate?

    Steht schon da: Cert-Manager.io, "Cloud native certificate management"... Einfach war gestern.


    Laut Log hat die DNS-Verifizierung geklappt:

    Code
    0s                      Normal    Presented            Challenge/ejabberd-meinedomain-tls-1-769472745-2580783813   Presented challenge using DNS-01 challenge mechanism
    0s                      Normal    DomainVerified       Challenge/ejabberd-meinedomain-tls-1-995231938-3514114516   Domain "meinedomain.de" verified with "DNS-01" validation
  • NaN

    Quote

    Domain "meinedomain.de" verified with "DNS-01" validation

    da ein Versuch nur mit der Hauptdomain erfolgreich war.


    Ich habe das so interpretiert, dass das der erfolgreiche Versuch mit der Hauptdomain war. Mit Glück schafft man es auch kürzerer Waittime, wenn man sehr nah am Netcup DNS Refresh-Zeitpunkt ist.


    Mir war jedenfalls in den Auszügen nicht ersichtlich, ob eine Waittime hinterlegt wurde, daher die Erwähnung.

    Ursache kann natürlich auch was ganz anderes sein. Für mich aber bisher nicht ersichtlich.

  • Ich hatte das ejabberd-meinedomain-tls in der Zeile so interpretiert, dass es schon um die Subdomain ging, aber das war verkehrt. Das ist der Name der Instanz. Wie auch immer, die DNS-API tut's und der Fehler liegt wohl in der Konfiguration dieses Kubernetes Monsters, das eine handvoll Web Requests alle drei Monate erledigen soll. Bin raus. Wo ist der Kopfschüttelsmiley wenn man ihn braucht?

  • Erstmal danke für die schnellen Antworten.


    Die ganzen Konfigs und Logs sind vom Versuch mit den Subdomains, wobei man da auch sieht das es mit der Hauptdomain scheinbar funktioniert und es "nur" an den Subdomains hängt das das Secret( ejabberd-meinedomain-tls) nicht erstellt wird.


    Würde es wenn es an der Waittime liegt dann nicht auch die Hauptdomain scheitern?


    Übrigens verwende ich diesen Webhook-HelmChart https://aellwein.github.io/cer…er-webhook-netcup/charts/ von aellwein


    Edit: Ihr postet so schnell da komm ich garnicht mit

  • Ich denke mal, dass die CNAMEs das Problem sein werden.

    Die sollten kein Problem sein.

    sub CNAME someothersub.example.com

    _acme-challenge.sub TXT challengetxt

    ist eine valide Konfiguration und lässt sich bei Netcup auch so setzen.

  • Ich denke mal, dass die CNAMEs das Problem sein werden.


    Ersetze die mal durch die richtigen A und AAAA Records, dann müsste das eigentlich klappen.

    Das scheint es wirklich gewesen zu sein. Werde das noch beobachten.


    Danke dir H6G


    Wie auch immer, die DNS-API tut's und der Fehler liegt wohl in der Konfiguration dieses Kubernetes Monsters, das eine handvoll Web Requests alle drei Monate erledigen soll. Bin raus. Wo ist der Kopfschüttelsmiley wenn man ihn braucht?

    Natürlich läuft mein Kubernetes-Cluster nur um Zertifikate auszustellen. :P

  • Sei mir nicht böse, aber du hast ein System aufgesetzt, das ein eigentlich triviales Protokoll, das wirklich nur aus einer handvoll GET-Requests besteht, so undurchsichtig gemacht hat, dass du nicht mal weißt, wo du nachgucken sollst, wenn es nicht funktioniert. Die scheinbare Lösung besteht dann darin, etwas nicht zu tun, was eigentlich keinen Einfluss haben sollte, und du weißt nicht, warum es damit trotzdem nicht geht. Also findest du dich damit ab, dass deine Konfiguration noch komplizierter sein muss, um einen für dich nicht zu findenden Fehler zu umgehen.


    Ich finde diesen 10 Jahre alten Talk immer noch herausragend: The Website Obesity Crisis. Der Abschnitt, auf den ich gerne hinweisen möchte, dreht sich um das Backend.

  • Bin raus.

    Ahja.


    Wie auch immer, die DNS-API tut's und der Fehler liegt wohl in der Konfiguration dieses Kubernetes Monsters, das eine handvoll Web Requests alle drei Monate erledigen soll.

    Scheinbar ja nicht. DNS, Netcups Implementierung von DNS und die DNS API sind allesamt ebenfalls komplex, vorallem wenn man viele Subdomains in einem Zertifikat absichern will. Das hat beim besten Willen nix mit Kubernetes und QpUQMFC9H7 s Entscheidung jenes einzusetzen zu tun.


    Im Gegenteil: QpUQMFC9H7 hat aufgelistet was das Problem ist, es gab genügend Infos im Thread und er hat probiert das Problem eigenständig zu lösen, durch eine Gegenprobe ohne Subdomain. Als er dann nicht mehr weiter wusste, hat er sich Hilfe hier im Forum gesucht. Jeder stößt einmal an seine Grenzen, sei es, weil nicht mehr Kenntnisse vorhanden sind, oder weil man den Wald vor lauter Bäumen nicht mehr sieht.


    Man kommt nicht einfach so auf die Idee, Jabber auf nem K8S auszurollen. Da wird QpUQMFC9H7 schon seine Gründe für haben und sich das sorgsam überlegt haben. Und wenn der Grund auch einfach nur: er will lernen wie man Jabber auf K8S betreibt ist. Lebenslanges lernen und so.


    Fazit: es war für uns alle ein langer Tag.

  • Habt ihr den Fehler privat gefunden? Hier im Forum ist davon ja nichts zu sehen.


    DNS, Netcups Implementierung von DNS und die DNS API sind allesamt ebenfalls komplex, vorallem wenn man viele Subdomains in einem Zertifikat absichern will.

    Geht mit einem Shellskript, aber das ist natürlich nicht web scale und cloud native. :rolleyes:

    Edited 3 times, last by NaN ().