Let’s Encrypt Zer­ti­fi­kat für das Heim-Netz

Inhalt

Update vom 1.7.2022: Bit­te unbe­dingt zuerst Nach­trag 3 beachten!

Mit eini­gen Vor­keh­run­gen las­sen sich Let’s-Encrypt-Zertifikate auch für inter­ne Net­ze nut­zen, die nicht vom Inter­net erreich­bar sind.

Zer­ti­fi­ka­te von Let’s Encrypt

Let’s Encrypt [1] bie­tet schon seit eini­gen Jah­ren kos­ten­lo­se SSL-Zer­ti­fi­ka­te für ein­zel­ne Domains an. Seit kur­zem wer­den auch Wild­card-Zer­ti­fi­ka­te aus­ge­stellt, die für alle Sub­do­mains einer Domain gül­tig sind. Wird ein sol­ches Zer­ti­fi­kat zum Bei­spiel für *.home​.kunz​.de aus­ge­stellt, gilt es auch für alle Sub­do­mains, also zum Bei­spiel auch für hinz​.home​.kunz​.de.

Damit lässt sich rela­tiv ein­fach ein Zer­ti­fi­kat gene­rie­ren, dass für alle Ser­ver im Heim-Netz gül­tig ist und nicht - wie ein selbst­si­gnier­tes Zer­ti­fi­kat - von Web-Brow­sern als unsi­cher mar­kiert wird. Die Let’s-Encrypt-Zertifikate sind aller­dings nur jeweils 60 Tage gül­tig. Des­we­gen macht es Sinn, die Erneue­rung des Home-Zer­ti­fi­kats auto­ma­tisch ablau­fen zu lassen.

Über­prü­fungs-Pro­ze­du­ren (Chal­lenges)

Wäh­rend der Bean­tra­gung oder Erneue­rung der Zer­ti­fi­ka­te muss der Let’s Encrypt Ser­ver über­prü­fen, dass  die Domain dem Bean­tra­ger gehört oder von ihm admi­nis­triert wird. Dafür gibt es meh­re­re Mög­lich­kei­ten, unter ande­rem die web­root- und die DNS-Prozedur.

Die web­root Pro­ze­dur erwar­tet eine Sei­te mit vor­ge­ge­be­nem Inhalt im Wur­zel-Ver­zeich­nis des Web­ser­vers. Das lässt sich zwar sehr leicht auto­ma­ti­sie­ren, aber zur Über­prü­fung muss der Ser­ver vom Inter­net aus erreich­barr sein, was im Heim­netz Port­wei­ter­lei­tun­gen auf dem Inter­net-Rou­ter erfor­der­lich macht.

Bei der DNS-Pro­ze­dur muss beim DNS-Ser­ver der Zone ein TXT-Record mit vor­ge­ge­be­nem Namen und Inhalt ein­ge­stellt wer­den. Die­ser Ein­trag wird bei der Bean­tra­gung vom Let’s Encrypt Ser­ver abge­ru­fen. Dafür muss die Domain selbst nicht erreich­bar sein, was die Nut­zung für Domains in pri­va­ten Net­zen sehr ver­ein­facht. Für Wild­card-Zer­ti­fi­ka­te ist die DNS-Chall­enge die ein­zig mög­li­che Überprüfungs-Prozedur.

Let’s Encrypt cert­bot installieren

Zunächst muss auf einem Ser­ver im Heim­netz das Let’s Encrypt cert­bot Paket instal­liert wer­den. Bei mir ist die­ser Ser­ver ein stän­dig lau­fen­der Raspber­ry­PI mit dem Debi­an-Stretch-basier­ten NAS-Sys­tem open­me­diav­ault 4 (omv).

Bei Debi­an Stretch befin­det sich das cert­bot-Paket im stretch-back­ports-Repo­si­to­ry, das bei omv 4 bereits in den Paket­quel­len ein­ge­tra­gen ist.

$ sudo apt-get install certbot -t stretch-backports

Das Zer­ti­fi­kat manu­ell beantragen

Jetzt kön­nen wir cert­bot benut­zen, um das Zer­ti­fi­kat zu bean­tra­gen. Der certonly Schal­ter bewirkt, dass das Zer­ti­fi­kat nur abge­ru­fen, aber nicht instal­liert wird. Wild­card-Zer­ti­fi­ka­te wer­den nur vom acme-v02 Ser­ver aus­ge­stellt, der mit dem ser­ver Schal­ter ange­ge­ben wer­den muss. Unter -d wird die Wild­card-Domain ange­ge­ben, für die das Zer­ti­fi­kat aus­ge­stellt wer­den soll.

Da die ein­zi­ge unter­stütz­te Prü­fungs­art die DNS-Chall­enge ist, muss sie mit pre­fer­red-chal­lenges dns aus­ge­wählt wer­den. Der manu­al Schal­ter gibt an, dass der TXT-Record manu­ell ein­ge­tra­gen wird. Zur Auto­ma­ti­sie­rung spä­ter mehr.

# certbot certonly --server https://acme-v02.api.letsencrypt.org/directory -d *.home.kunz.de --email webmaster@kunz.de --preferred-challenges dns --manual
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for home.kunz.de

-------------------------------------------------------------------------------
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?
-------------------------------------------------------------------------------
(Y)es/(N)o: y

-------------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.home.kunz.de with the following value:

dhfjknfhuioOHoihHohoioioih568_nvihUGüj87ui87

Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue

Nach­dem man sein Ein­ver­ständ­nis mit der Auf­zeich­nung sei­ner IP-Adres­se erklärt hat, druckt der cert­bot Namen und Inhalt des TXT-Records aus, der nun beim zustän­di­gen DNS-Zonen­ver­wal­ter - bei mir FreeDNS - ein­ge­tra­gen wer­den muss. Dazu öff­nen wir ein zwei­tes Terminal.

Die Heim­netz-Domain

Als Heim­netz-Domain wird eine Sub­do­main einer offi­zi­el­len Domain benutzt. Sie wird als Sub­do­main beim glei­chen Pro­vi­der ein­ge­tra­gen, der auch für die Basis-Domain ver­ant­wort­lich ist.

Wenn man vor­hat, auch vom Inter­net aus auf Ser­ver in der Heim-Domain zuzu­grei­fen, muss man auf die Diens­te eines dynDNS-Pro­vi­ders zurück­grei­fen. Ein­zel­hei­ten beschreibt der Arti­kel DynDNS für eine eige­ne Domain ein­rich­ten.

Im fol­gen­den arbei­ten wir mit dem DynDNS-Pro­vi­der FreeDNS, auf den die Namens­auf­lö­sung bei mei­nem Domain-Pro­vi­der dele­giert wurde.

Den DNS TXT-Record erzeugen

Nach Anmel­dung bei FreeDNS wäh­len wir aus dem Menü links den Ein­trag Dyna­mic DNS aus und kli­cken im Titel der Tabel­le der DNS-Records auf Add. Als Typ wäh­len wir TXT aus. Die Domain bleibt bei home​.kunz​.de. Unter Sub­do­main wird der gefor­der­te Chall­enge-Name und unter Desti­na­ti­on der Text in dop­pel­ten Anfüh­rungs­zei­chen eingetragen.

Nach dem Kli­cken auf Save che­cken wir per nslook­up, ob der TXT-Record schon ver­füg­bar ist, Das kann je nach TTL eini­ge Zeit dau­ern. Bei FreeDNS steht die TTL fest auf 60 Sekun­den, so dass spä­tes­tens nach etwa ein bis zwei Minu­ten der TXT-Record abruf­bar sein sollte.

$ nslookup
> set type=TXT
> _acme-challenge.home.kunz.de
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
_acme-challenge.home.kunz.de text = "dhfjknfhuioOHoihHohoioioih568_nvihUGüj87ui87"

Wei­ter mit cert­bot

Jetzt kann im ers­ten Ter­mi­nal der cert­bot mit Return fort­ge­setzt werden:

Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/home.kunz.de/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/home.kunz.de/privkey.pem
Your cert will expire on 2018-09-30. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew *all* of your certificates, run
"certbot renew"
- If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

#

Geht alles gut, lie­gen am Ende Schlüs­sel­da­tei und Zer­ti­fi­kat unter /etc/letsencrypt/live/home.kunz.de und kön­nen direkt ver­wen­det werden.

Das Zer­ti­fi­kat in omv nutzen

Um das Zer­ti­fi­kat für open­me­diav­ault ver­füg­bar zu machen, wählt man im omv-Menü Zer­ti­fi­ka­te aus, klickt auf den SSL Tab und wählt unter Hin­zu­fü­gen den Ein­trag Impor­tie­ren aus. Unter Pri­va­ter Schlüs­sel wird der Inhalt von privkey.pem und unter Zer­ti­fi­kat der Inhalt von fullchain.pem ein­ge­tra­gen. In’s Kom­men­tar­feld gehört eine mög­lichst ein­deu­ti­ger Text, um das Zer­ti­fi­kat spä­ter iden­ti­fi­zie­ren zu können.

Zuletzt wählt man unter All­ge­mei­ne Ein­stel­lun­gen bei Siche­re Ver­bin­dung das neue Zer­ti­fi­kat aus und sichert die Einstellungen.

Ab jetzt soll­te der Brow­ser die omv-Sei­te als Sicher mar­kie­ren, wenn sie mit dem voll­stän­di­gen Namen, also zum Bei­spiel mit omv​.home​.kunz​.de,  auf­ge­ru­fen wird.

Die­ses Zer­ti­fi­kat kön­nen alle Ser­ver mit einer Sub­do­main unter home​.kunz​.de  benut­zen; sie wer­den dann eben­falls als Sicher eingestuft.

Auto­ma­ti­sie­rung der DNS-Challenge

Das Über­prü­fungs­ver­fah­ren der DNS-Chall­enge kann mit einem Script auto­ma­ti­siert wer­den. Der manu­al-auth-hook [2.1] wird auf­ge­ru­fen, bevor die Über­prü­fung der Chall­enge statt­fin­det. In die­sem Script muss der gefor­der­te TXT-Record beim DNS-Pro­vi­der erzeugt werden.

Für eini­ge, vor­wie­gend ame­ri­ka­ni­sche DNS-Pro­vi­der exis­tie­ren vor­de­fi­nier­te auth-Scripts [2.2]. Für alle ande­ren muss man das Script selbst erzeu­gen. Die nöti­gen Wer­te wie Name und Inhalt des TXT-Records wer­den vom cert­bot als Umge­bungs­va­ria­blen über­ge­ben [2.1]. Uns inter­es­siert im Moment ledig­lich die Varia­ble CERTBOT_VALIDATION, in der der erfor­der­li­che Inhalt des TXT-Records über­ge­ben wird.

Bei FreeDNS [3] kann der Inhalt eines bestehen­den TXT-Records mit fol­gen­dem CURL-Kom­man­do geän­dert werden:

curl -b "dns_cookie=XXXXXXXXXX" -d "type=TXT" -d "subdomain=_acme-challenge" -d "domain_id=0000" -d "data_id=0000" -d "address=%22some_text%22" https://freedns.afraid.org/subdomain/save.php?step=2

Die Varia­blen data_id, domain_id und dns_cookie müs­sen aus der FreeDNS Web-Sei­te abge­le­sen werden:

  • Die data_id fin­det man unter dem Men­u­ein­trag Sub­do­mains im Link zum edi­tie­ren des TXT-Records.
  • Die domain_id steckt auf der glei­chen Sei­te im add Link hin­ter der Basis-Domain.
  • Den Inhalt des DNS-Coo­kies kann man aus dem dns_cookie für freedns​.afraid​.org able­sen
    (Bei Chro­me: chrome://settings/cookies/detail?site=freedns.afraid.org).

Hat man alle Anga­ben zusam­men, kann man die Funk­ti­on zunächst auf der Kom­man­do­zei­le prü­fen. Im Erfolgs­fal­le erzeugt curl dabei kei­ne Aus­ga­be, son­dern kehrt Kom­men­tar­los zum Prompt zurück. Mit nslook­up kön­nen wir nach ein bis zwei Minu­ten prü­fen, ob der TXT-Record auch pro­pa­giert wird:

# nslookup -type=TXT _acme-challenge.home.kunz.de
Server: 192.168.2.1
Address: 192.168.2.1#53

Non-authoritative answer:
_acme-challenge.home.kunz.de text = "some_text"

Das curl Koman­do ste­cken wir nun in das Script freedns​-txt​.sh, dass der cert­bot dann als manu­al-auth-hook benut­zen kann:

#!/bin/bash
#
dns_cookie="xxxxxxxxxxxx"
domain_id="0000"
data_id="0000"
ttl=60
#
curl -S -b "dns_cookie=$dns_cookie" -d "type=TXT" -d "subdomain=_acme-challenge" -d "domain_id=$domain_id" -d "data_id=$data_id" -d "address=%22$CERTBOT_VALIDATION%22" https://freedns.afraid.org/subdomain/save.php?step=2
sleep $ttl

Der Schal­ter -S (oder --silent) bewirkt, dass curl kei­ne Fort­schritts­an­zei­ge, wohl aber Feh­ler­nach­rich­ten aus­gibt. Am Ende war­tet das Script, bis die TTL des (alten) DNS-Ein­trags abge­lau­fen ist, was bei FreeDNS nach 60 Sekun­den geschieht.

Auto­ma­ti­sche Zertifikats-Erneuerung

Das renew-Kom­man­do des cert­bot wird für einen Test mit dem Pfad zu obi­gem Script ergänzt und mit --dry-run getestet:

# certbot renew --manual-auth-hook=/root/freedns-txt.sh --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/home.kunz.de.conf
-------------------------------------------------------------------------------
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator manual, Installer None
Renewing an existing certificate
Performing the following challenges:
dns-01 challenge for home.kunz.de

Waiting for verification...
Cleaning up challenges

-------------------------------------------------------------------------------
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/home.kunz.de/fullchain.pem
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/home.kunz.de/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)
-------------------------------------------------------------------------------

Wenn alles wie hier funk­tio­niert, kann die­ses Kom­man­do nun in die geplan­ten Auf­ga­ben des omv ein­ge­tra­gen wer­den, damit täg­lich über­prüft wird, ob das  Zer­ti­fi­kat erneu­ert wer­den muss.

Die Ver­tei­lung und Instal­la­ti­on des Zer­ti­fi­kats kann man eben­falls auto­ma­ti­sie­ren. Mit dem deploy-hook kann man ein Shell-Script ange­ben, dass nach einer erfolg­rei­chen Zer­ti­fi­kats­er­neue­rung auf­ge­ru­fen wird. Da mein pri­va­ter Ser­ver-Park aber noch über­schau­bar ist, ver­zich­te ich im Moment darauf.

Fazit

Mit einem Let’s Encrypt Zer­ti­fi­kat las­sen sich mit wenig Auf­wand auch Ser­ver absi­chern, die nicht vom Inter­net erreich­bar sind. Die Zer­ti­fi­kats-Erneue­rung lässt sich auto­ma­ti­sie­ren. Damit soll­ten auch im Heim­netz die Zei­ten unver­schlüs­sel­ter Über­tra­gun­gen vor­bei sein.

Nach­trag: cron­tab und sys­tem trigger

Das Debi­an-Paket cert­bot ent­hält schon sowohl einen cron­tab-Job als auch einen Sys­tem Trig­ger, die zwei mal täg­lich ver­su­chen, das Zer­ti­fi­kat zu erneu­ern. In mei­nem Fal­le läuft das schief, weil cert­bot ledig­lich mit

certbot renew -q

auf­ge­ru­fen wird. Wegen des feh­len­den manu­al-auth-hook schei­tert die­ser Ver­such immer mit einer Feh­ler­mel­dung in /var/log/letsencrypt/letsencrypt.log.

Man kann jetzt entwder den Auf­ruf von cert­bot im Ser­vice cert­bot und im cron­tab ändern, oder bei­de stil­le­gen und wei­ter­hin den cron­tab-Ein­trag im omv benutzen.

Ich habe mich für letz­te­res ent­schie­den, weil dann alle cron-Jobs an einer Stel­le über­sicht­lich über die omv Web-Ober­flä­che zu ver­wal­ten sind.

Um den cron­tab-Ein­trag zu ent­fer­nen, löscht man ein­fach die Datei /etc/cron.d/certbot. Ser­vice und Trig­ger wer­den mit fol­gen­den Kom­man­dos entfernt:

systemctl stop certbot
systemctl stop certbot.timer
systemctl disable certbot
systemctl disable certbot.timer​
systemctl daemon-reload

Jetzt soll­te letsencrypt.log sau­ber bleiben.

Nach­trag 2: Umzug des certbot

[26.11.2018] Vor kur­zem war der Umzug des cert­bot auf einen ande­ren Ser­ver nötig. Dazu wird auf dem neu­en Ser­ver zunächst das cert­bot Paket installiert:

apt-get install certbot

Das manu­al-auth-hook Script wird vom alten Ser­ver an die glei­che Stel­le (bei mir: /root/freedns-txt.sh) auf dem neu­en Ser­ver kopiert. Zusätz­lich kopiert man die alten Zer­ti­fi­kats­da­ten aus /etc/letsencrypt des alten Ser­vers, am ein­fachs­ten per tar-Archiv:

cd /etc/letsencrypt
tar cfv trans.tar accounts archive csr keys live renewal

Das Archiv trans.tar wird in /etc/letsencrypt des neu­en Ser­vers kopiert und entpackt:

cd /etc/letsencrypt
tar xvf trans.tar

Falls nicht ohne­hin vor­han­den, muss noch das beim manu­al-auth-hook benutz­te curl Paket nach­in­stal­liert werden:

apt-get install curl

Jetzt kann man die Auto­ma­ti­sche Zer­ti­fi­kats-Erneue­rung wie oben beschrie­ben tes­ten und als cron-Job eintragen.

Nach­trag 3: Neue Pro­ze­dur mit Hetz­ner DNS-Console

Mit der Hetz­ner DNS-Con­so­le lässt sich das Bean­tra­gen des Wild­card-Zer­ti­fi­kats erheb­lich ver­ein­fa­chen. Das Vor­ge­hen ist in „let­sen­crypt wild­card cer­ti­fi­ca­te mit acme​.sh und Hetz­ner DNS” beschrie­ben.


Quel­len und Links:

  1. Let’s Encrypt Home­page: let​sen​crypt​.org
  2. Cert­bot Doku­men­ta­ti­on: cert​bot​.eff​.org/​d​o​c​s​/​u​s​i​n​g​.​h​tml
    1. Pre- and Post-Validation-Hooks
    2. DNS-Plug­ins
  3. FreeDNS Homa­pa­ge: freedns​.afraid​.org

17 Kommentare

  1. Hal­lo Jörg,
    ich bin auf Dei­nen Blog gesto­ßen weil ich in mei­nem Heim­netz auch ein Let­sen­crypt-Zer­tif­kat ver­wen­den möch­te. Aller­dings soll wie in Dei­ner Ein­lei­tung beschrie­ben das Netz von aus­sen nicht erreich­bar sein, d.h. ich möch­te weder Ports auf mei­ner Fritz­Box öff­nen noch sol­len die Heim­ser­ver vom Inter­net erreich­bar sein. Ziel ist ein­fach den inter­nen Web­ser­ver ohne Sicher­heit­war­nung aus dem inter­nen Netz aufzurufen. 

    Bei Dei­ner Anlei­tung wird bspw. die Domi­an omv​.home​.kunz​.de mei­ner Mei­nung nach aber über das Inter­net auf­ge­ru­fen d.h. die Web­sei­te geht ein­mal um die Welt und der Daten­auf­ruf bleibt nicht im inter­nen Netz. Ist das so korrekt?

    Wie kann ich das anstel­len, dass ich die Sei­te nur im inter­nen Netz ohne Zer­ti­fi­kats­war­nung auf­ru­fen kann. Bekom­me ich das etwa mit der Anga­be einer wei­te­ren Domain à la „-d *.fritz​.box” hin?
    So dass ich dann bspw. omv​.fritz​.box im inter­nen Netz auf­ru­fen kann?

    1. Hal­lo Andi,
      für Domains a’la …fritz​.box stellt dir nie­mand ein Zer­ti­fi­kat aus. Die Grund­idee der SSL-Zer­ti­fi­ka­te ist ja gera­de, dass man den Ser­ver ein­deu­tig über sei­nen Domain-Namen iden­ti­fi­zie­ren kön­nen muss. Bei sol­chen pri­va­ten Domain-Namen ist das natür­lich nicht gege­ben, denn es gibt ja tau­sen­de fritz.box-Domains.
      Die Ver­bin­dung zu einem Ser­ver über sei­nen öffent­li­chen Namen läuft aber nicht über das Inter­net. In dei­nem pri­va­ten Netz rich­test Du ja eine eige­ne Namens­auf­lö­sung ein, die auf die inter­ne Adres­se dei­nes Ser­vers zeigt. somit ist der Rou­ter nicht an der Ver­bin­dung betei­ligt. Und selbst wenn Du über die öffent­li­che Adres­se gehen wür­dest, wären die meis­ten Rou­ter (u.a. auch die Fritz­box) so schlau, die Ver­bin­dung direkt her­zu­stel­len; ledig­lich die DNS-Abfra­ge geht u.U. nach draußen.
      Ansons­ten könn­test Du ein selbst signier­tes Zer­ti­fi­kat nut­zen, nur lei­der beschwe­ren sich alle moder­nen Brow­ser dann dar­über, dass das nicht ver­trau­ens­wür­dig ist. Bei eini­gen kannst Du per­ma­nen­te Aus­nah­men ein­rich­ten, aber eine sau­be­re Lösung ist das trotz­dem nicht.

      1. Hal­lo Jörg,
        selbst­si­gniert ist momen­tan im Ein­satz, was aus o.g. Grün­den nicht befrie­di­gend ist.

        Und selbst wenn Du über die öffent­li­che Adres­se gehen wür­dest, wären die meis­ten Rou­ter (u.a. auch die Fritz­box) so schlau, die Ver­bin­dung direkt her­zu­stel­len; ledig­lich die DNS-Abfra­ge geht u.U. nach draußen.”

        Momen­tan lie­fert mir ein Ping auf omv.home.meine.domain die exter­ne IP und der Auf­ruf lie­fert mir nicht die inter­ne Web­site. Die FB 7590 scheint hier nichts umzu­bie­gen? Also ver­ste­he ich das rich­tig, ich muss auf jeden Fall einen eige­nen Name­ser­ver betrei­ben und die­sem sagen omv.home.meine.domain = 192.168.x.x
        Den Fritz­Box DNS-Ser­ver kann ich lei­der nicht ver­wen­den, da ich über die Ober­flä­che den Netz­werk­ge­rä­ten kei­nen Namen omv.home.meine.domain zuwei­sen kann, da kei­ne Punk­te im Namen erlaubt sind. Und die­ser Hack https://​adri​an​-jagusch​.de/​2​0​1​5​/​0​3​/​d​o​m​a​i​n​s​-​a​b​f​a​n​g​e​n​-​m​i​t​-​d​e​r​-​f​r​i​t​z​b​o​x​-​a​l​s​-​d​n​s​-​s​e​r​v​er/ funk­tio­niert auch nicht mehr. Ich müß­te also jetzt mit einem dns­masq ein Split-DNS auf­bau­en und die Namens­auf­lö­sung der Fritz­Box abschal­ten. Kor­rekt? Oder reicht es viel­leicht die Adres­se omv.home.meine.domain in der DNS-Rebind-Aus­nah­me­lis­te der FB aufzunehmen?

        Nur noch­mal zum Ver­ständ­nis, wenn ich also omv.home.meine.domain im inter­nen Netz auf 192.168.x.x wie oben beschrie­ben umbie­ge, dann wird mir im inter­nen Netz mei­ne Sei­te mit gül­ti­gem Zer­ti­fi­kat gelie­fert, ohne dass eine Schlei­fe übers Inter­net gemacht wird. Es wird NUR die Gül­tig­keit des Zer­ti­fi­kats übers Inter­net geprüft anhand von home.meine.domain. Heißt aber auch, dass wenn die Inter­net­ver­bin­dung nicht steht, die Prü­fung nicht statt­fin­den kann?

  2. Da die fritz­box kei­ne Namen mit Punk­ten erlaubt und ich kei­nen wei­te­ren DNS Ser­ver in mei­nem Netz ein­rich­ten möchte,
    habe ich jetzt bei mei­nem Pro­vi­der (all-inkl) einen neu­en DNS Ein­trag mit Typ A für omv.home.meine.domain ange­legt, der auf mei­ne inter­ne IP 192.168.x.x verweist.
    Damit die Fritz­box auch die Auf­lö­sung auf das inter­ne Netz zulässt habe ich omv.home.meine.domain als Aus­nah­me in den DNS-Rebind-Schutz der Fritz­box hinterlegt.
    Ich weiß man soll kei­ne inter­nen IPs in öffentl. DNS ein­tra­gen, aber das ist für mich der ein­fachs­te Weg und der Pro­vi­der hat das nicht gesperrt.
    Ein Sicher­heits­ri­si­ko sehe ich auch nicht unbe­dingt, da kei­ne Daten nach ins Inter­net gela­gen aus­ser der Namensauflösung.
    Das gan­ze hat nur den Nach­teil, das wenn die Inter­net­ver­bin­dung aus­fällt kann auch der Name nicht auf­ge­löst werden.

    1. Hal­lo Andi,
      ich fürch­te, das wird alles nichts nüt­zen, weil Du kein Zer­ti­fi­kat für die­se Adres­se aus­stel­len las­sen kannst.

      1. Hal­lo Jörg,
        „meine.domain” ist nur ein Platz­hal­ter. Ich nut­ze tat­säch­lich eine gül­ti­ge Domain. Ich habe es wie beschrie­ben umge­setzt und es funk­tio­niert auch alles, eben nur mit der Beson­der­heit, dass ich intern kei­nen wei­te­ren DNS Ser­ver (neben der Fritz­Box) betrei­be, son­dern den DNS Ser­ver mei­nes Pro­vi­ders für die Namens­auf­lö­sung auf die inter­ne IP verwende.

  3. Hal­lo,
    ich nut­ze einen Heim­ser­ver, der aller­dings nicht auf einem Raspbi ist, son­dern auf einem ASROCK J4105-ITX Board.
    Ich habe die­se Anlei­tung über Goog­le gefun­den. Ist die­se Vor­ge­hens­wei­se auch ohne Raspbi mög­lich? Ist die­se Anlei­tung mach­bar, wenn man danach wei­te­re Diens­te (z.b.traefik, next­cloud) mit Docker-com­po­se nut­zen möchte?

    Ich habe kei­nen DynDNS Dienst akti­viert. Habe aber eine Domain, die ich in deren DNS Ein­stel­lun­gen mit sub­do­mains „befül­len” kann, um dies hier viel­leicht auch zu nut­zen. Wäre dies möglich?

    1. Hal­lo Martin,
      die Hard­ware ist letzt­lich egal, solan­ge Du ein Linux dar­auf instal­liert hast und cert­bot läuft.
      Für let’s encrypt ist nur ent­schei­dend, dass Du die DNS-Chall­enge bedie­nen kannst, also bei dei­nem Domain-Hos­ter per API Text-Records in dei­ne DNS-Kon­fi­gu­ra­ti­on ein­stel­len kannst.
      Viel Erfolg!
      Jörg

  4. Hal­lo zusammen,
    nur für den Fall das jemand das gan­ze wie ich bei All​-Inkl​.com ver­sucht, dort funk­tio­niert der acme chall­enge TXT Ein­trag nicht mit dem vor­han­de­nen DynDNS Dienst. Ich bin über fol­gen­des Git­hub Issue gestol­pert, das zumin­dest bei Nut­zung einer Fritz­box Abhil­fe schafft:
    https://​git​hub​.com/​a​c​m​e​s​h​-​o​f​f​i​c​i​a​l​/​a​c​m​e​.​s​h​/​i​s​s​u​e​s​/​2​812

    Man erstellt einen CNAME Ein­trag für die gewünsch­te Sub­do­main auf die myfritz​.net Adres­se und auf die­ser fun­kio­niert dann schließ­lich auch der acme chall­enge TXT Eintrag.

  5. hal­lo,
    nach umstel­lung von dsl auf glas­fa­ser und sophos utm auf pfsen­se möch­te ich die­se auch wie­der mit einem let’s encrypt zer­ti­fi­kat aus­stat­ten. wenn ich aller­dings wie hier beschrie­ben und auch in dem screen­shot zu sehen, ver­su­che die „_acme-challenge.xyz” bei freedns ein­zu­tra­gen, bekom­me ich eine fehlermeldung.
    „Crea­ti­on of records begin­ning with ‘_’ are pre­sent­ly rest­ric­ted to the domain owner only by default - this is tem­po­ra­ry (2016−02−10) plea­se cont­act dnsadmin@​afraid.​org if you need access.”
    hat­tet ihr die­sen feh­ler bei der erstel­lung nicht?

    1. Oh, das ist schon lan­ge her, aber soweit ich mich erin­nern kann, gab es den Feh­ler nicht. Ich hat­te aber aus einem ande­ren Grund Kon­takt mit dem Admin, also schrei­be ihn doch ein­fach an, er hat sich zumin­dest damals recht schnell gemel­det. Domain-Owner bist Du ja.

  6. Hal­lo Jörg,
    Ich habe ein Pro­blem bei der auto­ma­ti­sier­ten Zer­ti­fi­kats­er­neu­rung. Der Grund des Pro­blems wird wohl sein, dass ich für mei­ne Domain ein Wild­card-Zer­ti­fi­kat habe. Komi­scher­wei­se ver­sucht er die DNS-Chall­enge zwei­mal für die glei­che Domain (also die domain​.de, Name geän­dert). Bei bei­den Aus­füh­run­gen vom manu­al-auth-hook com­mand zeigt er dann einen Error an (Nur ne Tabel­le, wo im Prin­zip dran­steht, dass nichts ange­kom­men is). Am Ende wird dann noch das „Detail: Incor­rect TXT record” und „To fix the­se errors, plea­se make sure that your domain name was ente­red cor­rect­ly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address.”
    Hast du einen Tipp, was ich dage­gen machen kann?
    MfG Alex

    1. Hal­lo Alex,
      da passt offen­sicht­lich der DNS TXT Record nicht zu dem Domain Namen, den der Cert­bot abfragt. Kon­trol­lie­re am bes­ten noch ein­mal von Hand, ob DNS bei Abfra­ge der Wild­card-Domain auch den kor­rek­ten TXT-Record lie­fert (nslook­up -type=TXT _acme-challenge.[wildcard-domain]).

      1. Lei­der liegt auch da das Pro­blem nicht. Ich bekom­me Ser­ver sowie den Ein­trag in afraid und den aktu­el­len text.
        Das hier ist die genaue Aus­ga­be bei Ver­such von renew:
        The fol­lo­wing errors were repor­ted by the server:
        Domain: [domain​.de]
        Type: unauthorized
        Detail: Incor­rect TXT record
        „Zkrm3L7w­tRz2RW­pa­mo-Dowoi­Thr35S5F­ca-a5c3Lc8E” found at
        _acme-challenge.[domain.de]

        Also irgend­was scheint wohl mit der Authen­ti­fi­zie­rung falsch zu laufen?
        Komi­scher­wei­se pro­biert er auch die dns chall­enge zwei­mal für die
        Per­forming the fol­lo­wing challenges:
        dns-01 chall­enge for [domain​.de]
        dns-01 chall­enge for [domain​.de]

        1. Die Authen­ti­fi­zie­rung besteht ja nur in der Abfra­ge des TXT-Records vom DNS. Wenn er den bekommt und der Inhalt gleich dem gefor­der­ten ist, bist Du authen­ti­fi­ziert. War­um die chall­enge dop­pelt geprüft wird, kann ich dir aber lei­der auch nicht sagen.

  7. Muss man den TXT Ein­trag in der acme Sub­do­main aus Sicher­heits­grün­den wie­der ent­fer­nen oder hat das kei­nen Nach­teil wenn man ihn drin lässt? Den kann ja dann jeder abrufen.
    Dan­ke für den tol­len Bei­trag. Hat mir sehr geholfen.

    Vie­le Grüße

    1. Die Chall­enge wird mei­nes Wis­sens bei jeder Anfra­ge neu berech­net, also kann spä­ter nie­mand etwas damit anfan­gen. Ich las­se sie jeden­falls immer bis zur nächs­ten Abfra­ge dort liegen.

Schreibe einen Kommentar zu Andi Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

16 + 7 =