Let’s Encrypt: Kostenloses SSL/TLS Zertifikat erstellen
Let’s Encrypt ist eine Zertifizierungsstelle, die kostenlose X.509-Zertifikate für Transport Layer Security (TLS; umgangssprachlich SSL) anbietet. TLS ist eine gängige Methode im Internet Datenübertragungen abzusichern. Der Prozess der Erstellung, Validierung, Signierung, Einrichtung und Erneuerung von Zertifikaten wurde dabei, entgegen vieler anderer kommerzieller Zertifizierungsstellen, automatisiert. Let’s Encrypt ist eine Initiative von der gemeinnützigen Internet Security Research Group (ISRG) mit den Hauptsponsoren Electronic Frontier Foundation (EFF), die Mozilla Foundation, Akamai und Cisco Systems. Ziel des Projekts ist es verschlüsselte Verbindungen im Internet breit zu etablieren. Um ein X.509-Zertifikat zu erhalten, konnte man bislang eines selbst signieren, was Nachteile mit sich brachte, erhielt dieses mit vielen Restriktionen kostenlos bei StarCom oder musste sich ein solches für eine teils nicht unerhebliche Jahresgebühr bei einer Zertifizierungsstelle wie Thawte, RapidSSL, GEO Trust, GlobeSSL, Comodo oder VeriSign, kaufen.
Wie man ein kostenloses SSL bzw. TLS Zertifikat bei Let’s Encrypt erstellen kann, sodass man es z.B. für einen Apache Webserver oder einen FTP-Server verwenden kann, erkläre ich in folgendem Artikel. Dieses Vorgehen wird im Folgenden in einer Debian Linux Umgebung durchgeführt und kann daher bspw. auch auf dem Raspberry Pi unter Raspbian angewendet werden.
Hinweis: Falls du ein SSL/TLS Zertifikat für z.B. deinem Raspberry Pi mit einer DynDNS Subdomain wie .no-ip.org oder .myfritz.net erstellen möchtest, die häufig verwendet werden, wirst du merken, dass dies auf Grund von einer Beschränkung von Zertifikaten je Domain nicht funktionieren wird. Bei Anbietern wie No-IP.org oder Do.de (meine persönliche Empfehlung) kannst du jedoch für wenige Euro pro Jahr eine eigene Domain mieten, womit du solche Problem umgehst.
Zunächst sollte sichergestellt werden, dass Git installiert wird, da wir später darüber Software der Zertifizierungsstelle Let’s Encrypt herunterladen werden.
sudo apt-get install git
Wir können nun den ACME Client von Let’s Encrypt herunterladen und anschließend mit letsencrypt-auto alle Abhängigkeiten des Clients selbstständig installieren lassen.
cd /opt
sudo git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto --help
Falls ein Dienst, wie ein Webserver, auf Port 80 läuft, muss dieser temporär zur Erzeugung eines Zertifikats gestoppt werden.
Apache2
sudo /etc/init.d/apache2 stop
nginx
sudo /etc/init.d/nginx stop
Jetzt ist es bereits möglich ein Zertifikat zu erstellen. Dazu bedienen wir uns folgender Anweisung. Der Parameter --rsa-key-size gibt dabei die Länge des Zetifikatschlüssels an. Diese liegt normalerweise bei 2048-bit. Wir erhöhen diese im Beispiel auf 4096-bit. Außerdem muss über den Parameter -d angegeben werden für welche Domain bzw. welche Domains das Zertifikat ausgestellt werden soll. Bei Webservern wäre bspw. eine Variante mit und ohne www. sinnvoll. Die erste Domain sollte die Haupt-Domain sein auf der die Anwendung läuft.
Beim ersten Aufruf des Client muss man eine E-Mail-Adresse hinterlegen, die im Falle einer Sicherheitslücke in den Zertifikaten zur Kontaktaufnahme genutzt wird und im Falle dessen, dass man sein Zertifikat verloren hat, zur Wiederherstellung verwendet wird. Außerdem wird man aufgefordert die Nutzungsbedingungen von Let’s Encrypt durchzulesen und diesen zuzustimmen.
./letsencrypt-auto certonly --rsa-key-size 4096 -d domain.de -d www.domain.de
Anschließend sind in dem Ordner unter /etc/letsencrypt/live/domain.de/ (domain.de durch deine Domain ersetzen) folgende Dateien enthalten. Da die Rechte der Ordner sehr restriktiv sind kann man in diesen nur als root Benutzer wechseln.
- cert.pem: Öffentliches Zertifikat
- chain.pem: Intermediate Zertifikat
- fullchain.pem: cert.pem und chain.pem zusammen
- privkey.pem: Privater Schlüssel des Zertifikats
Bevor wir fortfahren sollten wir ggf. den Dienst auf Port 80 wieder starten, damit dieser nicht länger als nötig nicht erreichbar ist.
Apache2
sudo /etc/init.d/apache2 start
nginx
sudo /etc/init.d/nginx start
Abschließend muss das Zertifikat in der Anwendung für die es bestimmt ist eingebaut werden. Da dies bei jeder Anwendung anders funktioniert, empfehle ich in der Dokumentation der jeweiligen Software z.B. Apache2 oder nginx nachzuschlagen.
So einfach ist es ein Let’s Encrypt Zertifikat zu erstellen und zu verwenden. Beachtet werden sollte, dass die Zertifikate nur eine Gültigkeit von 90 Tagen haben. Welche Gründe zu dieser Entscheidung geführt haben erklärt Let’s Encrypt in ihrem Blog. Daher muss das Zertifikat regelmäßig erneuert werden.
Um ein Zertifikat zu erneuern reicht es folgenden Befehl aufzurufen. Dabei muss bei dem Parameter -d die Haupt-Domain des zu erneuernden Zertfikats angegeben werden. Zuvor muss wieder, falls vorhanden, der Dienst auf Port 80 gestoppt werden.
/opt/letsencrypt/letsencrypt-auto --renew certonly -d domain.de
Dies lässt sich auch als Cronjob automatisiert ausführen. Beachtet werden sollte, dass der Dienst, der das Zertifikat nutzt, in der Regel dieses neu einlesen muss oder neugestartet werden muss. Im folgenden Beispiel fügen wir die Zeile am Ende der Crontab Datei ein, welche einmal im Monat das Zertifikat erneuert und den Apache2 bzw. nginx Server automatisch die Konfigurationen neu einlesen lässt. Falls der Editor nano voreingestellt ist lässt sich die Datei mittels STRG + X, Y und Enter speichern.
crontab -e
Apache2
@monthly /opt/letsencrypt/letsencrypt-auto --renew certonly -d domain.de && sudo /etc/init.d/apache2 reload
nginx
@monthly /opt/letsencrypt/letsencrypt-auto --renew certonly -d domain.de && sudo /etc/init.d/nginx reload
Außerdem kann es passieren, dass das Zertifikat aus gegeben Gründen, z.B. Diebstahl des Private Keys, widerrufen werden muss. Auch dieser Vorgang ist mit Let’s Encrypt Zertifikat ganz einfach zu bewerkstelligen.
Um ein Zertifikat zu widerrufen muss folgender Befehl aufgerufen werden. Dabei muss domain.de durch die Haupt-Domain des zu erneuernden Zertifikats ersetzt werden.
/opt/letsencrypt/letsencrypt-auto revoke --cert-path /etc/letsencrypt/live/domain.de/fullchain.pem
53 Kommentare. Hinterlasse eine Antwort
Hallo Jan,
Danke für den Artikel.
Ich habe auch nach deinen Anleitungen meinen kleinen Owncloud-Raspi-Server laufen. Bisher ist der hinter der Fritzbox mit einem eigens signierten Zertifikat erreichbar. Das funktioniert soweit auch ganz gut, aber ohne die gültige Zertifizierungsstelle muss ich auf diversen Programmen und Diensten, die auf die Owncloud zugreifen irgendwelche workarounds zum ignorieren des Zertifikats aktivieren.
Ich habe bereits vorher versucht mit Let’sEncrypt ein Zertifikat zu bekommen dies wurde mir immer mit
„There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: myfritz.net“
quittiert.
Logisch, wenn man bedenkt, wieviele myfritz.net domains es alleine in Deutschland gibt.
Komme ich da ohne eigene dns nicht weiter?
Gruß Johnny
Danke für deinen Hinweis. Habe ich nachgesehen und du brauchst in der Tat i.d.R. eine eigene Domain. Ich habe den Artikel dahingehend überarbeitet.
Hallo Jan,
vielen Dank für die Anleitung.
Kann die Erneuerung des Zertifikats nicht per cron Job automatisiert werden?
Viele Grüße und schöne Feiertage
Natürlich. Ich habe den Artikel dahingehend erweitert. Danke für deine Anregung!
Hallo Jan,
habe das Zertifikat wie von dir beschrieben erstellt.
Leider bekomme ich jetzt die Fehlermeldung „Permission denied“, sobald ich auf den Ordner mit demZertifikat zugreifen möchte.
Habe schon versucht die Schreib- und Leserechte zu verändern, aber ohne Erfolg.
Beste Grüße
Probier mal mit root rechten drauf zu zugreifen. Falls du mit der grafischen oberfläche bzw. dem dateimanager drauf zugreifen willst, gib im terminal bzw console: sudo nautilus
ein. Aber funktioniert nur mit gnome bzw. wenn nautilus installiert ist.
Georg hat das schon ganz richtig erklärt. Habe im Artikel darauf hingewiesen. Danke!
Hallo Jan, ich habe einen Artikel gefunden, der sich mit Let´s Encrypt beschäftigt. Könnte dich und andere interessieren:
http://www.spiegelfechter.com/wordpress/132589/kostenlose-sicherheit-drum-pruefe-was-sich-ewig-bindet
Und dann noch eine Anregung für deinen schönen Blog hier. Wie wäre es, wenn du mal was über E-Book Server schreibst? Ich nenne hier mal „Library aka CPS“ und „bicbucstriim“. Schöne Feiertage weiterhin.
Vielen Dank für die wie immer ausführlichen Info’s. Hätte ich nicht schon ein SSL Zertifikat würde ich mir eins von Let’s Encrypt besorgen.
Grüße
Tom
Hab jetzt zum testen auf einer meiner Seiten das SSL Zertifikat installiert. Funktioniert absolut problemlos. Danke für den Tip 🙂
Beste Grüße
Tom
[…] nächsten Schritte habe ich vom Blogeintrag von Jan Karren: Let’s Encrypt: Kostenloses SSL/TLS Zertifikat erstellen entnommen. Was ihr hier lest ist also nur eine sehr kurze Zusammenfassung eines viel […]
Hallo Jan,
in diesem Artikel wird beschrieben, wie eine Owncloud mit Let’sEncrypt-Zertifikat und dyddns eingesetzt werden kann:
https://decatec.de/home-server/owncloud-auf-ubuntu-server-mit-nginx-mariadb-und-php/
Widerspricht das nicht den hier genannten Erfahrungen, dass dies nicht geht?
Mich interessiert die Absicherung einer Owncloud-Installation auf einem Raspi. Allerdings nutze ich kein dyndns, sondern eine Umleitung auf einer Domain, die mir gehört. Diese Umleitung wird durch ein Skript, das auf dem Raspi läuft, aktuell gehalten. Stellt sich die Frage, ob das mit einem solchen Zertifikat machbar ist.
Hallo Jochen,
ich bin der Autor des von dir genannten Artikels, daher bin ich mal so frei und antworte an dieser Stelle:
Prinzipiell kann man Let’s Encrypt auch mit DynDNS-Domains nutzen. Allerdings hat LE hier ein Limit von: 5 Zertifikate innerhalb von 7 Tagen für eine Domain. Wenn sich natürlich viele Leute, die einen speziellen DynDNS-Dienst nutzen, Zertifikate besorgen, dann ist hier irgendwann mal Schluss und man erhält vom LE-Client eine Fehlermeldung. Ich persönlich hatte mit einer DynDNS-Domain keine Probleme, was allerdings daran liegen kann, dass ich einer der ersten war, die hierfür ein Zertifikat erstellt haben.
Aber selbst wenn das Zertifikat ausgestellt werden kann: Das Problem kann jederzeit wieder auftreten, wenn das Zertifikat nach 90 Tagen erneuert werden muss. Daher würde ich die Verwendung von LE über eine DynDNS-Domain nicht empfehlen.
Es gibt allerdings einen Trick, wie man dieses Problem umgehen kann: Man besorgt sich eine eigene Domain für ein paar Euro im Jahr von einem beliebigen Webhoster. Durch einen CNAME-Eintrag wird dann die Domain mit der DynDNS-Domain verknüpft. Mehr Infos dazu in diesem Artikel: https://decatec.de/home-server/https-fuer-alle-ssl-zertifikate-mit-lets-encrypt-fuer-nginx/
Gruß,
Jan
Hallo,
wichtig ist auch zu wissen, dass man neben Port 80 auch HTTPS-Port 443 freigeben muss (Firewall, eigene Erfahrung), damit Lets Encrypt funktioniert, sonst bekommt man immer eine Fehlermeldung, dass die Domain nicht erreichbar sei.
Und muss man beim Cron-Job nicht erst den Webserver stoppen, wenn man es über das ACME Protokoll macht? (Bei Manual Mode, bei dem ein File auf den eigenen Webserver geladen wird, natürlich nicht)
PS: Als Dyn-DNS-Anbieter kann ich ddnss.de sehr empfehlen
Hallo,
genau das Problem steht mir im Weg!
Ich würde ja im Router auch gerne den Port 80 freigeben … da es sich jedoch um ein Speedport Model handelt geht das nicht (dieser ist laut Fehlermeldung für interne Zwecke reserviert … was zum Kuckuck…). Weiß jemand, wie man das umgehen kann oder hat jemand das gleiche Problem?
Viele Grüße
RMTX99
Hallo zusammen,
bei myfritz.net kam bei mir auch die genannte Fehlermeldung. Aber meine Subdomain bei anydns.info ging dann problemlos.
Ich erstellte das Zertifikat nicht direkt am (Banana) Pi, sondern unter Fedora, wo es sich per „dnf install letsencrypt“ direkt installieren lässt. Dann kommt halt noch etwas Kopiererei
Den Pi musste ich kurzfristig auf exposed host stellen und den Internetzugang der Fritzbox deaktivieren, da die per Port 443 erreichbar ist.
Mein probehalber Test der Erneuerung nach 3-4 Wochen hat nicht geklappt, zu früh sagte letsencrypt. Da bräuchte man in cron ein @bimonthly
Kann ich das Zertifikat eigentlich neben dem Pi auch in die FritzBox einspielen? Die Subdomain ist ja identisch.
Hey Jan,
warum erstellst du mit deiner Anleitung denn kein eigenes Zertifikat für jankarres.de? 😉
LG
Hey, danke für den Beitrag. Leider habe ich negative Erfahrungen mit den kostenlosen Zertifikaten gemacht, die werden dann teilweise vom Browser geblockt und am Ende gehts nichts mehr. ;(
Jetzt hab ich etwas Angst, dass auf einer produktiven Webseite einzusetzen.
Gruß Paul
Toll Anleitung. Vielen Dank dafür.
Ich frage mich wie lange es dauern wird bis kostenpflichtige kleinere SSL Zertifikate vom Markt verschwinden werden.
Beste Grüße
Doktor Geek
Hallo Jan,
ich habe noch einen anderen Beitrag über Let’s Encrypt gelesen, in dem darauf hingewiesen wird, dass durch die vielen Änderungen, die der Let’s Encrypt Client machen kann, durchaus ein Sicherheitsrisiko besteht.
Hier der entsprechende Beitrag: https://www.serverpedia.de/lets-encrypt-gratis-ssl-zertifikate-frei-haus/
Was ist deine Meinung dazu? Ist das nur ein theoretisches Risiko oder durchaus etwas, was man bedenken sollte?
Hallo, danke für die Anleitung. Eine Frage zur Erneuerung des Zertifikats: wenn ich
/opt/letsencrypt/letsencrypt-auto –renew certonly -d domain.de
aufrufe, erhalten ich den Fehler:
„letsencrypt: error: ambiguous option: –renew could match –renew-by-default, –renew-hook“
Mit –renew-by-default kann ich das Zertifikat zwar erneuern, muss dann aber den Dialog bestätigen, womit sich das dann nicht mehr im cron benutzen lässt. Irgendeine Idee?
Mit der zusätzlichen Option „–standalone“ lässt sich Prozess wieder automatisieren. Also:
>> sudo /opt/letsencrypt/letsencrypt-auto certonly –renew-by-default –standalone -d domain.com
Hallo Jan,
auch von mir DANKE für die tolle Anleitung. Habe das im März 2016 umgesetzt und es hat auch alles super funktioniert. Der Cron-Job hat Ende März das Zertifikat erneuert. Leider hat es Ende April nicht mehr automatisch funktioniert. Heute habe ich mal geschaut, was da los ist und siehe da: Das gleiche Problem wie mein Vorgänger BLUET. Der neue Client scheint irgendwie anders zu funktionieren. –renew certonly funktioniert nicht mehr. Irgendjemand eine Idee, wie man das wieder so hinbekommt, das das ein Cron-Job erledigen kann?
Dank Dirks Antwort geht es jetzt auch bei mir wieder. Falls es noch jemanden interessiert, hier mein neuer Eintrag im crontab:
@monthly sudo service nginx stop && /opt/letsencrypt/letsencrypt-auto –renew-by-default certonly –standalone -d domain.com && sudo service nginx restart
mit der Option renew ohne Parameter werden durch die aktuelle Version des Clients alle Zertifikate, die erneuert werden müssen, automatisch erneuert.
Außerdem sollte nginx nicht gestopppt und dann neu gestartet werden, sondern mittels reload die Konfiguration neu eingeladen werden, so dass als Eintrag in Crontab damit empfehlenswert wäre:
@monthly /opt/letsencrypt/letsencrypt-auto renew && sudo service nginx reload
Viele Grüße
irgendwie werden hier doppelte — verschluckt:
@monthly sudo service nginx stop && /opt/letsencrypt/letsencrypt-auto —renew-by-default certonly —standalone -d domain.com && sudo service nginx restart
vor renew und vor standalone müssen doppelte – sein!
Hi, also ich habe das Zertifikat wie beschrieben erstellt und eingebunden bekommen. Danke dafür !
Das ganze läuft auf einem PI hinter meiner Fritzbox auf Port 80 und 443.
Ich habe jetzt einen zweiten PI installiert, der eine getrennten eigenen Domain bedienen soll.
Als Domainnamen sind xxx.spdns.org und yyy.spdns.org registriert. beide erreich ich auch aus dem Internet, die xxx mit https (diese war zuerst da und mit dieser wurde das Zertifikat erstellt.) Die yyy erreiche ich zwar auch (Port 8080) aber nicht auf dem https (433). Ich kann mir auch kein neues (zweite) Zertifikat erstellen. Ich bin newbie, denke aber ich mache hier was prinzipielles falsch. Ich hatte auch bereits beide apache gestoppt.
Danke für eure Hilfe.
T.
Hallo nochmal, keiner eine Idee ?
Hi! Mach doch einfach ein Zertifikat für beide Domains! Beachte, dass insbesondere Subdomains von DDNS Anbietern bei der Vergabe beschränkt werden (nur n Zertifikate pro Stunde).
An die Portfreigabe gedacht?
Melde dich einfach nochmal unter diesem Kommentar!
Hi DANI, danke für die Info, das habe ich gemacht, dass passt auch. Mein Problem ist, wie kann ich das Zertifikat auf den zweiten Server installieren. Also, wo liegt es auf Server1 um es zu kopieren, und wie bekomme ich es auf Server2 eingebunden ? Sicherlich kein Hexenwerk, aber ich bin noch zu frisch im LINUX/UNIX/PI…
Achso ok 🙂
apt-get install rsync
Du erstellst in /opt/copy_certs.sh ein Shell-Skript, das die Zertifikatsdateien bei Änderungen kopiert.
rsync -L /etc/letsencrypt/live/example.tld/fullchain.pem user@server2:/etc/letsencrypt/live/example.tld/fullchain.pem
rsync -L /etc/letsencrypt/live/example.tld/privkey.pem user@server2:/etc/letsencrypt/live/example.tld/privkey.pem
Hinweis: Das Argument -L sorgt dafür, dass die Dateien nur kopiert werden, wenn sie neuer sind. Außerdem muss auf server2 die Ordnerstruktur vorhanden sein (/etc/letsencrypt/live). RSync nutzt SSH, um die Dateien zu kopieren.
Dann noch chmod +x /opt/copy_certs.sh
Zum Test einmal ausführen mit /opt/copy_certs.sh
Also du tragst mit
crontab -efolgendes in die sog. Crontab-Datei ein, die Befehle zu einer bestimmten Zeit ausführen kann. (Hier kommt ja auch der renew Befehl von LE hin)
@monthly /opt/copy_certs.sh
So sollte es gehen…
Hallo DANI, danke. ich bekomme allerdings diese Fehlermeldung:
rsync: mkstemp „/etc/letsencrypt/live/domain.de/.fullchain.pem.YuHZrr“ failed: Permission denied (13)
Was und wie muss ich die Rechtevergabe denn hier für das RSYNC ändern ?
Nimmt denn der server2 dann automatisch das https:// an oder muss ich dem noch sagen, dass er ein Zertifikat hat ?
du machst zuerst
sudo su
und dann crontab -e
damit root rsync aufruft.
Ja, du musst den Webserver wie auf server1 konfigurieren.
Sorry nochmal,
also ich habe das wie unten beschrieben alles geändert und zum testen ausgefhrt.
sudo su war gesetzt. Trotzdem laufe ich in diese Fehler.
root@PI3:/opt# chmod +x /opt/copy_certs.sh
root@PI3:/opt# /opt/copy_certs.sh
pi@nextpi’s password:
rsync: mkstemp „/etc/letsencrypt/live/domain.tg/.fullchain.pem.Y6FfWc“ failed: Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.1]
pi@nextpi’s password:
rsync: mkstemp „/etc/letsencrypt/live/domain.de/.privkey.pem.xb3sNH“ failed: Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.1]
root@PI3:/opt#
Das sieht danach aus, als hätte der User keinen (Schreib)Zugriff auf dem anderen Server (Da bin ich mir allerdings nicht so sicher). Mach halt auf dem anderen Server chown pi /etc/letsencrypt/live (ist ja ein Server hinter nem Router) oder benutze gleich den root User.
Hallo,
ich habe Probleme bei der ab Step 2. Kannst du mir bitte sagen wie ich diesen Fehler beheben kann ?
Ich habe das Log auf Pastebin hochgeladen.
https://pastebin.com/5y4gXPs6
steht doch da, deine pip Version ist zu alt (kommt mit python)
Hast du:
pip install –upgrade pip
probiert ?
Hallo Jan,
wieder mal ein sehr guter Artikel zum Thema Raspberry Pi. Let’s Encrypt hat sich ja in den letzten Monaten wirklich zu einer zuverlässigen Lösungen für Privat und Business gemausert.
Ich würde gerne noch auf zwei Ergänzungen hinweisen, die ich in einem eigenen Artikel verarbeitet habe:
https://www.ionas-server.com/blog/lets-encrypt-zertifikat-mit-dem-raspberry-pi/
1) man kann let’s encrypt auch so verwenden, dass man nur den Port 443 öffnet. Das ganze geht mit sogenannten pre-hooks und post-hooks. Vereinfacht gesprochen, beendet der acme-bot kurz den Webserver, startet einen eigenen kleinen Webserver, der auf Port 443 auf die Antwort der Zertifizierungsstelle horcht.
2) du beschreibst nur die Einrichtung unter Apache, jedoch setzen viele User ganz bewußt nginx auf einem Raspberry Pi ein, da dieser weniger Ressourcen verbraucht.
Vielleicht hilft es ja dem einen oder anderen.
Viele Grüße
Christoph
Hallo Jan,
ich habe auf meinem Raspperry Pi eine Seafile Cloud eingerichtet und die Verbindung mittels Let’s Encrypt Zertifikat verschlüsselt. Dabei habe ich mich an diese Anleitung gehalten: https://blog.tausys.de/2016/02/02/lets-encrypt-nginx-und-viele-hosts/
Bisher funktioniert auch alles soweit. Allerdings hätte ich noch einige Verständnisfragen zu diesem Vorgehen.
1. Was hat es mit dem Webroot auf sich? Welche Funktion steckt dahinter bzw. wie funktioniert es?
2. Warum muss ich beim Let’s Encrypt Zertifikat diesen Weg gehen? Warum funktioniert es nicht so wie bei einem selbst erstellten Zertifikat, indem ich einfach den Pfad der Zertifikate in der entsprechenden Config-Datei des Nginx-Servers anpasse?
Viele Grüße
Simon
Hallo,
ersteinmal vielen Dank für die Anleitung!
Wenn ich versuche, mein Zertifikat zu erneuern erhalte ich folgende Fehlermeldung:
/opt/letsencrypt/letsencrypt-auto –renew certonly -d xxx.spdns.de
Requesting root privileges to run certbot…
/home/pi/.local/share/letsencrypt/bin/letsencrypt –renew certonly -d xx.spdns.de
usage:
letsencrypt-auto [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] …
Certbot can obtain and install HTTPS/TLS/SSL certificates. By default,
it will attempt to use a webserver both for obtaining and installing the
cert.
certbot: error: ambiguous option: –renew could match –renew-by-default, –renew-with-new-domains, –renew-hook
Hat jemand einen Tipp?
Was tippst du den genau ein wenn du wes erneuern willst? Hast du evtl. vor dem Befehl kein „sudo“ gesetzt?
Ich verwende folgenden Befehl:
/opt/letsencrypt/letsencrypt-auto –renew certonly -d mapi.spdns.de && sudo /etc/init.d/apache2 reload
(wie in der Anleitung beschrieben)
Ich erhalte die Fehlermeldung auch, wenn ich den Befehl als root ausführe.
Ergänze mal dein: -renew
Bitte mit: –renew
hmm..strange mach einfach vor dem renew noch einen zweiten bindestrich das du dann zwei aufteinander folgende hast. Des Wird hier irgendwie net dargestellt.
fallls das net klappt probiere es mit:
„renew-by-default“ anstelle von „renew“
Hi,
bei mir wurde ebenfalls ein Bindestrich entfernt…
Mit dem Befehl „renew-by-default“ funktioniert nun auch das Erneuern des Zertifikats! Danke!!!
Ich musste statt „/etc/init.d/apache2 reload“ „/etc/init.d/apache2 restart“ verwenden.
Das im Beitrag beschriebene Tool „letsencrypt-auto“ ist veraltet. Alternativ lässt sich das Tool Certbot verwenden.
Ich habe mir die aktuelle lets encrypt-config heruntergelden ( sudo git clone https://github.com/letsencrypt/letsencrypt) und dann den Befehl ./certbot-auto renew –force-renew eingegeben. Ich erhalte jedoch folgende Fehlermeldung:
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for xxx.spdns.de
Error while running apache2ctl graceful.
httpd not running, trying to start
Action ‚graceful‘ failed.
The Apache error log may have more information.
AH00112: Warning: DocumentRoot [/var/lib/letsencrypt/tls_sni_01_page/] does not exist
AH00558: apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1. Set the ‚ServerName‘ directive globally to suppress this message
(98)Address already in use: AH00072: make_sock: could not bind to address [::]:443
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443
no listening sockets available, shutting down
AH00015: Unable to open logs
Was mache ich falsch???
Hallo,
Kannst du bitte die Anleitung hinsichtlich der Zertifikatserneuerung überarbeiteten?
Vielen Dank!
Marco
Hallo,
wie funktioniert das denn, wenn ich tunnel?
Ich habe einen DS-Lite anschluss, meine Domain Zeigt auf einen VServer, und der Tunnelt alle anfragen zu meinem Webserver Zuhause.
Ich bekomme folgende Fehlermeldung:
IMPORTANT NOTES:
– The following errors were reported by the server:
Domain: ger-ducks.de
Type: connection
Detail: Connection refused
Domain: http://www.ger-ducks.de
Type: connection
Detail: Connection refused
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.
Hallo Jan,
dein Artikel mag zwar schon etwas älter sein, ich habe jedoch eine aktuelle Frage zum Thema. Ich bin nämlich ziemlich verunsichert zu erkennten, welche SSL-Zertifikate sicher sind. Wie hier zu lesen ist, entzieht Google seit geraumer Zeit einigen CAs das Vertrauen. Woran kann ich festmachen, ob eine CA davon betroffen sein wird und wie sieht es bei kostenlosen SSL-Zertifikaten von Let’s Encrypt aus?
Vielen Dank im Voraus!!
Hallo,
was muss ich machen, damit der Befehl ./letsencrypt-auto certonly –rsa-key-size 4096 -d domain.de -d http://www.domain.de
ein Zertifikat in /etc/… wie oben beschrieben, erzeugt? Das stimmt so nicht mehr. Ich bekomme eine komische Abfrage:
1: Spin ab a….
2: Place files in….
Egal was ich bestätige, es kommt zum Abbruch. Und in /etc/… steht nicht, wie oben bschrieben, das Zertifikat.
Danke für deinen Tipp mit No-IP.org oder Do.de, ohne diesen Tipp hätte ich viel Zeit unnötigerweise verloren. Dafür danke ich dir!