Let's Encrypt: kostenlose SSL-Zertifikate

  • Ab sofort steht euch hier im Forum die neue Add-on Verwaltung zur Verfügung – eine zentrale Plattform für alles rund um Erweiterungen und Add-ons für den DSM.

    Damit haben wir einen Ort, an dem Lösungen von Nutzern mit der Community geteilt werden können. Über die Team Funktion können Projekte auch gemeinsam gepflegt werden.

    Was die Add-on Verwaltung kann und wie es funktioniert findet Ihr hier

    Hier geht es zu den Add-ons

Status
Für weitere Antworten geschlossen.
Was auch neben anderen Varianten in der Client-Sammlung zu finden ist, die in #85 verlinkt ist.
 
Und wiedermal zeigt sich was für ein DAU ich bin.

Ich hab jetzt versucht mit der Anleitung von hier:
http://linuxundich.de/gnu-linux/ssl-zertifikat-lets-encrypt-synology-nas/
Die SSL Sachen zu installieren.

Dazu hab ich versucht den ACME Client zu installieren. Nach jener Anleitung: https://thomas-leister.de/internet/anleitung-fuer-lets-encrypt-kostenlose-tls-zertifikate-fuer-alle/

./letsencrypt-auto certonly --rsa-key-size 4096 -d xxx.de yyy.de

Dann kommt:
Syno> ./letsencrypt-auto certonly --rsa-key-size 4096 -d xxx.de
grep: /etc/os-release: No such file or directory
grep: /etc/issue: No such file or directory
Sorry, I don't know how to bootstrap Let's Encrypt on your operating system!

You will need to bootstrap, configure virtualenv, and run a pip install manually
Please see https://letsencrypt.readthedocs.org/en/latest/contributing.html#prerequisites
for more info
./letsencrypt-auto: line 170: command: not found
./letsencrypt-auto: line 170: command: not found
./letsencrypt-auto: line 170: command: not found
./letsencrypt-auto: line 170: command: not found
Cannot find any Pythons... please install one!
sh: line: bad number
sh: line: bad number
Creating virtual environment...
./letsencrypt-auto: line 170: virtualenv: not found

Hat jemand das Lets Encrypt auch schon mit dem Lets Encrypt Skript und dem ACME Client versucht zu installieren und ist hierüber gestolpert?
 
Hat jemand das Lets Encrypt auch schon mit dem Lets Encrypt Skript und dem ACME Client versucht zu installieren und ist hierüber gestolpert?

jupp siehe mein Beitrag #62. ... wollte dann über eine Linux Maschine das dann manuell erledigt und da scheiterte ich an einer fehlenden IPv6 Unterstützung seitens LetsEncrypt, denn dank DSLite bin ich über IPv4 nicht erreichbar
 
Zuletzt bearbeitet:
Es gibt wie gesagt ja auch andere Clients, bspw. per php.
Fefe's macht ja keinen Hehl aus seinen mitunter radikalen Meinungen. Auch hier darf man durchaus hinterfragen: Vertraut Fefe dem Zertifikats-System nicht etwas zu sehr? Aus seinem Post lese ich durchaus gewisses Vertrauen demgegenüber. Was ist besser: Einfach zu generierende Zertifikate die sich jeder ausstellen kann, was die Prozentzahl an verschlüsselter Kommunikation stark erhöhen dürfte, oder ein System das eher versierten Anwendern bzw. Fachpersonal und Unternehmen offensteht, den Normalanwender aber aufgrund seiner Komplexität "aussperrt". Nur so als Diskussionsanstoß.

MfG Matthieu
 
... Was ist besser: Einfach zu generierende Zertifikate die sich jeder ausstellen kann, was die Prozentzahl an verschlüsselter Kommunikation stark erhöhen dürfte, oder ein System das eher versierten Anwendern bzw. Fachpersonal und Unternehmen offensteht, den Normalanwender aber aufgrund seiner Komplexität "aussperrt".
Ja, gerade hier sehe ich auch einen der Haken in den letzten Jahren - Komplexität wirkt in der Breite abschreckend. Wobei man ja noch im Zertifikat-System unterscheiden muss - zwischen der technischen Sicherheit von Zertifikaten an sich und dem Vertrauenssystem. Ersteres ist unbestritten, bei letzterem teilen sich die Geister. Ich persönlich sehe daher den besten Weg darin, ein einfaches Zertifikatssystem zur Erzeugung zu etablieren - auch mit entsprechenden Settings/Infos zu den verwendeten Parametern-, kombiniert mit entsprechend neu etablierten Vertrauensankern, losgelöst von hierarchischen Strukturen. DNSSEC/DANE und gepinnte Zertifikate sind Beispiele, die ich teilweise hier ja auch schon beleuchtet hatte - wenn so etwas automatisiert läuft (bspw. auf einer DS), wird das der Verschlüsselung und dem Vertrauen darin enormen Vorschub geben.
 
Was ist besser: Einfach zu generierende Zertifikate die sich jeder ausstellen kann, was die Prozentzahl an verschlüsselter Kommunikation stark erhöhen dürfte, oder ein System das eher versierten Anwendern bzw. Fachpersonal und Unternehmen offensteht, den Normalanwender aber aufgrund seiner Komplexität "aussperrt". N
ich verstehe nicht so ganz wieso das C&P eines CSR in ein Formular eines Cert-Anbieters soo kompliziert sein soll. Sorry aber wer einen Sever betreibt soll sich auch mit der Materie auseinandersetzen. Ein openssl Kommando abzutippen ist echt nicht viel schwieriger als die Installation des letsencrypt Paketes.
 
ich verstehe nicht so ganz wieso das C&P eines CSR in ein Formular eines Cert-Anbieters soo kompliziert sein soll.
Ich sehe das prinzipiell ähnlich, die Diskussionen im Forum zu diesem Thema deuten aber auf etwas anderes hin. Das Erneuern der Zertifikate finde ich im übrigen auch nicht so prickelnd. Auch empfinde ich die "Durchschnittspreise" als zu hoch. Mal hat man halt etwas mehr als 1 oder 2 Domains und wenn man Wildcard oder ein Zertifikat für mehrere Domains möchte, wird man ganz schön zur Kasse gebeten.

MfG Matthieu
 
bei den (Mond)preisen bin ich bei dir. Das ist echt ne Sauerei was dafür verlangt wird. Wer weiss vielleicht gibt es durch letsencrypt Druck auf die Preise der anderen Anbieter?
Handkehrum muss man sagen: der Otto-Normal-User könnte imho auch mit der Warnung eines selbst signierten Zertifikates leben. Wer prüft schon den Fingerabdruck eines Certs? :-)
Viele Normaluser haben halt das Gefühl, dass die Sicherheit erhöht würde durch ein offizielles Cert, was natürlich Quatsch ist,aber bring das denen mal bei ;-) In Zukunft ist es gut möglich, dass Browser selber signierten Certs ohne Warnung vertrauen, wenn DANE/TLSA Records vorhanden sind, welche mit DNSSEC gesichert sind. Das wird aktuell recht heftig diskutiert. Vom Standpunkt der "Vertaulichkeit" einer Verbindung her ist es besser ein selbst signiertes Zertifikat einzusetzen, dafür aber mit TLSA und DNSSEC gesichert, als ein vertrauenswürdig signiertes Cert ohne DNSSEC & Co
 
...In Zukunft ist es gut möglich, dass Browser selber signierten Certs ohne Warnung vertrauen, wenn DANE/TLSA Records vorhanden sind, welche mit DNSSEC gesichert sind. ...
Nach der jüngsten Reservierung eines SMIMEA-Records zum bereits bestehenden TLSA wird da im Hinblick auf stärkere DANE-Unterstützung sicher ein wenig mehr Fahrt gewonnen - allgemeinverfügbare email-Verschlüsselung ist ein aktuell mehr als drängendes Problem. Auch alternative Wildwüchse à la "Email made by Germany" wurden zum Glück zugunsten von DANE aufgegeben - von daher denke ich werden wir im ersten Halbjahr 2016 spürbare Schritte erleben. Bei Let's Encrypt dann übrigens auch mit dem Wechsel in Richtung ECC - ein weiterer Grund, warum sich hier ein Generationswechsel anbahnt.
 
leider sträuben sich noch viele gegen DNSSEC, was die Grundlage wäre für DANE/TLSA. Noch nichtmal im Onlinebanking, wo man mit DNSSEC wirklich mehr Sicherheit bieten könnte, sieht man Banken mit gesicherten Records (zumindest bei uns). Bei uns bieten einige grosse (u.a. auch der grösste) Emailprovider die SSL gesicherte Verschlüsselung für eingehende Mails an Port 25 schlicht nicht mehr an. Damit ist für diese Kunden dann auch DANE hinfällig. Andere fahren die angebotene Chiphren soweit runter, dass man gleich darauf verzichten könnte ;-)
 
Noch nichtmal im Onlinebanking, wo man mit DNSSEC wirklich mehr Sicherheit bieten könnte, sieht man Banken mit gesicherten Records (zumindest bei uns).
Das liegt aber eher daran, dass die meisten Banken über Jahre hinweg das Thema Onlinesicherheit vernachlässigt und schlichtweg per Outsourcing gelöst haben... Und was die Jungs da liefern, ist nun nicht das Gelbe vom Ei - bis vor einem guten Jahr nutzten Banken zu über 80% RC4 als favorisierte Cipher! Abgesehen davon - in der Bankenwelt ticken die Uhren anders. Wer sich mal mit der Geschichte des MM-Moduls einer Zahlungskarte beschäftigt - ein Inselfeature aus grauer Vorzeit-, staunt mehr als große Klötzchen...
 
Dabei sind wir gefühlt in Europa schon deutlich besser dran als die in Amerika, wo viele Terminals im Handel mit den Smartcards nicht umgehen können und daher auf die Magnetstreifen angewiesen sind.

MfG Matthieu
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat