Letsencrypt auf Client hinter reverse Proxy von Diskstation

[luddi]

Hallo liebe Forum Gemeinde,

nun bräuchte ich eure Expertise.

Folgendes Scenario:
Ich habe im Netzwerk einen Client (Raspberry Pi) auf dem ein apache Webserver läuft.
Nun hoste ich auf diesem Webserver ein Verzeichnis welches über eine Subdomain erreichbar sein soll.

Da die Diskstation hier selbst schon einige Webserver Verzeichnisse mittels Vhost (auf Port 80/443) bereit stellt, blieb für das durchreichen zum Raspberry Pi die Möglichkeit mittels Reverse Proxy Konfiguration.

Dies läuft somit auch absolut sauber und die einzelnen Subdomains werden richtig zugeortnet.
subdomain-A.domain.tld --> landet auf der Diskstation
subdomain-B.domain.tld --> durch reverse Proxy auf dem Raspberry Pi.

Soweit so gut... Dies zeigt mir, dass die Umleitung für Anfragen auf subdomain-B.domain.tld sowohl über Port 80 als auch Port 443 (vorerst mittels self-signed cert) einwandfrei funktionert.

Jetzt mein Problem beim Erstellen eines Letsencrypt Zertifikats.
Wenn der Befehl vom Client (Raspberry Pi) abgesetzt wird...

certbot certonly --webroot -w /var/www/html/host-directory-subdomain-B -d subdomain-B.domain.tld

erhalte ich folgende Fehlermeldung:

Failed authorization procedure. subdomain-B.domain.tld (http-01): urn:ietf:params:acme:error:connection :: 
The server could not connect to the client to verify the domain :: 
Fetching http://subdomain-B.domain.tld/.well-known/acme-challenge/ARrKiwgDzFShkmbRZQufX6leSxuNTcIjRQ0s3CY7v74: 
Timeout during connect (likely firewall problem)

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: subdomain-B.domain.tld
   Type:   connection
   Detail: Fetching
   http://subdomain-B.domain.tld/.well-known/acme-challenge/ARrKiwgDzFShkmbRZQufX6leSxuNTcIjRQ0s3CY7v74:
   Timeout during connect (likely firewall problem)

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

Mögliche Fehlerquellen der Ausgabe:
a.) "...domain name was entered correctly..." --> JA
b.) "...DNS A/AAAA record(s) for that domain contain(s) the right IP address..." --> JA
c.) "...please check that your computer has a publicly routable IP address..." --> Hier habe ich meine Zweifel bezügl. dem reverse Proxy
d.) "...that no firewalls are preventing the server from communicating with the client..." --> Eine Firewall ist auf dem Raspberry Pi nicht aktiv. die iptables sind komplett leer.


Somit stellt sich die Frage, was muss beim Einrichten des Reverse Proxy auf der Diskstation beachtet werden, dass die Anfragen vom Client (Raspberry Pi) auch wieder richtig zugeordnet bzw. zurück geroutet werden.
Ich denke der Response auf den http-01 challenge request "http://subdomain-B.domain.tld/.well-known/acme-challenge" wird nicht korrekt zum Client (Raspberry Pi) geroutet.

Hat hier jemand Erfahrung wie ich auf einem Client (Raspberry Pi) der auf die gleichen Webserver Ports wie die Diskstation lauscht, die entsprechenden Responses durch den Reverse Proxy geroutet bekomme?

Schöne Grüße
luddi

 

[Fusion]

Wieso auf dem Raspi holen?
Die DS kann auch für die Reverse Proxies das Cert holen und die https Verbindung terminiert dann am Proxy.

 

[luddi]

Danke Fusion für deine schnelle Antwort.

Ja über diese Möglichkeit hatte ich selbst bereits nachgedacht. Ich wollte es aber eben über diese Methode lösen dass der Raspi die Certs selbst erstellt.

Nun habe ich mir das in der DSM Gui angeschaut und versucht ein LE-Cert zu erstellen.
Leider negativ...

Ich habe den Reverse Proxy wie folgt konfiguriert.



Anschließend der misslungene Versuch das Zertifikat zu erstellen.



Darf ich die Reverse Proxy Konfiguration erst nach dem Erstellen des Zertifikats einrichten?

--luddi

 

[Fusion]

Nein, vermute eher es liegt an den Einstellungen.
Probiers mal ohne den http proxy, also nur mit dem https reverse proxy. Vermute sonst hängt das irgendwo zwischen DS und Raspi fest.
Bei mir habe ich nur reverse proxies für 443 und da geht es, deshalb die Vermutung.

 

[luddi]

Gesagt getan...

Ich habe den http reverse entfernt und nochmals versucht das LE-Cert für sub-B.domain.tld zu erstellen. Jedoch wieder die gleiche Fehlermeldung und somit ohne Erfolg.
Was mich aber wundert, dass der DSM Cert-manager für einen https reverse proxy sofort das default Cert konfiguriert.



Und es gibt nicht einmal die Möglichkeit dieser domain sub-b das cert zu entziehen bzw. keines zuzuordnen.

--luddi

 

[Fusion]

Was wundert dich da, jedem neu angelegten Dienst wird erst mal das Standardzertifikat verpasst. Für alle existierenden Dienste für die noch keines explizit gesetzt war wird jenes des Dienstes "Systemvoreinstellung" genommen.

Aber komisch. Fällt mir grad auch nur trial & error ein.
Also alle proxies mal entfernen und nur den https nochmal anlegen ob es dann geht.
Oder alle löschen und probieren das Zertifikat mal ohne existierend Host-Definition auf der DS zu holen (nur zum Spaß, weil es muss mit funktionieren, sonst würde vermutlich auch die automatische Erneuerung fehlschlagen).

Aber ich habe heute auch aus dem blauen 2 Hostnames die sich mit dem Timeout Fehler in deinem ersten Post für den Erneuerungsversuch bedankt haben.
In dem Zertifikat war ein Hostnames und 2 Alternate Hostnames.
Einen davon wollte ich dann als einzelnes Zertifikat neu anlegen. Beim ersten Mal kam der Fehler, dass die Anzahl der Anträge für die Domain überschritten wäre.
Beim zweiten Versuch gerade derselbe wie bei dir zuletzt mit gültigem Domainname.
Nach Deaktivierung von HSTS konnte ich dann die Einzelversion doch anlegen.
Schon komisch, wenn es 1-2 Jahre funktioniert und dann mal nicht mehr.

 

[Fusion]

Anmerkung, bei allen gerade erwähnten ging es nach Deaktivierung von HSTS.
Muss ich wohl bei Gelegenheit die webserver config mal durchleuchten, ob da ne falsche Richtlinie oder Zeit etc. drin steht.

 

[luddi]

Was wundert dich da, jedem neu angelegten Dienst wird erst mal das Standardzertifikat verpasst. Für alle existierenden Dienste für die noch keines explizit gesetzt war wird jenes des Dienstes "Systemvoreinstellung" genommen.

Meine Verwunderung diesbezüglich aus folgendem Grund...
Ich glaube ich hatte von einem "reverse proxy" die falsche Vorstellung bzw. ein falsches Bild was er macht. Aber nach ein wenig weiterer Recherche bin ich nun vermutlich schlauer als vorher.
Es scheint so, als würde der Proxy immer sein Zertifikat nach außen präsentieren und nicht das vom backend server der über den reverse Eintrag erreichbar ist.
Folgende Information habe ich als Bestätigung diesbezüglich auch z.B. aus dieser Quelle im Nachhinein gefunden. Es beschreibt exakt das gleiche Thema wie ich es hier in diesem Forum angebracht habe.

Letsencrypt challenge with Reverse Proxy not working

[...]
When you are using a reverse proxy, you normally generate and install the certificate on the reverse proxy itself and not on the backend server.

That's why you need to generate the certificate from the Synology NAS, and assign it on the reverse proxy entry.

Weil eben der Reverse Proxy für das Zertifikat zuständig ist und nicht der Backend Server selbt (in meinem Fall der Raspi), erstellt die Diskstation auch für jeden reverse proxy Eintrag für https auch ein Eintrag in der Zertifikatsverwaltung und verwendet per default das Standard Zertifikat.

Somit verflüchtigt sich meine Verwunderung auch über das Verhalten der Diskstation und dessen Zertifikatsmanager in Kombination mit einem https reverse proxy Eintrag.
Ich ging davon aus, dass alle Requests von Außen, an den Backend Server geroutet werden wie es eine Firewall machen würde indem das Routing anhand von der Quelle gehandhabt wird.
Dies ist aber hier nicht der Fall, und es muss zwingend ein Zertifikat an der Diskstation erstellt werden weil die https Verbindung genau am Proxy terminiert wird.

Aber komisch. Fällt mir grad auch nur trial & error ein.

Das ist auch mein Gedanke. Alle anderen aktuell gültigen Zertifikate habe ich ja auch über die DSM GUI erstellt. Das einzige was mir zu meinem Problem einfällt ist, dass ich vermutlich schon zu viele Anfragen für meine Domain gestellt habe, sozusagen die Rate Limits der LE policies überschritten habe.

Ich werde das morgen nochmal in Ruhe für eine neue angelegte Subdomain probieren.

--luddi

 

[luddi]

Anmerkung, bei allen gerade erwähnten ging es nach Deaktivierung von HSTS.

Auch ein guter Hinweis. Bisher hatten bei mir alle Renewals aus der Kommandozeile per Skript tadellos funktioniert. Ich bin auf den nächsten Aktualisierungszeitpunkt gespannt ob sie weiterhin problemlos verlängert werden.

--luddi

 

[blurrrr]

Letzteres wird wohl gut möglich sein, wenn Du es sehr oft versucht hast. Grundsätzlich sind aber verschiedene Konstrukte möglich:

Server <----> Proxy <--SSL--> Internet
(so hat man "intern" nichts mehr mit SSL am Hut, sieht man aber ziemlich häufig)

Server <--SSL--> Proxy <--SSL--> Internet
(so wäre es natürlich am besten, interner Server und Proxy müssen sich dann aber auch entsprechend vertrauen (self-signed))

Server <----> Proxy <----> Internet
(sollte so nicht mehr betrieben werden)

Sinn und Zweck des Reverseproxy ist primär die Schutzfunktion, so dass nicht "direkt" mit dem dahinterliegenden Server agiert werden kann. Hat in diesem Sinne also auch nicht wirklich primär was mit vhosts und dergleichen zu tun, sondern es ist einfach ein System mehr dazwischen, welche seine zusätzliche Schutzfunktion bieten soll. Zudem können die meisten auch noch zusätzliche Einstellungen bereitstellen, um das System dahinter entsprechend zu schützen (URL-Harding, Cookie-Signing, usw.). Bei fortgeschrittenen gibt es dann auch noch weitere Schutzmaßnahmen gegen SQL-Injections und und und (die Liste ist ja quasi endlos ).

Je nach Einsatzzweck bietet es sich übrigens an, die maximale Anzahl an ALT-Names beim Zertifikat auszunutzen, so musst Du Dich nicht um zig Zertifikate kümmern, sondern vllt nur um 2-3. Vielleicht erleben wir ja auch noch irgendwann, dass die LE-Wildcard-Zertifkate automatisch verlängert werden können (da bin ich aber auch ehrlich gesagt nicht so auf dem neusten Stand), dann hätte sich das Problem ja quasi eh erledigt

 

[blinddark]

Ich erstelle und verlängere mein wildcard-Cert mittels acmev2. Das übernimmt bei mir der pi und schreibt diese auf ein via nfs angebundenes Verzeichnis. So muss ich es nur noch auf allen Geräten die es benötigen importieren. Das leider alle 90 Tage aber ein Skript für den Import habe ich noch nicht entdeckt. Ins Besondere für die Syno wär das interessant. ReverseProxy und clients kommunizieren meist auch via SSL mit einander. Auf der Syno ein Wildcard ohne Synology DNS habe ich noch nicht hinbekommen.

 

[luddi]

Hallo blurrrr,

danke auch für deine Unterstützung und das Teilen mit deinem Wissen.

Server <----> Proxy <--SSL--> Internet
(so hat man "intern" nichts mehr mit SSL am Hut, sieht man aber ziemlich häufig)

D.h. dieses Konstrukt ist das welches die Diskstation verwendet? Somit übernimmt der Proxy die Termininierung mit dem SSL Zertifikat.

Server <--SSL--> Proxy <--SSL--> Internet
(so wäre es natürlich am besten, interner Server und Proxy müssen sich dann aber auch entsprechend vertrauen (self-signed))

Ist dieses Konstrukt mit DSM Mitteln möglich? Es erscheint mir jedenfalls nicht so, dass man diese Kette Aufbauen könnte da ja einem reverse Proxy Eintrag sofort das Standardzertifikat zugeordnet wird.

Sinn und Zweck des Reverseproxy ist primär die Schutzfunktion, so dass nicht "direkt" mit dem dahinterliegenden Server agiert werden kann. Hat in diesem Sinne also auch nicht wirklich primär was mit vhosts und dergleichen zu tun, sondern es ist einfach ein System mehr dazwischen, welche seine zusätzliche Schutzfunktion bieten soll.

Das leuchtet mir nun ein und die Funktion als solche Schutzfunktion ist auch plausibel nachvollziehbar.

Jedoch stelle ich mir die Frage, weshalb ein http-01 challenge response nicht an dem Client ankommt welcher auch den Request abgesetzt hat der hinter einem Router mit NAT sitzt. Die Anfrage des challange Request bei LE welches vom Raspberry (der Client hinter dem reverse Proxy) aus gestartet wird, geht ja bei der Anfrage nicht über den Proxy. Somit sollte der Zugriff nach Außen (www) direkt über den Router erfolgen (ist auch so eingestellt dass das Gateway der Router ist). Somit kommuniziert der Raspberry Client hinter einer NAT Firewall mit dem Server von LE, und die NAT verpackt ja schließlich die Informationen der Hostquelle des LAN in die Kommunikationspakete damit die NAT wiederum weiß wem die Daten bei einem Response wieder zugeordnet werden sollen.

Außer ich habe ein falsches Bild vom Ablauf des Challenge Reqeusts, und der LE Server schickt ein unabhängiges Paket welches vom Requester (Client) beantwortet werden muss. Und genau das scheitert dann aus welchem Grund auch immer, obwohl ja eine Anfrage der Homepage von sub-B.domain.tld richtig dem Backend zugeordnet werden kann.

Ich werde zunächst weiterhin versuchen ein Zertifikat auf der Diskstation für den reverse Proxy Eintrag zu erstellen. Villeicht klappt es ja heute.

--luddi

 

[luddi]

Hallo blinddard,

Ich erstelle und verlängere mein wildcard-Cert mittels acmev2.

Wie lauten denn hier dei Befehle um mittels acmev2 ein Cert zu erstellen? Bzw. wo gibt es gute Referenzen hierzu? Die Dokumentation über LE ist in meinen Augen leider etwas dünn und man muss sich überall Teile an Informationen sammeln die dann das gesamte Puzzle ergeben.

So muss ich es nur noch auf allen Geräten die es benötigen importieren. Das leider alle 90 Tage aber ein Skript für den Import habe ich noch nicht entdeckt.

Nach was für eine Skript suchst du denn genau? Was soll es denn eigenltich können?
Es sollte doch nur prüfen ob neue Zertifikate auf dem NFS Share liegen und diese dann an die entsprechende stelle kopieren. Und vermutlich im Anschluss die Konfiguration des Webservers neu laden bzw. diesen neu starten.

Auf der Syno ein Wildcard ohne Synology DNS habe ich noch nicht hinbekommen.

Wildcards aus der DSM GUI sind meines Wissens noch nicht möglich. Ob dies in der nahen Zukunft kommen wird, bleibt abzuwarten.

--luddi

 

[Benares]

Bez. Wildcard-Zertifikat lies mal hier und folge dem Link in #10.

 

[luddi]

Wildcards aus der DSM GUI sind meines Wissens noch nicht möglich. Ob dies in der nahen Zukunft kommen wird, bleibt abzuwarten.

Hallo Zusammen.

Als hätte das Universum uns gehört!

Gerade entdeckt dass eine neue DSM 6.2.3 verfügbar ist.
Hier die Release Notes z.B. anhand meines Modells 1817+ Rlease Notes

Da steht folgendes:

What's New in DSM 6.2.3
11. Added support for Let's Encrypt wildcard certificates.

Falls interesse an einem sofortigen Update besteht findet ihr den Download entsprechend zu eurem Modell im Archiv:
DSM-release-6.2.3-25423

--luddi

 

[blinddark]

Zu meinen befehlen:
also zunächst musst du dir das acme.sh auf deinen pi laden:
auf dem pi anmelden
sudo su

apt-get install git socat

cd ~
git clone https://github.com/Neilpang/acme.sh.git
cd acme.sh
danach führst du folgendes aus um acme.sh zu installieren und aufrufbar zu machen:
acme.sh --install --home /opt/acme.sh --config-home /etc/acme.sh --accountemail "mail@hoster.de"
cd ..
rm -rf acme.sh
exit
sudo su
bei bedarf autoupdate deaktivieren:

acme.sh --upgrade --auto-upgrade 0

update des clients mit:
acme.sh --upgradenun kannst du ein Zertifikat erstellen:

acme.sh --issue --force --keylength 4096 --domain *.domain.de --domain domain.de --domain *.xxx.domain.de --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please --cert-file /media/nas/acme/domain.cert.pem --key-file /media/nas/acme/domain.key.pem --ca-file /media/nas/acme/domain.de.ca.pem --fullchain-file /media/nas/acme/domain.de.chain.pem

Nun musst du die DNS-Einträge mittels der txt-records validieren und danach diesen Befehl ausführen:
acme.sh --renew --force --keylength 4096 --domain *.domain.de --domain domain.de --domain *.xxx.domain.de --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please --cert-file /media/nas/acme/domain.cert.pem --key-file /media/nas/acme/domain.key.pem --ca-file /media/nas/acme/domain.de.ca.pem --fullchain-file /media/nas/acme/domain.de.chain.pem


Anschließend glaub ich noch den cron setzen mit:
acme.sh --cron --force --yes-I-know-dns-manual-mode-enough-go-ahead-please

Zu meinem Wunschskript ja es soll prüfen, ob irgendwo neue Zertifikate liegen und die aufs nas spielen.

 

[luddi]

Tausend Dank für das detailreiche "how to".

Das scheint ja wirklich kein großes Ding zu sein. Hier ist das schöne, dass die domain mittels txt record einmal validiert wird. Für ein update bzw. verlängerung ist eine erneute Validierung mittels TXT-Record hoffentlich nicht notwendig. Ist das korrekt? Muss ja so sein wenn du das auch per Cron erledigst...

Zu meinem Wunschskript ja es soll prüfen, ob irgendwo neue Zertifikate liegen und die aufs nas spielen.

D.h. es sollte doch nicht allzu schwierig sein das per Script zu realisieren, so jedenfalls mein Gefühl.
Die Zertifikate liegen doch immer an gleicher stelle auf deinem Raspberry? Auch nach einer Verlängerung behalten die Dateien vermutlich den gleichen Namen?
Deine Verlängerung der Certs ist doch bei dir automatisiert soweit ich das richtig verstanden habe oder (Cron)?
Erhalten die erneuerten Certs einen neuen Zeitstempel nach erfolgreicher Verlängerung? Zumindest wird sich der Hash/CSUM einer Datei ändern.

--luddi

 

[blinddark]

Bisher musste ich die txt-records noch nicht wieder anfassen.

ja der timestamp ändert sich hab es eben noch einmal getestet.

 

[luddi]

ja der timestamp ändert sich hab es eben noch einmal getestet.

Und vermutlich somit auch die Checksumme der Datei.

Du kannst ja einmal folgendes probieren...

openssl dgst -md5 $File | egrep -o [0-9a-zA-Z]{32}

Also sollte dies nun möglich sein ein kleines Script zu schreiben.
Gib mir noch einmal die Anahltspunkte im Detail.

a.) Du erneuerst die Zertifikate mit dem Raspberry Pi
b.) Wo liegen die Zertifikate? Werden sie direkt über die NFS Freigabe auf die Synology kopiert?

Oder wie genau ist deine Topologie, und wer soll das Script zur Überprüfung auf ein neues Zertifikat ausführen (Raspi oder Diskstation)?

Ich denke ich kann dir helfen ein Script auf bash zu erstellen wenn du möchtest.

--luddi

 

[blinddark]

Hi das mit dem skript wäre super.
1. der Raspberry erstellt und erneuert die Zertifikate.
2. die Zertifikate werden direkt in ein Verzeichnis auf der DS geschrieben.
3. Auch nach dem Erneuern erfolgt das Schreiben in das NFS-Verzeichnis welches sich auf der DS befindet.

Ich habe in zwischen mal auf meiner DS gekramt und meine genaueren Mitschriften zur Installation und Konfiguration für le-zertifikate via acme.sh gefunden. Diese möchte ich euch nicht vorenthalten. Da gibt es noch ein paar kleine Anpassungen zu dem schnell geschriebenen von vorhin:
############
##acme.sh installieren
#Voraussetzungen schaffen
sudo su
apt-get install git socat
#acme von github clonen
git clone https://github.com/Neilpang/acme.sh.git
#acme.sh installieren
cd acme.sh
./acme.sh --install --home /opt/acme.sh --config-home /etc/acme.sh --cert-home /media/nas/acme --accountemail "mail@domain.de"

#löschen der Installationsdateien
cd
rm -rf acme.sh/
#su erneut anmelden
exit
sudo su


##ecc


#test ecc (somit werden für die Tests und das Generieren der txt-records keine Zertifikatsanfragen verbraucht)
acme.sh --issue --test --keylength ec-384 --domain domain.de --domain *.domain.de --domain *.vpn.domain.de --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please --cert-file "/media/nas/acme/ecc/domain-cert.pem" --key-file "/media/nas/acme/ecc/domain-key.pem" --ca-file "/media/nas/acme/ecc/domain-de-ca.pem" --fullchain-file "/media/nas/acme/ecc/domain.de-chain.pem"

#generiere ecc (live)
acme.sh --issue --force --keylength ec-384 --domain domain.de --domain *.domain.de --domain *.vpn.domain.de --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please --cert-file "/media/nas/acme/ecc/domain-cert.pem" --key-file "/media/nas/acme/ecc/domain-key.pem" --ca-file "/media/nas/acme/ecc/domain-de-ca.pem" --fullchain-file "/media/nas/acme/ecc/domain.de-chain.pem"

#erneuern ecc
acme.sh --renew --keylength ec-384 --domain domain.de --domain *.domain.de --domain *.vpn.domain.de --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please --cert-file "/media/nas/acme/ecc/domain-cert.pem" --key-file "/media/nas/acme/ecc/domain-key.pem" --ca-file "/media/nas/acme/ecc/domain-de-ca.pem" --fullchain-file "/media/nas/acme/ecc/domain.de-chain.pem"


##rsa


#test rsa (somit werden für die Tests und das Generieren der txt-records keine Zertifikatsanfragen verbraucht)
acme.sh --issue --test --keylength 4096 --domain domain.de --domain *.domain.de --domain *.vpn.domain.de --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please --cert-file "/media/nas/acme/rsa/domain-cert.pem" --key-file "/media/nas/acme/rsa/domain-key.pem" --ca-file "/media/nas/acme/rsa/domain-de-ca.pem" --fullchain-file "/media/nas/acme/rsa/domain.de-chain.pem"

#generiere rsa (live)
acme.sh --issue --force --keylength 4096 --domain domain.de --domain *.domain.de --domain *.vpn.domain.de --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please --cert-file "/media/nas/acme/rsa/domain-cert.pem" --key-file "/media/nas/acme/rsa/domain-key.pem" --ca-file "/media/nas/acme/rsa/domain-de-ca.pem" --fullchain-file "/media/nas/acme/rsa/domain.de-chain.pem"


#erneuern rsa
acme.sh --renew --keylength 4096 --domain domain.de --domain *.domain.de --domain *.vpn.domain.de --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please --cert-file "/media/nas/acme/rsa/domain-cert.pem" --key-file "/media/nas/acme/rsa/domain-key.pem" --ca-file "/media/nas/acme/rsa/domain-de-ca.pem" --fullchain-file "/media/nas/acme/rsa/domain.de-chain.pem"

##sonstiges


#auflisten der zertifikate
acme.sh --list


#upgrade von acme.sh
acme.sh --upgrade


#Autoupgrade deaktivieren
acme.sh --upgrade --auto-upgrade 0


#Autoupgrade aktivieren
acme.sh --upgrade --auto-upgrade 1

#cron starten
acme.sh --cron --force --yes-I-know-dns-manual-mode-enough-go-ahead-please
######################

Hier ließen sich auch ecc-Zertifikate erzeugen, leider kann die DS damit noch nicht umgehen.