Lets Encrypt Wildcard Zertifikat (ACME v2)

[Benares]

Wie erstellt / 'verlängert' ihr eure Wildcardzertifikate?

Also ich mach's immer noch per acme.sh-Script bzw. einem anderen Script drumrum, so ~alle 3 Monate so halbmanuell, weil es für Strato wohl keine DNS-API gibt. D.h., Script aufrufen, TXT-Record bei Strato ändern, Script noch aufrufen, Zertifikat einspielen.
Heute habe ich das, nach deiner Meldung, auch mal wieder wiederholt. Das lief problemlos. Allerdings gab es da diesmal auch einige Retry-Meldungen im letzten Teil.

 

[geimist]

Danke fürs Testen - machst du also genauso.
Mal gucken, was die nächsten Tage bringen.

 

[geimist]

Mit dem Schalter --debug 2 konnte ich noch ein paar Infos herauskitzeln.

[Sun Oct 17 15:17:08 CEST 2021] Here is the curl dump log:
[Sun Oct 17 15:17:08 CEST 2021] == Info: Protocol " https" not supported or disabled in libcurl

Du nutzt acme.sh auf DSM7?
Keine Ahnung, warum hier das fehlende https von curl bemängelt wird.

 

[Ulfhednir]

Wie erstellt / 'verlängert' ihr eure Wildcardzertifikate?

Die Erstellung der Wildcard-Zertifikate läuft in meiner SWAG-Instanz und dank Netcup-DNS-Plugin vollkommen automatisch.

 

[Benares]

Du nutzt acme.sh auf DSM7?

Ja, ich nutze acme.sh unter DSM7.
Grad gestern hab ich auch mal Script erneuert (acme.sh --upgrade). Neu war danach, dass man vor einem --issue erst nochmal ein
./acme.sh --register-account -m admin@$DOMAIN
absetzen muss, um einen Account anzulegen.
Etwas blöd ist auch immer, dass nach einem DSM-Update immer auch das root-Homeverzeichnis leer ist und somit auch das ~/.acme.sh Verzeichnis weg ist. Aber mit einem erneuten --issue entsteht es ja neu. Oder ich müsste es halt sichern/wiederherstellen. Es einfach woanders hinzulegen ist mir noch nicht wirklich gelungen.

 

[geimist]

Um mein Problem zu umgehen, versuche ich gerade das Ganze über Docker einzurichten. Mal gucken, ob mir das gelingt.

Bzgl. des Homeverzeichnisses:
Bei mir funktionierte das die letzten anderthalb Jahre ganz gut mit diesen Parametern:

WORKPATH="/volume1/homes/<user>/.wildcardcert"
DOMAINLIST="-d *.domain1.com -d *.domain2.com -d domain1.com -d domain2.com"
ACCOUNTMAIL="mail@example.com"

# erstellen:
./acme.sh --force --issue --home "$WORKPATH" --config-home "$WORKPATH" --cert-home "$WORKPATH/LE_CERT-home" --accountemail "${ACCOUNTMAIL}" ${DOMAINLIST} --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please

# erneuern:
./acme.sh --log --force --home "$WORKPATH" --renew ${DOMAINLIST} --config-home "$WORKPATH" --cert-home "$WORKPATH/LE_CERT-home" --accountemail "${ACCOUNTMAIL}" --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please

 

[geimist]

Update:
In Docker läuft acme.sh korrekt durch. Es scheint also ein Problem mit der DSM curl Version zu geben.

 

[Benares]

Meinste? Dann lass uns mal die curl-Versionen vergleichen

root@DS415:~# curl --version
curl 7.75.0 (x86_64-pc-linux-gnu) libcurl/7.75.0 OpenSSL/1.1.1l zlib/1.2.11 c-ares/1.14.0 nghttp2/1.41.0
Release-Date: 2021-02-03
Protocols: http https
Features: alt-svc AsynchDNS Debug HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL TrackMemory UnixSockets

 

[geimist]

root@DS920:~# curl --version
curl 7.54.0 (x86_64-pc-linux-gnu) libcurl/7.54.0 OpenSSL/1.0.2u zlib/1.2.11 c-ares/1.12.0 libssh2/1.9.0 nghttp2/1.24.0
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS Debug TrackMemory IPv6 Largefile NTLM NTLM_WB SSL libz HTTP2 UnixSockets HTTPS-proxy

 

[Benares]

Die Version ist zwar etwas älter, aber https ist auch dabei - sogar noch einiges mehr. Und welche Version hast du in Docker?
Ich glaub, ehrlich gesagt, nicht, dass es daran liegt.

 

[geimist]

Und welche Version hast du in Docker?

root@DS920:~# docker run --rm neilpang/acme.sh curl --version
curl 7.79.1 (x86_64-alpine-linux-musl) libcurl/7.79.1 OpenSSL/1.1.1l zlib/1.2.11 nghttp2/1.41.0
Release-Date: 2021-09-22
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL TLS-SRP UnixSockets

Prinzipiell verwundert mich das auch. Aber die Meldung von acme.sh sprach ja irgendwie für sich.
[Sun Oct 17 15:17:08 CEST 2021] == Info: Protocol " https" not supported or disabled in libcurl

Mir ist es aber inzwischen auch egal. Mit Docker läuft es ja erstmal wieder ?

 

[NSFH]

Habe das hier im Web gefunden um wildcards von LE nach der Vorbereitung automatisiert über den Aufgabenplaner aktualisieren zu können.
Vielleicht für den ein oder anderen interessant.

1. Installing acme.sh
Open SSH client's terminal, go to any folder with write access permissions (e.g. /tmp or ~ folder), download and install acme.sh:

git clone https://github.com/acmesh-official/acme.sh.git
cd ./acme.sh
./acme.sh --install \
--home /usr/local/acme.sh \
--cert-home /usr/local/acme.sh/certs \
--config-home /usr/local/acme.sh/data \
--accountemail "email@example.com" \
--force # use it with elevation (sudo) for all commands
After successful installation remove the downloaded folder and restart the terminal in order to apply changes to the ACME-client settings (environment variables):

cd ..
rmdir acme.sh

2. Issuing cert

acme.sh supports several ways of domain approving (you can find all in acme.sh documentation).

For now the hook (dns_synology_dsm) is in development state and you can find it here only: https://github.com/arabezar/acme.sh/blob/dev/dnsapi/dns_synology_dsm.sh

It's a good idea first trying to issue cert using test server (with debug log):

/usr/local/acme.sh/acme.sh --staging --debug 2 --issue --dns dns_synology_dsm -d example.com -d *.example.com --log
After successful issuing cert on staging server you can issue the real one:

/usr/local/acme.sh/acme.sh --issue --dns dns_synology_dsm -d example.com -d *.example.com --log
*) use --force when using elevation (sudo)



3. Updating cert

Updating can be realized using daily task.
Go to Control Panel -> Task Scheduler and add the new task with the name 'Lets Encrypt Update Cert' (run as root):

export LE_WORKING_DIR="/usr/local/acme.sh"
export LE_CONFIG_HOME="/usr/local/acme.sh/data"
/usr/local/acme.sh/acme.sh --config-home /usr/local/acme.sh/data --renew-all


4. Deploying cert

And at last the cert should be deployed to all modules. This can be done by adding another periodical task (e.g. monthly).
Go to Control Panel -> Task Scheduler and add the new task with the name 'Lets Encrypt Deploy Cert' (run as root):

export LE_WORKING_DIR="/usr/local/acme.sh"
export LE_CONFIG_HOME="/usr/local/acme.sh/data"
export SYNO_Create=1 # Create cert if not exists yet
export SYNO_Certificate="example.com" # Description text in Control Panel -> Security -> Certificates
/usr/local/acme.sh/acme.sh --config-home /usr/local/acme.sh/data --deploy -d example.com --deploy-hook synology_dsm

 

[nk111]

FYI: Ich nutze auch acme.sh für ein Wildcard Zertifikat unter DSM 7 als scheduled task. Ich nutze dabei die DNS-API von Checkdomain.de für die ich mir einen entsprechenden Provider für acme geschrieben habe.

Im Prinzip beruht das ganze auf dieser Anleitung:
https://lippertmarkus.com/2020/03/14/synology-le-dns-auto-renew/

Das einzige Problem an der Sache ist, dass nach einer gewissen Zeit der Login Token (Cookie) für meinen extra eingerichteten Admin User abläuft. Den brauche ich wegen 2FA. Dann kann das Skript leider das neue Zertifikat nicht mehr deployen und ich muss mich händisch einmal mit dem Zertifikatsuser einloggen um den Cookie neu auszulesen und das Skript manuell anstoßen.

 

[Fusion]

Das DID Problem für das deploy habe ich auch. Zwar andere DNS Anbieter für eine Alias Domain, aber... Das funktioniert alles wie ein Uhrwerk, nur auto-deploy eben nicht. Mir ist noch keine Lösung über den Weg gelaufen.

 

[geimist]

Ich habe wieder mal ein Problem beim Erneuern. Ich muss ja die Records manuell setzen - macht aber nichts. Also den 1. Durchlauf starten und mir die TXT-Records generieren lassen und brav im DNS hinterlegen. Der 2. Durchlauf läuft erfolgreich durch und die Zertifikate liegen im Zielordner (mit aktuellem Zeitstempel). Aber wenn ich mir mit openssl x509 -noout -text -in cert_path das Ablaufdatum anzeigen lasse, so entspricht das dem alten Zertifikat.

Könnt ihr euch da einen Reim drauf machen?

 

[Benares]

Sowas hatte ich auch schon mal. Alles lief wie immer durch, die Zertifikatsdateien hatten auch ein neues Datum, aber das Ablaufdatum war das alte - mehrfach probiert.
Ich hab dann einfach ein neues Zertifikat erstellt.

 

[geimist]

So hab ich es auch gemacht.

 

[speedyhome]

hab mir dafür selbst ein script gemacht alle 7 tage vor ablauf hab ich ein neues Zertifikat
mit richtigem Datum in diesem Post beschrieben
Beruht auch auf das acme.sh script nur alles vohrer manuel gemacht bis zum auto renew

 

[speedyhome]

Nachtrag zu meinem Post
nach dem renew der Zertifikate wurde im DSM zwar das neue angezeigt aber nicht im Browser übernommen
systemctl reload nginx brachte nix und restart hatte docker und vmm mit gekillt. also weiter gesucht und
gefunden
synow3tool --gen-all && systemctl reload nginx
synosystemctl restart pkgctl-WebStation.service

mit diesen wird auch das Zertifikat im browser selbst auktualisiert ohne das alles andere gekillt wird

 

[geimist]

Wen es interessiert: Für Selfhost scheint inzwischen eine DNS-API in acme.sh integriert worden zu sein. Getestet habe ich es noch nicht.
https://github.com/acmesh-official/acme.sh/pull/3873