{"id":2590,"date":"2020-10-26T07:00:00","date_gmt":"2020-10-26T05:00:00","guid":{"rendered":"https:\/\/www.my-it-brain.de\/wordpress\/?p=2590"},"modified":"2020-10-23T21:25:33","modified_gmt":"2020-10-23T19:25:33","slug":"lets-encrypt-nutzung-des-dns-alias-modus-mit-dem-acme-sh-client","status":"publish","type":"post","link":"https:\/\/www.my-it-brain.de\/wordpress\/lets-encrypt-nutzung-des-dns-alias-modus-mit-dem-acme-sh-client\/","title":{"rendered":"Let&#8217;s Encrypt: Nutzung des DNS-Alias-Modus mit dem acme.sh-Client"},"content":{"rendered":"\n<p>Dieses Tutorial erkl\u00e4rt, wie der <a rel=\"noreferrer noopener\" href=\"https:\/\/letsencrypt.org\/de\/\" target=\"_blank\">Let&#8217;s Encrypt<\/a> Client (LE-Client) <a rel=\"noreferrer noopener\" href=\"https:\/\/github.com\/acmesh-official\/acme.sh\" target=\"_blank\">acme.sh<\/a> mit dem Plugin <code>dns_nsupdate<\/code> auf einem Linux-System installiert und zur Nutzung der <a rel=\"noreferrer noopener\" href=\"https:\/\/letsencrypt.org\/de\/docs\/challenge-types\/#dns-01-challenge\" target=\"_blank\">&#8222;DNS-01 challenge&#8220;<\/a> im <a rel=\"noreferrer noopener\" href=\"https:\/\/github.com\/acmesh-official\/acme.sh\/wiki\/DNS-alias-mode\" target=\"_blank\">DNS-Alias-Modus<\/a> konfiguriert werden kann.<\/p>\n\n\n\n<p>Um dem Tutorial folgen zu k\u00f6nnen, sollte man den grundlegenden Umgang mit einem Terminal und einer weitgehend POSIX-kompatiblen Shell beherrschen. Grundlegende Kenntnisse der Funktion von <a rel=\"noreferrer noopener\" href=\"https:\/\/de.wikipedia.org\/wiki\/Domain_Name_System\" target=\"_blank\">DNS<\/a> und <a rel=\"noreferrer noopener\" href=\"https:\/\/de.wikipedia.org\/wiki\/Resource_Record\" target=\"_blank\">Resource Records<\/a> sind hilfreich, jedoch nicht erforderlich und k\u00f6nnen im Zweifel unter den verlinkten Seiten erworben werden.<\/p>\n\n\n\n<p>In diesem Tutorial werden <strong>nicht<\/strong> die Vor- und Nachteile der <a rel=\"noreferrer noopener\" href=\"https:\/\/letsencrypt.org\/de\/docs\/challenge-types\/#dns-01-challenge\" target=\"_blank\">&#8222;DNS-01 challenge&#8220;<\/a> diskutiert. Diese k\u00f6nnen unter vorstehendem Link nachgelesen werden.<\/p>\n\n\n\n<p>Die Begriffe SSL-Zertifikat, TLS-Zertifikat oder nur Zertifikat werden in diesem Tutorial synonym verwendet. Der zum Zertifikat geh\u00f6rende Schl\u00fcssel wird als Private-Key bezeichnet.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"umfeld\">Umfeld<\/h2>\n\n\n\n<p>Im Folgenden werden die Begriffe <a rel=\"noreferrer noopener\" href=\"https:\/\/de.wikipedia.org\/wiki\/Domain_(Internet)#Subdomain\" target=\"_blank\">Subdomain<\/a> und <a rel=\"noreferrer noopener\" href=\"https:\/\/de.wikipedia.org\/wiki\/Zone_(DNS)\" target=\"_blank\">Zone<\/a> synonym verwendet. Es sei darauf hingewiesen, dass diese Begriffe in einem anderen Kontext eine unterschiedliche Bedeutung haben k\u00f6nnen.<\/p>\n\n\n\n<p>Als Beispiel-Domain wird <strong>example.org<\/strong> mit den beiden Subdomains <strong>foo.example.org <\/strong>und <strong>bar.example.org<\/strong> verwendet. Um dem acme.sh-Client keinen direkten Zugriff auf diese DNS-Zonen geben zu m\u00fcssen, hat der DNS-Anbieter die DNS-Zone <strong>acme.foo.example.org<\/strong> definiert, welche f\u00fcr den Zweck der DNS-Challenge verwendet wird.<\/p>\n\n\n\n<p>Der Nameserver f\u00fcr alle in diesem Tutorial verwendeten Domains lautet <strong>ns.example.org<\/strong>.<\/p>\n\n\n\n<p>Vom DNS-Anbieter wird ein sogenannter <a rel=\"noreferrer noopener\" href=\"https:\/\/de.wikipedia.org\/wiki\/TSIG\" target=\"_blank\">TSIG-Schl\u00fcssel<\/a> bereitgestellt, welcher berechtigt ist <a rel=\"noreferrer noopener\" href=\"https:\/\/de.wikipedia.org\/wiki\/TXT_Resource_Record\" target=\"_blank\">TXT-Ressource-Records<\/a> in der oben genannten DNS-Zone <strong>acme.foo.example.org<\/strong> anlegen zu k\u00f6nnen. In diesem Tutorial werden folgender Name und Wert f\u00fcr einen TSIG-Schl\u00fcssel angenommen:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>TSIG-NAME: acme-key<\/li><li>TSIG-WERT: SuperGeheim1111elf==<\/li><li>TSIG-Algorithmus: hmac-sha512<\/li><\/ul>\n\n\n\n<p>Das Ziel soll nun sein, ein Zertifikat ausgestellt zu bekommen, welches f\u00fcr die beiden folgenden Hostnamen g\u00fcltig ist:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>host.foo.example.org<\/li><li>mein-schoener-host.bar.example.org<\/li><\/ul>\n\n\n\n<p>In diesem Tutorial wird als Webserver Apache in der Distribution RHEL 7 verwendet. Die entsprechende Service-Unit lautet demnach <em>httpd.service<\/em>. Wird ein anderer Webserver oder eine andere Distribution verwendet, ist der Name der Service-Unit entsprechend anzupassen (z.B. <em>nginx.service<\/em>).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Sinn und Zweck des DNS-Alias-Modus<\/h2>\n\n\n\n<p>Der DNS-Alias-Modus kann verwendet werden, wenn man einem Programm wie dem acme.sh-Client keinen direkten API-Zugriff auf die DNS-Zonen der eigenen Domain geben m\u00f6chte. In diesem Abschnitt werde ich beispielhaft erkl\u00e4ren, warum eine Nutzung dieses Modus angeraten erscheint.<\/p>\n\n\n\n<p>Bevor Let&#8217;s Encrypt ein Zertifikat ausstellt, muss der anfragende Client beweisen, dass er die administrative Kontrolle \u00fcber die Domain hat. Im Falle der DNS-Challenge geschieht dies indem ein TXT-Record in der jeweiligen DNS-Zone erstellt wird. Der LE-Client ben\u00f6tigt somit Zugriff mit Schreibberechtigung auf die entsprechenden DNS-Zonen. Dies kann jedoch verheerende Folgen haben, wenn der Host mit dem LE-Client kompromittiert wird. Ein Angreifer k\u00f6nnte hierdurch API-Zugang erlangen und die Informationen einer (oder mehrere) DNS-Zonen l\u00f6schen. Oder noch schlimmer, die Eintr\u00e4ge manipulieren bzw. eigene Eintr\u00e4ge hinzuf\u00fcgen.<\/p>\n\n\n\n<p>In unserer Organisation hat daher nur autorisiertes Personal mit personalisierten Zugangsdaten Zugriff auf ausgew\u00e4hlte Zonen.<\/p>\n\n\n\n<p>Eine wichtige Eigenschaft von personalisierten Zugangsdaten ist, dass diese nur von der Person verwendet werden, an die sie ausgeh\u00e4ndigt wurden. Diese sollten tunlichst nicht in einen LE-Client eingetragen werden, den man anschlie\u00dfend f\u00fcr Monate oder Jahre sich selbst \u00fcberl\u00e4sst.<\/p>\n\n\n\n<p>Der DNS-Alias-Modus funktioniert so, dass der DNS-Anbieter eine Zone einrichtet, in der dynamische Updates durch LE-Clients gestattet sind. Die Authentifizierung und Autorisierung kann mittels sogenannter <a rel=\"noreferrer noopener\" href=\"https:\/\/de.wikipedia.org\/wiki\/TSIG\" target=\"_blank\">TSIG-Schl\u00fcssel<\/a> durchgef\u00fchrt werden.<\/p>\n\n\n\n<p>Als Sysadmin erstellt man nun einen CNAME-Eintrag in der eigentlichen DNS-Zone, z.B. foo.example.org welcher auf die Zone acme.foo.example.org zeigt. Der LE-Client legt w\u00e4hrend der DNS-Alias-Challenge eine TXT-Record in der Zone acme.foo.example.org an. Let&#8217;s Encrypt kann nun \u00fcber den CNAME den erstellten TXT-Record validieren. Anschlie\u00dfend wird das Zertifikat an den LE-Client ausgestellt.<\/p>\n\n\n\n<p>Wird der LE-Client kompromittiert, sind damit zwar auch die auf ihm gespeicherten Private-Keys kompromittiert (was schon schlimm genug ist), es kann jedoch dar\u00fcber hinaus nur die sogenannte DNS-Alias-Zone manipuliert werden. Eine Manipulation der eigentlichen Zone bleibt ausgeschlossen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"installation-acme-client\">Installation des acme.sh-Clients<\/h2>\n\n\n\n<p>Um ein neu ausgestelltes bzw. erneuertes Zertifikat und den dazugeh\u00f6rigen Private-Key in einem Webserver zu verwenden, muss die Webserver-Konfiguration neu geladen werden. Dazu sind meist Root\/sudoer-Rechte erforderlich. In diesem Tutorial wird der acme.sh-Client unter einem User mit sudo-Berechtigung installiert.<\/p>\n\n\n\n<div class=\"wp-block-group has-light-gray-background-color has-background\"><div class=\"wp-block-group__inner-container is-layout-flow wp-block-group-is-layout-flow\">\n<p><em>Hinweis:<\/em> Das Projekt empfiehlt die Nutzung von <code>sudo<\/code> ausdr\u00fccklich <strong>nicht<\/strong>. Weitere Informationen finden sich unter dem Link: <a rel=\"noreferrer noopener\" href=\"https:\/\/github.com\/acmesh-official\/acme.sh\/wiki\/sudo\" target=\"_blank\">https:\/\/github.com\/acmesh-official\/acme.sh\/wiki\/sudo<\/a><\/p>\n\n\n\n<p>Da ich glaube, zu wissen, was ich tue, werde ich hier optional die Einrichtung unter einem User mit sudo-Berechtigung dokumentieren. Befehle sind entsprechend mit oder ohne <code>sudo<\/code> auszuf\u00fchren, je nachdem welcher User verwendet wird.<\/p>\n<\/div><\/div>\n\n\n\n<p>Zur Installation f\u00fchrt man folgende Kommandos aus (<a rel=\"noreferrer noopener\" href=\"https:\/\/github.com\/acmesh-official\/acme.sh#2-or-install-from-git\" target=\"_blank\">Quelle<\/a>):<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>git clone https:\/\/github.com\/acmesh-official\/acme.sh.git\ncd .\/acme.sh\n.\/acme.sh --install<\/code><\/pre>\n\n\n\n<p>Durch die Installationsroutine werden folgende drei Aktionen durchgef\u00fchrt:<\/p>\n\n\n\n<ol class=\"wp-block-list\"><li>Erstellen und Kopieren von <code>acme.sh<\/code> in das HOME-Verzeichnis (<code>$HOME<\/code>): <code>~\/.acme.sh\/<\/code>. Unterhalb dieses Verzeichnisses werden die ausgestellten Zertifikate abgelegt.<\/li><li>Erstellen eines Alias f\u00fcr: <code>acme.sh=~\/.acme.sh\/acme.sh<\/code>.<\/li><li>Erstellen eines t\u00e4glichen <em>cron job<\/em>, welcher die Restlaufzeit der Zertifikate pr\u00fcft und diese ggf. verl\u00e4ngert.<\/li><\/ol>\n\n\n\n<p>Beispiel eines Cron-Jobs:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>1 0 * * * \"\/home\/alice\/.acme.sh\"\/acme.sh --cron --home \"\/home\/alice\/.acme.sh\" > \/dev\/null<\/code><\/pre>\n\n\n\n<p>Nach der Installation meldet man sich am besten einmal neu an, damit der Alias f\u00fcr acme.sh genutzt werden kann.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"add-cname\">Anlegen der CNAME-Records<\/h2>\n\n\n\n<p>Nun legen wir die CNAME-Records an, welche f\u00fcr den DNS-Alias-Mode ben\u00f6tigt werden (<a rel=\"noreferrer noopener\" href=\"https:\/\/github.com\/acmesh-official\/acme.sh\/wiki\/DNS-alias-mode#1-first-set-domain-cname\" target=\"_blank\">Quelle<\/a>).<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>_acme-challenge.host.foo.example.org IN CNAME acme.foo.example.org\n_acme-challenge.mein-schoener-host.bar.example.org IN CNAME acme.foo.example.org<\/code><\/pre>\n\n\n\n<p>Der vom DNS-Anbieter bereitgestellte TSIG-Schl\u00fcssel ist ausschlie\u00dflich zum Erstellen von Records in der Zone <code>acme.foo.example.org<\/code> berechtigt. Mit dem CNAME-Record weisen wir quasi nach, dass wir die Kontrolle \u00fcber die DNS-Zone haben und dort Ressource-Records erstellen d\u00fcrfen, w\u00e4hrend der acme.sh-Client nur berechtigt ist Eintr\u00e4ge in jenen Zonen zu erstellen, auf welche die CNAME-Records verweisen.<\/p>\n\n\n\n<p>Dies geschieht aus Sicherheitsaspekten. Auf diese Art und Weise wird verhindert, dass ein kompromittierter Host mit acme.sh-Client die wichtigen Zonen \u00fcberschreiben kann.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Beantragung, Ausstellen und Installation eines Zertifikats<\/h2>\n\n\n\n<p>Die \u00dcberschrift deutet bereits an, dass der folgende Prozess aus drei Schritten besteht. Ich beginne mit einem optionalen Schritt, in dem ich die notwendige Konfiguration f\u00fcr einen sudo-User erkl\u00e4re.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"non-root-user\">Optional: Konfiguration f\u00fcr non-root-User<\/h3>\n\n\n\n<p>Wer den acme.sh-Client unter dem User root installiert hat, kann diesen Abschnitt <a href=\"#cert-dir\" data-type=\"internal\" data-id=\"#cert-dir\">\u00fcberspringen<\/a>. An dieser Stelle wird die Konfiguration eines sudo-Users beschrieben.<\/p>\n\n\n\n<p>Verwendet wird dabei ein Useraccount, der bereits \u00fcber sudo-Berechtigungen verf\u00fcgt, sich bei der Verwendung von <code>sudo<\/code> jedoch mit einem Passwort authentisieren muss. Im Folgenden nennen wir diesen Useraccount Alice.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Anpassung der sudoers-Datei<\/h4>\n\n\n\n<p>Da f\u00fcr die Installation des Let&#8217;s Encrypt Zertifikats in einem Webserver  ein Reload der Konfiguration des Webservers erforderlich ist und dies sp\u00e4ter automatisch (ohne Passworteingabe) geschehen soll, ist eine Anpassung der sudoers-Datei von Alice erforderlich.<\/p>\n\n\n\n<p>Die sudoers-Datei von Alice (\/etc\/sudoers.d\/alice) sieht zu Beginn wie folgt aus:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>alice  ALL=(ALL) ALL<\/code><\/pre>\n\n\n\n<p>Um Alice nun das Recht zu geben, die Webserver-Konfiguration ohne Passworteingabe neu zu laden, wird folgende Zeile hinzugef\u00fcgt. Dabei ist die Reihenfolge der Zeilen zu beachten (siehe sudoers(5)). Die Bearbeitung der Datei wird mit dem Kommando <code>sudo visudo -f \/etc\/sudoers.d\/alice<\/code> durchgef\u00fchrt.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>alice  ALL=(ALL) ALL\nalice  ALL=(ALL) NOPASSWD: \/bin\/systemctl reload httpd.service<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\" id=\"cert-dir\">Verzeichnis f\u00fcr TLS-Zertifikate und Private-Keys erstellen<\/h4>\n\n\n\n<p>Zur weiteren Nutzung durch den Webserver, sollen die Zertifikate und Private-Keys in einem Verzeichnis gespeichert werden, auf das Alice Schreibrechte hat. Der Verzeichnisname kann dabei abweichend vom folgenden Beispiel frei gew\u00e4hlt werden. Im Beispiel wird die Gruppe <code>apache<\/code> verwendet. Diese ist ggf. an das eigene System anzupassen:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo mkdir -m 750 \/etc\/letsencrypt\nsudo chown alice.apache \/etc\/letsencrypt<\/code><\/pre>\n\n\n\n<p>Die folgenden Schritte sind f\u00fcr <code>root<\/code> und <code>alice<\/code> gleich. Nur muss <code>alice<\/code> einige Befehle halt mit <code>sudo<\/code> auf\u00fchren. Diese sind entsprechend gekennzeichnet. <code>root<\/code> l\u00e4sst ein f\u00fchrendes <code>sudo<\/code> einfach weg.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Zertifikat beantragen und austellen<\/h3>\n\n\n\n<p>Wie eingangs erw\u00e4hnt, wird ein TSIG-Schl\u00fcssel und das Plugin <code>dns_nsupdate<\/code> genutzt, um dynamische Zonen-Updates auf dem Nameserver durchzuf\u00fchren. Um den acme.sh-Client entsprechend zu konfigurieren, wird zuerst eine Key-Datei erstellt, welche den TSIG-Schl\u00fcssel in JSON-Notation enth\u00e4lt (vgl. Abschnitt <a href=\"#umfeld\">Umfeld<\/a>).<\/p>\n\n\n\n<p><strong>Wichtig:<\/strong> Der TSIG-Schl\u00fcssel erlaubt dynamische Zonen-Updates im DNS. Er ist geheim zu halten und bestm\u00f6glich zu sch\u00fctzen.<\/p>\n\n\n\n<p>Der Name der Datei ist dabei frei w\u00e4hlbar. Ich  empfehle die Datei im HOME-Verzeichnis des Users abzulegen, welcher den acme.sh-Client ausf\u00fchrt und die Datei nur f\u00fcr diesen User lesbar zu machen (<code>chmod 0400 DATEINAME<\/code>). Beispiel:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>cat ~\/.nsupdate.key\nkey \"acme-key\" {\n  algorithm hmac-sha512;\n  secret \"SuperGeheim1111elf==\";\n};\n\nchmod 0400 ~\/.nsupdate.key<\/code><\/pre>\n\n\n\n<p>Als n\u00e4chstes werden notwendige Informationen \u00fcber den Nameserver und unseren TSIG-Key verf\u00fcgbar gemacht. Die folgenden Kommandos sind einmalig auszuf\u00fchren. Die Werte werden vom acme.sh-Client sp\u00e4ter automatisch in <code>~\/.acme.sh\/account.conf<\/code> gespeichert (<a rel=\"noreferrer noopener\" href=\"https:\/\/github.com\/acmesh-official\/acme.sh\/wiki\/dnsapi#7-use-nsupdate-to-automatically-issue-cert\" target=\"_blank\">Quelle<\/a>).<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>export NSUPDATE_SERVER=\"ns.example.org\"\nexport NSUPDATE_KEY=\"\/home\/alice\/.nsupdate.key\"<\/code><\/pre>\n\n\n\n<p>Nun ist es endlich soweit, dass ein Zertifikat ausgestellt werden kann. F\u00fcr die in diesem Tutorial verwendeten Werte lautet der Befehl dazu wie folgt:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>acme.sh --issue --dns dns_nsupdate -d host.foo.example.org -d mein-schoener-host.bar.example.org --challenge-alias acme.foo.example.org<\/code><\/pre>\n\n\n\n<p>Der folgende Code-Block zeigt ein konkretes Beispiel unter Verwendung der <a rel=\"noreferrer noopener\" href=\"https:\/\/letsencrypt.org\/de\/docs\/staging-environment\/\" target=\"_blank\">Staging-Umgebung<\/a>. <\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>acme.sh --issue --staging --dns dns_nsupdate -d host.foo.example.org -d mein-schoener-host.bar.example.org --challenge-alias acme.foo.example.org\n\n&#91;Fr 4. Sep 09:52:41 CEST 2020] Using ACME_DIRECTORY: https:\/\/acme-staging-v02.api.letsencrypt.org\/directory\n&#91;Fr 4. Sep 09:52:42 CEST 2020] Using CA: https:\/\/acme-staging-v02.api.letsencrypt.org\/directory\n&#91;Fr 4. Sep 09:52:42 CEST 2020] Create account key ok.\n&#91;Fr 4. Sep 09:52:42 CEST 2020] Registering account: https:\/\/acme-staging-v02.api.letsencrypt.org\/directory\n&#91;Fr 4. Sep 09:52:43 CEST 2020] Registered\n&#91;...]\n&#91;Fr 4. Sep 09:52:43 CEST 2020] Creating domain key\n&#91;Fr 4. Sep 09:52:44 CEST 2020] The domain key is here: \/home\/alice\/.acme.sh\/host.foo.example.org\/host.foo.example.org\n.key\n&#91;Fr 4. Sep 09:52:44 CEST 2020] Multi domain='DNS:host.foo.example.org,DNS:mein-schoener-host.bar.example.org'\n&#91;Fr 4. Sep 09:52:44 CEST 2020] Getting domain auth token for each domain\n&#91;Fr 4. Sep 09:52:46 CEST 2020] Getting webroot for domain='host.foo.example.org'\n&#91;Fr 4. Sep 09:52:46 CEST 2020] Getting webroot for domain='mein-schoener-host.bar.example.org'                                             \n&#91;Fr 4. Sep 09:52:46 CEST 2020] Adding txt value: 2tG2NCvV23KGUNCSGeVO3P_UVaOVAG4t0ehbv1cJbtY for domain:  _acme-challenge.acme.foo.example.org\n&#91;Fr 4. Sep 09:52:46 CEST 2020] adding _acme-challenge.acme.foo.example.org. 60 in txt \"2tG2NCvV23KGUNCSGeVO3P_UVaOVAG4t0ehbv1cJbtY\"\n&#91;Fr 4. Sep 09:52:46 CEST 2020] The txt record is added: Success.\n&#91;Fr 4. Sep 09:52:46 CEST 2020] Adding txt value: yFbL8EF6xQre3v3RfYiCYQ8X4KH0gykagD9_oRfIvgA for domain:  _acme-challenge.acme.foo.example.org\n&#91;Fr 4. Sep 09:52:46 CEST 2020] adding _acme-challenge.acme.foo.example.org. 60 in txt \"yFbL8EF6xQre3v3RfYiCYQ8X4KH0gykagD9_oRfIvgA\"\n&#91;Fr 4. Sep 09:52:46 CEST 2020] The txt record is added: Success.\n&#91;Fr 4. Sep 09:52:46 CEST 2020] Let's check each DNS record now. Sleep 20 seconds first.\n&#91;Fr 4. Sep 09:53:07 CEST 2020] Checking host.foo.example.org for _acme-challenge.acme.foo.example.org                       \n&#91;Fr 4. Sep 09:53:07 CEST 2020] Not valid yet, let's wait 10 seconds and check next one.\n&#91;Fr 4. Sep 09:53:20 CEST 2020] Checking mein-schoener-host.bar.example.org for _acme-challenge.acme.foo.example.org\n&#91;Fr 4. Sep 09:53:21 CEST 2020] Domain mein-schoener-host.bar.example.org '_acme-challenge.acme.foo.example.org' success.\n&#91;Fr 4. Sep 09:53:21 CEST 2020] Let's wait 10 seconds and check again.\n&#91;Fr 4. Sep 09:53:32 CEST 2020] Checking host.foo.example.org for _acme-challenge.acme.foo.example.org\n&#91;Fr 4. Sep 09:53:32 CEST 2020] Domain host.foo.example.org '_acme-challenge.acme.foo.example.org' success.\n&#91;Fr 4. Sep 09:53:32 CEST 2020] Checking mein-schoener-host.bar.example.org for _acme-challenge.acme.foo.example.org\n&#91;Fr 4. Sep 09:53:32 CEST 2020] Already success, continue next one.                                                                          \n&#91;Fr 4. Sep 09:53:32 CEST 2020] All success, let's return\n&#91;Fr 4. Sep 09:53:32 CEST 2020] Verifying: host.foo.example.org\n&#91;Fr 4. Sep 09:53:35 CEST 2020] Pending\n&#91;Fr 4. Sep 09:53:38 CEST 2020] Success\n&#91;Fr 4. Sep 09:53:38 CEST 2020] Verifying: mein-schoener-host.bar.example.org                                                               \n&#91;Fr 4. Sep 09:53:41 CEST 2020] Success\n&#91;Fr 4. Sep 09:53:41 CEST 2020] Removing DNS records.\n&#91;...]\n&#91;Fr 4. Sep 09:53:41 CEST 2020] Removed: Success\n&#91;Fr 4. Sep 09:53:41 CEST 2020] Verify finished, start to sign.\n&#91;Fr 4. Sep 09:53:41 CEST 2020] Lets finalize the order.\n&#91;Fr 4. Sep 09:53:41 CEST 2020] Le_OrderFinalize='https:\/\/acme-staging-v02.api.letsencrypt.org\/acme\/finalize\/15482274\/142528495'\n&#91;Fr 4. Sep 09:53:42 CEST 2020] Downloading cert.\n&#91;Fr 4. Sep 09:53:42 CEST 2020] Le_LinkCert='https:\/\/acme-staging-v02.api.letsencrypt.org\/acme\/cert\/fa6e5a9922acccb49619cc8808f6f0916dc0'\n&#91;Fr 4. Sep 09:53:43 CEST 2020] Cert success.\n&#91;...]\n&#91;Fr 4. Sep 09:53:43 CEST 2020] Your cert is in  \/home\/alice\/.acme.sh\/host.foo.example.org\/host.foo.example.org.cer\n&#91;Fr 4. Sep 09:53:43 CEST 2020] Your cert key is in  \/home\/alice\/.acme.sh\/host.foo.example.org\/host.foo.example.org.key\n&#91;Fr 4. Sep 09:53:43 CEST 2020] The intermediate CA cert is in \/home\/alice\/.acme.sh\/host.foo.example.org\/ca.cer\n&#91;Fr 4. Sep 09:53:43 CEST 2020] And the full chain certs is there:  \/home\/alice\/.acme.sh\/host.foo.example.org\/fullchain.cer<\/code><\/pre>\n\n\n\n<p>Damit liegen alle ben\u00f6tigten Dateien auf unserem Host. Im n\u00e4chsten Schritt werden diese in die korrekte Lokation installiert.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Installation der Zertifikate f\u00fcr Apache<\/h3>\n\n\n\n<p>Das folgende Beispiel gilt f\u00fcr den Webserver Apache und ist der <a rel=\"noreferrer noopener\" href=\"https:\/\/github.com\/acmesh-official\/acme.sh#3-install-the-cert-to-apachenginx-etc\" target=\"_blank\">Dokumentation des acme.sh-Clients<\/a> entnommen. Auf der verlinkten Seite findet sich ein weiteres Beispiel f\u00fcr den Webserver NGINX.<\/p>\n\n\n\n<p>Das Kommando im folgenden Beispiel enth\u00e4lt am Ende den Parameter <code>--reloadcmd \"sudo systemctl reload httpd.service<\/code>. Das <code>sudo<\/code> ist notwendig, wenn man einen User mit sudo-Berechtigungen wie z.B. Alice nutzt (siehe <a href=\"#non-root-user\">oben<\/a>). Als root l\u00e4sst man <code>sudo<\/code> einfach weg. Ggf. muss der Name der Service-Unit an das eigene System angepasst werden.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>acme.sh --install-cert -d host.foo.example.org --cert-file \/etc\/letsencrypt\/host.foo.example.org.cer --key-file \/etc\/letsencrypt\/host.foo.example.org.key --fullchain-file \/etc\/letsencrypt\/host.foo.example.org.fullchain.cer --reloadcmd \"sudo systemctl reload httpd.service\"<\/code><\/pre>\n\n\n\n<p>Hat alles funktioniert, erzeugt obiger Befehl folgende Ausgabe:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;Fr 4. Sep 12:36:22 CEST 2020] Installing cert to:\/etc\/letsencrypt\/host.foo.example.org.cer\n&#91;Fr 4. Sep 12:36:22 CEST 2020] Installing key to:\/etc\/letsencrypt\/host.foo.example.org.key\n&#91;Fr 4. Sep 12:36:22 CEST 2020] Installing full chain to:\/etc\/letsencrypt\/host.foo.example.org.fullchain.cer\n&#91;Fr 4. Sep 12:36:22 CEST 2020] Run reload cmd: sudo systemctl reload httpd.service\n&#91;Fr 4. Sep 12:36:22 CEST 2020] Reload success<\/code><\/pre>\n\n\n\n<p class=\"has-light-gray-background-color has-background\"><em>Hinweis:<\/em> Der Webserver bzw. VirtualHost des Webservers muss so konfiguriert werden, dass die Zertifikate aus dem entsprechenden Pfad auch verwendet werden. Diese Konfiguration ist nicht Gegenstand dieses Tutorials. Es wird hierzu auf die Dokumentation des genutzten Webservers verwiesen.<\/p>\n\n\n\n<p>Die Dateiberechtigungen f\u00fcr oben installierte Dateien sind nach der Installation einmalig zu korrigieren und ggf. mit <code>chown<\/code> und <code>chmod<\/code> so zu konfigurieren, dass nur Alice und der Webserver-User Zugriff darauf haben. <strong>Wichtig:<\/strong> Der Private-Key darf unter keinen Umst\u00e4nden von allen Usern gelesen werden d\u00fcrfen. Folgender Code-Block zeigt eine m\u00f6gliche Berechtigung:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ls -l \/etc\/letsencrypt\/\ntotal 12\n-rw-r-----. 1 alice apache 1964  4. Sep 15:09 host.foo.example.org.cer\n-rw-r-----. 1 alice apache 3644  4. Sep 15:09 host.foo.example.org.fullchain.cer\n-rw-r-----. 1 alice apache 1679  4. Sep 15:09 host.foo.example.org.key<\/code><\/pre>\n\n\n\n<p>Die Dateiberechtigungen bleiben bei einer Erneuerung des Zertifikats und beim \u00dcberschreiben der existierenden Dateien erhalten.<\/p>\n\n\n\n<p>Die vorgenommenen Einstellungen und Befehle werden in der Datei <code>~\/.acme.sh\/account.conf<\/code> gespeichert. In der Standard-Einstellung wird das Zertifikat automatisch alle 60 Tage erneuert, in den angegebenen Pfaden installiert und ein Neustart des Webservers durchgef\u00fchrt.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Weiterf\u00fchrende Quellen und Links<\/h2>\n\n\n\n<ol class=\"wp-block-list\"><li>A Technical Deep Dive: Securing the Automation of ACME DNS Challenge Validation: <a rel=\"noreferrer noopener\" href=\"https:\/\/www.eff.org\/deeplinks\/2018\/02\/technical-deep-dive-securing-automation-acme-dns-challenge-validation\" target=\"_blank\">https:\/\/www.eff.org\/deeplinks\/2018\/02\/technical-deep-dive-securing-automation-acme-dns-challenge-validation<\/a><\/li><li>How-to install acme.sh: <a rel=\"noreferrer noopener\" href=\"https:\/\/github.com\/acmesh-official\/acme.sh\/wiki\/How-to-install\" target=\"_blank\">https:\/\/github.com\/acmesh-official\/acme.sh\/wiki\/How-to-install<\/a><\/li><li>Install from Git: <a rel=\"noreferrer noopener\" href=\"https:\/\/github.com\/acmesh-official\/acme.sh#2-or-install-from-git\" target=\"_blank\">https:\/\/github.com\/acmesh-official\/acme.sh#2-or-install-from-git<\/a><\/li><li>Set up Let\u2019s Encrypt certificate using acme.sh as non-root user: <a href=\"https:\/\/gist.github.com\/Greelan\/28a46a33140b65c9a045573ca460f044\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/gist.github.com\/Greelan\/28a46a33140b65c9a045573ca460f044<\/a><\/li><\/ol>\n","protected":false},"excerpt":{"rendered":"<p>Dieses Tutorial erkl\u00e4rt, wie der Let&#8217;s Encrypt Client (LE-Client) acme.sh mit dem Plugin dns_nsupdate auf einem Linux-System installiert und zur Nutzung der &#8222;DNS-01 challenge&#8220; im DNS-Alias-Modus konfiguriert werden kann. Um dem Tutorial folgen zu k\u00f6nnen, sollte man den grundlegenden Umgang mit einem Terminal und einer weitgehend POSIX-kompatiblen Shell beherrschen. Grundlegende Kenntnisse der Funktion von DNS<span class=\"continue-reading\"> <a href=\"https:\/\/www.my-it-brain.de\/wordpress\/lets-encrypt-nutzung-des-dns-alias-modus-mit-dem-acme-sh-client\/\">[Weiterlesen&#8230;]<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_metis_text_type":"","_metis_text_length":0,"_post_count":0,"footnotes":""},"categories":[3],"tags":[599,601,600,379,430,305],"class_list":["post-2590","post","type-post","status-publish","format-standard","hentry","category-tutorials","tag-acme-sh","tag-dns-alias-modus","tag-dns-challenge","tag-lets-encrypt","tag-osbn","tag-planet"],"_links":{"self":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/2590","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/comments?post=2590"}],"version-history":[{"count":14,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/2590\/revisions"}],"predecessor-version":[{"id":2638,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/2590\/revisions\/2638"}],"wp:attachment":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/media?parent=2590"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/categories?post=2590"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/tags?post=2590"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}