Bericht Let's Encrypt: Erste Erfahrungen mit dem HTTPS für jedermann

Domi83 schrieb:
Ich weiß ja nicht was LE für Zertifikate ausstellt, aber wenn es keine Wildcard Zertifikate sind, muss für jede Subdomain ein separates Zertifikat erstellt werden. Das heißt, wenn domain.tld ein Zertifikat bekommt, muss dieses nicht mal für www.domain.tld gültig sein.

Ist es auch nicht, aber Du kannst alle in einem Rutsch beantragen ...-d example.com -d www.example.com -d sub1.example.com -d sub2.example.com ....-d sub10.example.com
 
T0a5tbr0t schrieb:
Blog, ohne vernünftig funktionierende Verschlüsselung, kritisiert eine Initiative um Verschlüsselung einfacher zum machen. Super Beispiel.

vor allem nur die Referenz-Implementeirung. Das Protokoll ist aber offen - das hat fefe sogar gemerkt, als er auf die "einfache" Alternative verwiesen hat.
Aber kein Wort zur Automatisierung oder anderen wesentlichen Punkten.
Und selbst eine nett gesagt komische Konfig auf dem Server haben:rolleyes:
 
fethomm schrieb:
Es gibt ein Plugin für IIS aus der Community. Kann ich aber nichts zu sagen.
Ich hab's heute auf meinem Windows Server 2012R2 eingerichtet, über https://gethttpsforfree.com/ ohne Plugin.

Es geht einfacher, wenn man sich für die Kommandozeilenbefehle einfach eine Linux-VM aufsetzt.

Es geht auch komplett in Windows. Dazu OpenSSL-Binaries runterladen, zB unter https://slproweb.com/products/Win32OpenSSL.html (die Light reicht völlig; achtung: er will die OpenSSL-Binaries standardmäßig ins Windows-Verzeichnis kopieren, eventuell will man das nicht).

Jetzt die Website gethttpsforfree abarbeiten. Man muss jetzt ein paar Sachen anders machen, wie zB die cat und echo-Befehle ersetzen (s.u.). Das betrifft:

Schritt 2:

Den SAN-Block in die openssl.cfg ans Ende manuell eintragen:
Code:
[SAN]
subjectAltName=DNS:<domain-1>,DNS:<domain-2>

danach den Befehl ohne CAT ausführen:

Code:
openssl req -new -sha256 -key domain.key -subj "/" -reqexts SAN

Schritt 3:

Hier hat das Windows-echo leider komisches Verhalten mit trailing Spaces und Line Breaks, weshalb das mit der Pipe nicht so recht tut (kommen halt andere Hex-Werte raus).
Die zu encodierenden Strings kann man aber auch in eine Textdatei speichern, und dann per type angeben (mühselig, aber tut):

Code:
type text.txt | openssl dgst -sha256 -hex -sign account.key

Schritt 4

Das Verifzieren des Servers macht man am besten über die zweite Option (Textdatei). Die Datei einfach wie beschrieben anlegen.

Problem 1: mit dem Explorer kann man keine Ordner, die mit eine Punkt anfangen, anlegen. Also mkdir benutzen.
Problem 2: der IIS liefert standardmäßig keine Dateien ohne Endung aus, dafür muss man in dem Ordner acme-challenge eine Web.config erzeugen, die folgendes enthält:

Code:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <staticContent>
            <mimeMap fileExtension="." mimeType="text/plain" />
        </staticContent>
    </system.webServer>
</configuration>

PFX erzeugen und importieren
Danach bekommt man ein Zertifikat und ein Intermediate-Zertifikat.
Beide zusammen (wie beschrieben) in eine PEM-Datei kopieren, und dann aus der domain.key und der .pem eine pfx für den IIS erzeugen:

Code:
openssl pkcs12 -export -in chained.pem -inkey domain.key -out my.pfx

Wenn beim Setzen der Bindings im IIS der unten stehende Fehler kommt, dann die .pfx statt unter "Webhosting" manuell in den privaten Zertifikatspeicher importieren.
http://stackoverflow.com/questions/...ssion-does-not-exist-it-may-already-have-been

Wenn gewünscht, kann ich das auch noch etwas ausarbeiten und zB im Windows Server-Forum posten...
 
Zuletzt bearbeitet:
Domi83 schrieb:
Ah mit dem Suchbegriff finde ich auch endlich mal etwas bei Google :) Das LE das nicht anbietet, habe ich mir fast gedacht und war auch nicht mein Ziel. Mich interessierte halt nur, wie man in das System (die Browser) mit seinen eigenen Zertifikaten rein kommt und die Browser das auch selbst akzeptieren ohne "Ausnahmen hinzuzufügen" ;)

Ach so. Also wenn es nur um eine begrenzte und bekannte Anzahl von Clients geht, dann kann man sich auch seine eigene CA aufsetzen und das Stammzertifikat dieser CA in die Liste der vertrauenswürdigen Stammzertifizierungsstellen im Browser importieren. Dann geht das Ganze auch ohne externe Signierung deiner eigenen CA. Wenn es "einfach so" weltweit funktionieren soll, dann nur mit einer Signierung einer CA die bereits "vertrauenswürdig" ist.
Hier auf unserer kleinen Insel (-> Firma ;)) haben wir das ganz einfach mit der Windows CA gemacht. Wenn sie installiert wird, verteilt sich das Stammzertifikat auf alle Domänenmitglieder und man kann dann vertrauenswürdige Zertifikate für alles mögliche erstellen. Authentifizierung, SSL, Codesigning usw. Externe Rechner erkennen diese Zertifikate natürlich nicht an, weil sie das Stammzertifikat nicht kennen. Da ist die Grenze der ganzen Geschichte, denn wir haben unsere CA nicht signieren lassen. Viiiiel zu teuer.
 
T0a5tbr0t schrieb:
Wie bitte kommt man dann an den Webserver? Programmiert man mal eben selber?
Dass das Einrichten von Verschlüsselung unnötig schwer ist, ist kein Naturgesetz oder so. Wenn das aufsetzen eines Webservers einfacher geht, als das einrichten von einem Zertifikat, läuft generell was schief.

Das sind ein paar Zeilen in der Config. Wer so ein Tool verwendet, dürfte mit einer einfachen Server Konfiguration bedient sein. Ich gehe nicht davon aus, dass jemand große Webserver betreibt, aber kein SSL konfigurieren kann. Die Zielgruppe dürften kleine bis mittelgroße Websites sein.
 
Die Plesk Extension ist verfügbar. Habe es heute getestet. Man wählt einfach eine Domain aus seiner Liste aus, gibt seine Emailadresse an und klickt auf Zertifikat erstellen. Keine 10 Sekunden später ist die Seite über HTTPS erreichbar und Plesk kümmert sich automatisch um das erneuern. Man muss nichts einstellen. Perfekt für Hobby-Admins.
 
T0a5tbr0t schrieb:
Blog, ohne vernünftig funktionierende Verschlüsselung, kritisiert eine Initiative um Verschlüsselung einfacher zum machen. Super Beispiel.

Aha, nur weil Felix sich zu fein ist, ein Zertifikat einer etablierten CA für seine Domain zu bezahlen, und stattdessen auf eine offene CA setzt, die aber noch nicht in den Browsern steckt, ist es nicht vernünftig konfiguriert?

Das SSL von seinem Blog ist besser konfiguriert als das von vermutlich 80% der Websites im Netz, siehe SSL-Test von Qualys.
https://www.ssllabs.com/ssltest/analyze.html?d=blog.fefe.de&s=2001:4d88:3508:0:0:0:fefe:b106&latest
Das einzige was eben bemängelt wird, ist, dass dem Zertifikat nicht vertraut wird. Und das auch nur, weil CACert nicht im Browser / SSL-Test integriert ist.
Und egal was man persönlich von ihm denkt, seine technischen Statements bezüglich solcher Themen sind mitunter die, die ich am meisten respektiere. Vermutlich noch mehr als das C++ gebashe von Torvalds.


BTT:
Ich finde die Idee hinter dem Projekt super, und auch, dass das ganze recht schnell umgesetzt wurde. Ebenso finde ich es super, dass sie IdenTrust für's Cross-Signing für sich gewinnen konnten, damit die alten Browser nicht rum heulen, weil das Cert ja nicht von ihren CA's signiert wurde.

Dazu machen sie beim "Certificate Transparency"-Projekt mit, was auch für sie spricht.
Übrigens auch mal interessant für alle, die es noch nicht kennen: Alle beteiligten CA's listen dort ihre ausgestellten Zertifikate auf.
Hier für LE: https://crt.sh/?Identity=%&iCAID=7395

Was mich aber enorm an diesem ganzen Projekt stört, ist das, was auch Fefe bemängelt: Ich habe mir meinen Server extra so eingerichtet, dass ich möglichst wenig Software vertrauen muss. Und die Software, die ich brauche (nginx, postfix, openssl etc.), compile ich mir nach jedem größeren Update dieser Software selbst neu, um A) alle wichtigen Updates & Features zu haben (Ist unter Jessie sonst recht umständlich, also die Features. Siehe http2 unter nginx. (Jessie Stable steht bei 1.6.2, http2 gibt es seit 1.9.5 & aktuell ist 1.9.7)) und B) auch wirklich die Software aus den öffentlichen Sources zu bekommen.

Und jetzt soll ich mir für ein stinknormales SSL Zertifikat einen Client runterladen, der root Rechte will, um mir anschließend einen Haufen Software zu installieren (Vermutlich noch einmal soviel, wie ohne LetsEncrypt auf dem Server)?
Wenn es einen vernünftigen "Uninstaller" gäbe, würde ich es vermutlich sogar machen.
Cronjob 1x alle 30 Tage, installiert den Client+Packages, erneuert das Cert, deinstalliert sich clean & lässt nur den Config-Ordner unter /etc zurück.

Alternativ bieten sie ja noch ein Docker-Image an, aber mir Docker installieren ist eine ähnlich schlechte Idee.

Ich setze hier auch auf gethttpsforfree.com, auch wenn ich jetzt brav jeden zweiten Monat per Hand meine Zertifikate verlängern lassen muss.

Wer nur zum Spaß seinen Server betreibt - gerne. Aber wer sich wirklich Mühe macht, den Server sicher zu halten - nein danke.
Dann entweder per Hand, 1x im Jahr die 10€ für's Comodo-Zertifikat oder eben StartSSL.
Von StartSSL bin ich aber auch nicht der riesen Fan, die lassen sich das Revoken ganz gut bezahlen. Dann lieber Comodo @ Namecheap, 10€/Jahr & so oft Revoken wie ich will & dazu nur 1x einrichten.
 
Zuletzt bearbeitet von einem Moderator:
Snowi schrieb:
Was mich aber enorm an diesem ganzen Projekt stört, ist das, was auch Fefe bemängelt: Ich habe mir meinen Server extra so eingerichtet, dass ich möglichst wenig Software vertrauen muss. Und die Software, die ich brauche (nginx, postfix, openssl etc.), compile ich mir nach jedem größeren Update dieser Software selbst neu, um A) alle wichtigen Updates & Features zu haben (Ist unter Jessie sonst recht umständlich, also die Features. Siehe http2 unter nginx. (Jessie Stable steht bei 1.6.2, http2 gibt es seit 1.9.5 & aktuell ist 1.9.7)) und B) auch wirklich die Software aus den öffentlichen Sources zu bekommen.

In dem Fall gilt für dich das gleiche, was ich mir auch schon bei Fefes Eintrag gedacht habe: Ihr seid absolut nicht die Zielgruppe von Let's Encrypt. Eure Webseiten laufen auch so schon verschlüsselt und eure Server sind sicherer als die Mehrheit im Internet. Das ist toll und soll auch so bleiben.

Auf der anderen Seite gibt es immer noch unendlich viele Webserver, die nicht einmal schlecht konfiguriertes HTTPS anbieten, sondern nur im Klartext kommunizieren. Hier und nirgendwo anders will Let's Encrypt ansetzen und damit einen Schritt in Richtung vollständiger Abschaffung des unverschlüsselten Internetverkehrs gehen. Die Automatisierung und Konfigurationshilfen die man in dem Zusammenhang anbietet sind dafür mMn zwingend notwendig, um die entsprechende Zielgruppe zu erreichen.
 
tiash schrieb:
In dem Fall gilt für dich das gleiche, was ich mir auch schon bei Fefes Eintrag gedacht habe: Ihr seid absolut nicht die Zielgruppe von Let's Encrypt. Eure Webseiten laufen auch so schon verschlüsselt und eure Server sind sicherer als die Mehrheit im Internet. Das ist toll und soll auch so bleiben.

Auf der anderen Seite gibt es immer noch unendlich viele Webserver, die nicht einmal schlecht konfiguriertes HTTPS anbieten, sondern nur im Klartext kommunizieren. Hier und nirgendwo anders will Let's Encrypt ansetzen und damit einen Schritt in Richtung vollständiger Abschaffung des unverschlüsselten Internetverkehrs gehen. Die Automatisierung und Konfigurationshilfen die man in dem Zusammenhang anbietet sind dafür mMn zwingend notwendig, um die entsprechende Zielgruppe zu erreichen.

An sich gebe ich dir recht, jedoch kommt hier wieder der Python-Client ins Spiel:
Der Installer für Apache läuft laut Netzgemeinde eher schlecht als recht, alle anderen quasi gar nicht.
Also muss man sich als User zurzeit noch immer seine Konfiguration im Netz zusammensuchen.
Aber gut, ist noch Beta, daher nachvollziehbar. Zertifikate ausstellen funktioniert ja schon mal.

Andererseits muss ich mich fragen, ob jemand der nicht in der Lage ist, ein paar Zeilen einer nginx/Apache Konfiguration aus der Dokumentation zu copy-pasten, einen eigenen Server betreiben sollte.
Ich will nicht so klingen, wie all die Leute, die ständig nur andere Leuten bashen, weil die sich einen 5€-vServer für TS + Clan Website mieten wollen.

Aber wer nicht in der Lage ist, weniger als 15 Zeilen von einer Website in seine Config zu pasten, sollte keinen Server administrieren. Denn das wird man für genau das als unwissender des öfteren tun müssen.

An den tausenden Websites, die bei unterirdisch schlechten Anbietern laufen, die von Geldgeilheit geplagt sind, kann LetsEncrypt leider nichts ändern, das macht aber auch einige Websites da draußen aus. Und eben diese miesen Anbieter, werden einen Teufel tun, ihren Usern kostenloses SSL anzubieten, statt einen saftigen Bonus zu verdienen, um ein Perl-Script ein gekauftes Zertifikat installieren zu lassen.
Diese User können glücklicherweise aber zB CloudFlare incl. SSL-Proxy 4free dazwischen klemmen.

Aber ja, es ist ein Schritt in die richtige Richtung, und das Projekt an sich finde ich noch immer super :)
Dennoch finde ich den Ansatz eines 30k+ Zeilen Python-Clients nicht gerade anregend..
(30k habe ich irgendwo gelesen, keine Ahnung wo. Habe aber mal kurz @ Github geschaut, könnte ganz gut hinkommen.)
 
Snowi schrieb:
A

An den tausenden Websites, die bei unterirdisch schlechten Anbietern laufen, die von Geldgeilheit geplagt sind, kann LetsEncrypt leider nichts ändern, das macht aber auch einige Websites da draußen aus.

Wie gesagt, gerade für die Leute mit ihren 5 Euro Virtual Servern ist es doch jetzt perfekt. Hier auf dem ersten Screenshot sieht man schon das komplette Formular welches man ausfüllen muss um ein Zertifikat für seine Domain zu erhalten: https://ext.plesk.com/packages/f6847e61-33a7-4104-8dc9-d26a0183a8dd-letsencrypt

Ich könnte das Client gebashe ja verstehen wenn dieser nicht Opensource ist sondern nur als Binary vorliegen würde und es keine Alternativen gäbe. Aber jetzt gibt es schon eine Webseite, einen Offline ACME Client, den offiziellen Client und Plesk. Wie man da immer noch meckern kann verstehe ich nicht.

Und mir ist auch nicht klar warum Fefe geben Python auf dem Webserver bashed. Warum soll das auf einem Webserver nichts zu suchen haben? Ich entwickle alle meine Web Projekte mit Python (Django / Flask). Bei mir hätte dafür PHP nichts zu suchen. Deswegen lasse ich trotzdem keinen unqualifizierten Post raus nur um Aufmerksamkeit zu bekommen. Ich dachte so etwas hat der gute Herr gar nicht nötig wenn er doch schon als Koryphäe gilt.

Hier noch ein Screenshot von meinem Plesk Server mit Zertifikat:
Screen Shot 2015-12-04 at 14.35.33.png
 
Zuletzt bearbeitet:
Falc410 schrieb:
Und mir ist auch nicht klar warum Fefe geben Python auf dem Webserver bashed. Warum soll das auf einem Webserver nichts zu suchen haben? Bei mir hätte dafür PHP nichts zu suchen.

Also du würdest ohne jegliches Murren sofort PHP installieren nur um das Zertifikat nutzen zu können ?
Warum man nicht auf die gängigen tools baut ist mir ein Rätzel.
 
@CvH

Noch mal ein Kaffe drinken ;) Er schreibt ja es hat NICHTS auf seinem Server zu suchen. Kann ich auch nachvollziehen als jemand der auch aus dem Django Bereich kommt. Hätte PHP aber nicht einfach diese deutlich erleichterungen in gewissen Sachen wäre ich noch auf Django statt Drupal. Ich will es nicht mehr missen mit einem Klick ein Addon zu installieren und nicht erst in der settings.py und der urls.py zu arbeiten.
 
Mir ging es darum das die PHP "Leute" (im Falle von FeFe weder noch) sich beschweren das sie Python installieren müssen, aber die Python Leute doch das selbe Problem hätten sich PHP zu installieren (wenn es ein PHP client wäre) nur um das Zertifikat nutzen zu können. Ich installiere mir keine sinnlose Abhängigkeit die ich nicht brauche auf den Server, wieso auch.
 
Achso, stimmt aber nicht ganz. Es kommt ganz auf die Installation des Servers an. Wenn dies z.B. ein LAMP Installation ist, ist PHP schon mit dabei. Daher auch der Name Linux Apache MySQL PHP.

Dazu kommt Python ist bei "jedem" Linux dabei. Also muss man da nichts installieren.
 
Wie ihr schon richtig erkannt habt, egal wie der Client geschrieben ist - man braucht immer etwas. Wobei Python und PHP nun wirklich weit verbreitet sind - auch auf Webservern. Hätten Sie es nur in Bash geschrieben, würden die Powershell Windows Admins aufschreien. Ebenso wenn es nur ein Binary gäbe. Oder der Client wurde in C geschrieben - aber ein gcc hat nun wirklich nichts auf einem Webserver zu suchen. Wie man es dreht und wendet, irgendwas braucht man immer.
Persönlich fand ich den Schritt Python zu benutzen logisch, aber wie man halt sieht kann man es nie allen Recht machen. Da kommen dann eben alternative Clients ins Spiel.
 
Wie ich schon sagte, LE hätte es einfach so machen müssen wie jede andere CA auch.

CSR in ein Formular eingeben, E-Mail Addresse des Admin-C angeben, diese wird überprüft, und nach einigen Minuten hat man sein Public Zertifikat.

Da brauch es kein Client zumindest keinen den der User sieht und damit würde es auch nicht si viel gemecker geben.
 
Snowi schrieb:
Aha, nur weil Felix sich zu fein ist, ein Zertifikat einer etablierten CA für seine Domain zu bezahlen, und stattdessen auf eine offene CA setzt, die aber noch nicht in den Browsern steckt, ist es nicht vernünftig konfiguriert?

CA? Das Zertifikat wurde von niemanden Unterschrieben. Und wenn doch, warum fehlt dann das Zwischenzertifikat? Du evrweist ja selbst auf SSLlabs:
No trust paths available
Issuer unknown, or intermediate certificate(s) missing.

Ergo: Ein stinknormales selbst erstelltes Zertifikat, ganz ohne sig einer CA, auch nicht von CACert.

Das SSL von seinem Blog ist besser konfiguriert als das von vermutlich 80% der Websites im Netz, siehe SSL-Test von Qualys.
[...]
Das einzige was eben bemängelt wird, ist, dass dem Zertifikat nicht vertraut wird. Und das auch nur, weil CACert nicht im Browser / SSL-Test integriert ist.
Besser ist aber noch lange nicht gut ;)
+ Kein GCM
+ neben kein GCM auch kein SHA256 bei den Ciphers = Keine TLS 2 Cipher Suit
+ Non FS über FS
+ 2048 DHE bei 4096 RSA Zertifikat (inkonsistent)

vielleicht sollte er nochmal bei Mozilla vorbei schauen, die haben ein paar wunderbare Konfigurationsvorschläge.

Cool Master schrieb:
Wie ich schon sagte, LE hätte es einfach so machen müssen wie jede andere CA auch.

und in 90 Tagen hätten wir dann 10000 weitere Seiten mit abgelaufenen Zertifikat, das niemals erneuert wird :rolleyes:
 
Der-Orden-Xar schrieb:
und in 90 Tagen hätten wir dann 10000 weitere Seiten mit abgelaufenen Zertifikat, das niemals erneuert wird :rolleyes:

Wenn ich eine Seite betreibe muss ich eh min. jede Woche auf Updates schauen. Da kann man nach 11 Wochen auch mal ein renew machen.
 
Wenn man es nur mit einem Webformular anbieten würde dann wäre es am Ende ja tatsächlich genau so wie StartSSL, also überhaupt nichts neues und kaum Berichterstattung wert. Der Trend soll hier ganz klar Richtung Automatisierung gehen, was vielen Betreibern von z.B. kleinen Blogs hoffentlich die Furcht vor SSL nimmt.
Zwischen einmal apt-get upgrade (worauf ich je nach vServer Vorkonfiguration sogar direkt beim Login per SSH motd hingewiesen werde) und einem Login bei einer CA + Renewvorgang liegen Welten vom Aufwand her. Zumal ich das Installieren von sicherheitskritischen Updates sogar auch automatisieren kann.
 
Zurück
Oben