[acme.sh] Fehlermeldung - Selbes Zertifikat mit anderem User erstellen?

[Benares]

Der Registrar/Vertragspartner bleibt weiterhin Netcup? Nur der Nameserver wandert zu Cloudfare?

Bei Netcup hat man NC_Apikey, NC_Apipw und NC_CID, die man hinterlegen muss, bei Cloudfare wohl nur ein CF_Token.

 

[*kw*]

Vielleicht mach das irgendwann mal. Aber ich möchte das jetzt nich unnötig verkomplizieren.

Dito. Bin froh, dass die Chose wieder läuft.

 

[alexhell]

@Benares genau so

 

[*kw*]

@alexhell: bisher ging das mit LE über ein Jahr problemlos und ich bin ja froh, die Ursache für mein eigenes Unvermögen erkannt zu haben.

Von daher bin ich froh, hier Tag für Tag die Schrittgeschwindigkeit langsam erhöhen zu können. Aber im Moment lehne ich mich dankbar erstmal zurück.

 

[*kw*]

Vollständigkeitshalber habe ich bezüglich der deploy-Fehlermeldung mal in der netcup-Community nachgefragt.

Mit dem Befehl dig +short -t TXT _acme-challenge.meinedomain.de wurden mir als Antwort alle vier aktuellen DNSSEC-Einträge (als gültig) angezeigt

Als Hinweis bekam ich noch:

Wenn lediglich das Entfernen des DNS-TXT-Eintrags aufgrund der nicht korrekt übergebenen Session-ID im letzten Schritt fehlschlägt, dürften die Auswirkungen ggf. erst zu spüren sein, wenn der verbliebene Identifikationseintrag beim Ausstellen des nächsten Zertifikats "im Weg steht", weil er zu diesem Zeitpunkt veraltet ist.

 

[Benares]

Ist ja klar, ein _acme-challenge.example.com-TXT-Record wird ja für example.com und *example.com gesetzt, geprüft, und hinter wieder entfernt.
Wenn da aus irgendwelchen Gründen Leichen bleiben, klappt es beim nächsten Mal nicht mehr.
Also alle _acme-challenge.example.com-Records entfernen, dann erst weiter probieren.

 

[*kw*]

Danke für die Rückmeldung. Ich frage mich nur, weshalb ich jetzt vier _acme-challenge Einträge im DNSSEC habe? Ich wollte künftig das beschriebene, mögliche Fehlverhalten vermeiden.

Kann ich das Gegentesten? Ist da irgendein "Durcheinander" entstanden? Sollte ich bei der nächsten gescheiterten Aktualisierung die TXT-Records löschen und auch einen neuen API-key samt Passwort erzeugen und nochmal neu deployen? Oder hat letzteres nichts unmittelbares miteinander zu tun? API-key gilt ja für alle meine Domains.

 

[plang.pl]

Ich würd einfach die DNS-Einträge manuell löschen und dann beim nächsten mal kucken, ob es wieder passiert. Du kannst ja auch testweise mit "--force" eine Erneuerung erzwingen. Aber ACHTUNG: Man munkelt, dass manche hier schon wegen zu vielen Versuchen bei Let's Encrypt gesperrt wurden

 

[plang.pl]

klappt es beim nächsten Mal nicht mehr.

Sicher? Wird dann ich über den API-Key der bestehende Eintrag einfach überschrieben / aktualisiert?

 

[Benares]

s.o. Hau den _acme-challenge-Rotz einfach weg. Das sind Leichen.
Das Setzen ist eine Sache, das überprüfen und löschen eine andere. Mehr als 2 (für example.com, *.example.com) sollten da nie sein. Und die sollten auch ja, nach jedem Lauf, wieder weg sein.

 

[*kw*]

@Benares: Lach, ich habe jetzt mal ganz mutig in der Zwischenzeit die vier Einträge gelöscht und mit --force ein Renew erzwungen. Super durchgeflutscht.

Einziger Hinweis: SYNO_TOTP_SECRET - depreciated

Was ist bei 2FA der alternative Tag? Ansonsten schau ich mal direkt auf github.

 

[Benares]

Was ist bei 2FA der alternative Tag?

Keine Ahnung, sorry.

 

[plang.pl]

Das soll wohl jetzt irgendwie über nen Cookie laufen, der da mitgegeben werden will: https://github.com/acmesh-official/acme.sh/wiki/Synology-NAS-Guide
Aber so recht blick ichs auch nicht. Wenn man ganz sicher gehen will, würd ichs eher so machen: Einen Admin-User ohne 2 FA anlegen und den per IP-Beschränkung nur vom localhost aus anmelden lassen.

 

[*kw*]

So hatte ich es auch vorher (ohne 2FA). Danke!

 

[*kw*]

Vollständigkeitshalber, außer den DNS API Werten des Anbieters soll die account.conf wohl so gestaltet werden:

export SYNO_Username=<insert username>
export SYNO_Password=<insert password>
export SYNO_Scheme=https
export SYNO_Port=443 <by default, this is set to 5001 which may cover the majority of installs>
export SYNO_Hostname=<insert FQDN>
export SYNO_Certificate="<insert optional description of certificate"
export SYNO_Create=1
acme.sh --deploy --insecure -d <insert FQDN> --deploy-hook synology_dsm

Daraus werde ich nur nicht ganz schlau (oder so banal?) insert optional description of certificate

 

[plang.pl]

Das ist nur die Beschreibung, die im DSM angezeigt wird für das Cert.

 

[Benares]

Daraus werde ich nur nicht ganz schlau (oder so banal?) insert optional description of certificate

Darin definierst die Beschreibung des Zertifikats, was beim Deploy im Ziel aktualisiert werden soll. Es könnte ja am Ziel mehrere geben.

 

[*kw*]

Ohkäh, Ei häff sis underständ nau werrili well.

 

[Benares]

Again what learned
Ich lerne auch noch jeden Tag etwas dazu und freue mich darüber.

 

[*kw*]

Erst haben wir @FleischFlori verarztet, jetzt klinke ich mich nochmal mit ein paar erweiterten Infos ein.

Um die bisherigen Problemen zu umgehen, hatte ich für das kommende Ablaufdatum bereits einen neuen User (ohne 2FA) angelegt und einen neuen API_key samt Passwort erstellt (wegen Dabbischkeit) und jetzt getestet.

Beim deployen kam eine Fehlermeldung und im debug-Modus konnte ich erkennen, dass die TXT-records nicht an netcup übertragen werden konnten (zwei Einträge domain/wildcard). Jetzt habe ich auch den Zusammenhang verstanden, in welcher Richtung die records normalerweise ins DNSSEC kommen (besser spät als nie ).

Problem: angeblicher Fehler im API_key Feld, TXT record konnte nicht übertragen werden, obwohl alle Daten definitiv stimmen. Ich hätte schon fast wieder in die Tischkante gebissen, als ich schlussendlich nochmal acme.sh neu installiert habe.

Und sieh da, dort lag der Fehler. Mit der frischen Version klappt es jetzt (reproduzierbar!).

Zertifikat fehlerfrei erstellt!

Mein Problem jetzt: der deploy-hook zur DSM. Mit dem Befehl acme.sh --deploy --deploy-hook synology_dsm -d domain.de fängt die Meckerei wegen User-Daten und TOTP an.

Da acme.sh bei "Ungereimtheiten" immer wieder auf die account.conf zurückgreift, habe ich diverse Kombination der deployhooks ausprobiert. Sind die Werte erfüllt, um 2FA zu umgehen, meckert er wegen TOTP. 2FA ist defnitiv off.

Mit der nachfolgenden account.conf hat das deployen geklappt, auch der renew-Befehl (zur Info, nicht --force) funktioniert, nur nicht hook zur DSM.

export NC_Apikey="KEY"
export NC_Apipw="PW"
export NC_CID="ID"
export SYNO_Username="DS_USERNAME"
export SYNO_Password="DS_PW"

Infos

By default, Synology requires 2-factor authentication via TOTP (Time-based One Time Password) for each user upon API-based access to any recent DSM version.
...
acme.sh continues to work with such a risky workaround (until Synology ultimately pulls the plug on that)

PS: da das neue Zertifikat auf der DS liegt, habe ich es jetzt vorerst händisch eingefügt.