Wir hatten diese Diskussion schon.
Auf neue Versionen wird hingewiesen:
Das Changelog sowie die Download-Seiten werden natürlich immer entsprechend aktualisiert. Ein Changelog im APT-File ist derzeit aus technischen Gründen nicht möglich. Der Versand von Postkarten ist aus logistischen Gründen nicht möglich.
Schönes Wochenende. 
Das kommt drauf an was für eine Subdomain Sie anlegen.
Wenn Sie einen SRV-Record bei der Domain "example.org" für Port 1234 TCP benötigen, dann muss die dazugehörige Subdomain i.d.R. "_1234._tcp.example.org" heißen.
Beachten Sie bitte, dass erst mit der aktuellen 1.9-Preview Subdomains mit Unterstrichen im Namen angelegt werden können.
Im Hostingvertrag (oder Angebot) müssen Sie Subdomains erlauben und darunter die Einstellung "eigene DNS-Einträge:" auf "erlaubt" setzen.
Anschließend können Sie über Hosting -> Domains die gewünschte Subdomain anlegen oder bearbeiten und finden dort einen Karteireiter "Eigene DNS-Einträge", wo Sie u.a. auch SRV-Records anlegen können.
Streng genommen geht es ja um "OCSP Stapling" (nicht um OSCP). Beim OCSP-Stapling wird (ganz vereinfacht gesagt) eine von der CA signierte Bestätigung, dass das Zertifikat nicht zurückgezogen wurde, mit dem Zertifikat zusammen an den Client (Browser) gesendet. Wie so eine Nachricht "roh" aussieht kann man z.B. beim SSL-Check auf demo.liveconfig.com anschauen.
OCSP-Stapling erfordert, dass der Server (Apache/NGINX/etc) regelmäßig bei der jeweiligen CA eine solche signierte Bestätigung abholt, um die dann an anfragende Clients mit auszuliefern.
Bei Apache ist das ab Version 2.3.3 implementiert, bei NGINX ab 1.3.7. Um die Frage von Andreas zu beantworten: nein, da lässt sich leider nichts tricksen (außer: Apache selbst kompilieren oder einen Jessie-Backport installieren).
Prinzipiell ist OCSP-Stapling auch mit anderen Diensten denkbar, da aber der meiste OCSP-Traffic durch Browser erzeugt wird, dürfte das bei allen anderen Protokollen relativ unwichtig sein. Zumal ja ohnehin fraglich ist, wie viele FTP-Clients/MUAs/MTAs/etc. tatsächlich per OCSP die Gültigkeit eines Zertifikats prüfen.
Eine serverseitige Implementierung von OCSP-Stapling in LiveConfig ist nicht unmöglich (das Protokoll ist nicht sooo komplex), kostet aber (geschätzt) mindestens 1-2 Mannmonate. Wir haben das bereits auf der Wunschliste, aber mit sehr niedriger Priorität.
Hauptvorteil von OCSP-Stapling (neben der Entlastung der CAs von OCSP-Requests und somit schnellerem SSL-Erst-Handshake) ist eben die Tatsache, dass die CA so nicht mehr mitbekommt, für welches Zertifikat die Gültigkeit geprüft wird (und somit implizit welche Website ein Browser gerade besuchen will).
[offtopic]So lange man aber das "Safe Browsing" im Firefox/Chrome/etc. nicht abschaltet, wird ohnehin jede angesurfte URL an Google & Co. übermittelt...[/offtopic]
Viele Grüße
-Klaus Keppler
Besser noch ein paar Features (die schon auch nett sind), damit die Bug-Anzahl bloß nicht abnimmt
Von manchen Bugs können wir uns einfach sooo schwer trennen. :p
Spaß beiseite: ein paar "Altlasten" sind auch schon beseitigt, mehr dazu nächste Woche.
Viele Grüße
-Klaus Keppler
Ab sofort werden auch FTPES und POP3/IMAP (STARTTLS) geprüft. Außerdem zeigt der Check nun weitere Infos an, u.a. OCSP-Support auf Port 443, verwendetes SSL-Protokoll sowie den Key-Typ & Größe. Im nächsten Schritt werden die gesammelten Infos aufbereitet und Tipps für eine bessere Konfiguration gegeben. Mit den ganzen Infos kann ja leider nicht jeder auf den ersten Blick etwas anfangen. 
Ab sofort steht eine aktualisierte Preview der Version 1.9.0 (r3635) zum Download bereit. Es gab eine ganze Menge größerer Änderungen und Erweiterungen (siehe Änderungsverlauf auf der Preview-Seite).
Zu den Themen DANE/TLSA und OCSP wird gerade noch die Doku erstellt; sobald diese fertig ist wird die an dieser Stelle noch verlinkt.
Der Server demo.liveconfig.com läuft bereits mit v1.9.0, zudem haben wir DANE/TLSA erfolgreich u.a. auf der Domain @liveconfig.com (sowie natürlich @keppler-it.de) eingerichtet.
Viele Grüße
-Klaus Keppler
Hi,
hier noch ein Link der verschwunden ist: http://www.liveconfig.com/de/kb/3
Ist hier zu finden: http://www.liveconfig.com/wiki/de/ssl4liveconfig
Die alte URL wurde offenbar nicht weitergeleitet - wird gleich behoben.
Ab sofort bieten wir einen neuen Service auf der LiveConfig-Website: der SSL-Check.
Mit dem SSL-Check kann man bequem und blitzschnell die SSL-Konfiguration auf allen wichtigen Standard-Ports prüfen (derzeit: 25 (SMTP), 465 (SMTPS), 587 (Submission), 443 (HTTPS), 993 (POP3S), 995 (IMAPS) und 8443 (LiveConfig). POP3/IMAP mit STARTTLS kommen in Kürze noch dazu.
Der SSL-Check ersetzt ausdrücklich nicht ausführliche Protokolltests wie z.B. den Qualys SSL-Test. Vielmehr soll der SSL-Tests einen schnellen Überblick über alle konfigurierten Zertifikate bieten (Qualys testet derzeit nur Port 443). Zudem zeigt der SSL-Check an, ob DNSSEC für die angegebene Domain aktiviert ist, sowie die für TLSA-Records (DANE) relevanten Zertifikat-/Key-Hashes (mehr dazu in Kürze in einem separaten Beitrag).
SSL-Check: https://www.liveconfig.com/de/sslcheck
Dokumentation: https://www.liveconfig.com/wiki/de/sslcheck
Der SSL-Test wird in der nächsten Zeit noch weiter ausgebaut - insbesondere die häufigsten Fehler (selbstsignierte Zertifikate, unsichere DH-Parameter, etc.) sollen erkannt und entsprechend hervorgehoben werden.
Für Feedback, Anregungen und eventuelle Fehlermeldungen bitte einfach in diesem Thread antworten, oder eine Mail an support@liveconfig.com schicken.
Viele Grüße
-Klaus Keppler
Welche Linux-Distribution bzw. welche Webserver-Software genau läuft denn auf dem neuen Server?
(Apache 2.2, 2.4...?)
Wenn Änderungen überhaupt keine Wirkung zeigen, dann kann das auch insgesamt auf ein Problem in der Apache-Konfiguration hindeuten (die Verzeichnisschutz-Sachen werden in die vhost-Konfiguration unter /etc/apache2/sites-available/<Vertrag>.conf geschrieben - die werden per Reload in den Apache übernommen; wenn aber ein Fehler irgendwo anders in der Apache-Konfiguration besteht, wird der Reload abgebrochen). In diesem Fall kann nur der Hoster selbst weiterhelfen (die können sich aber ggf auch gerne an uns wenden).
Die optionalen PHP-Pakete für Debian wurden eben auf die Versionen 5.4.42, 5.5.26 und 5.6.10 aktualisiert (siehe Wiki).
NEU: ab sofort stehen diese Pakete auch für Debian 8 (Jessie) zur Verfügung. Anders als bei Squeeze/Wheezy werden wir auch für die eigentlich über die Distribution verfügbare Serie (in diesem Fall 5.6.x) eigene PHP-Pakete bereitstellen (bei Jessie ist standardmäßig PHP 5.6.9 dabei).
NEU: ab sofort steht zudem PHP 7.0.0-alpha1 zur Verfügung. Vom produktiven Einsatz rät das PHP-Team noch ab, aber erste Tests sind somit schon mal möglich. PHP 7 soll bis zu doppelt so schnell sein wie 5.6. Weitere Infos dazu gibt's auf der PHP-Website.
Nur so zur Info: das wurde vorige Woche bereits implementiert, Aktualisierung im Tracker sowie Update der Preview erfolgt morgen im Laufe des Tages.
Alles anzeigenEs fehlten
Order allow,deny
Allow from all
bevor:
Require all granted
Wo genau (also in welcher Datei und dort an welcher Stelle) soll das gefehlt haben?
Welche Apache-Version verwenden Sie genau? (bzw. welche Linux-Distribution & -Version)
Ab Apache 2.4 gilt die "neue" Syntax ("Require all granted" statt Order/Allow).
Mit Version 1.9.0-r3619 enthält LiveConfig einen Workaround für den Bug im MySQL-Client.
LiveConfig (bzw. der darunterliegende Datenbank-Layer) initialisiert das mysql-Objekt dann für jeden Verbindungsversuch komplett neu.
Eventuell sind die hier vereinzelt genannten Sonderzeichen-Darstellungsfehler mit MySQL als Backend damit auch beseitigt (ich kann mir vorstellen, dass da beim Reconnect auch die UTF8-Einstellung verloren gegangen ist).
Was genau ist fehlerhaft?
Was liefert der Befehl "apache2ctl configtest"?
Weiß jemand, wie man LC von diesem Verhalten, den Socket an der falschen Stelle in /tmp statt an der passenden Stelle unter /var/run/mysqld/ zu suchen, abbringt?
LiveConfig ruft zur Verbindung zu MySQL die Funktion "mysql_real_connect()" in einer Schleife auf. Der MySQL-Client wiederum liest seine Einstellungen (u.a. socket) aus /etc/mysql/my.cnf, Abschnitt [client].
Wenn bei einem Reconnect der falsche Socket-Pfad verwendet wird, dann handelt es sich um einen Fehler im MySQL-Client, und nicht in LiveConfig.
[offtopic]Höchste Zeit also, Oracle mal mit dem Anwalt zu drohen.[/offtopic]
In LiveConfig können Sie den Socket auch explizit in der /etc/liveconfig/liveconfig.conf angeben. Fügen Sie dazu die Zeile "db_options = socket=/var/run/mysqld/mysql.sock" hinzu.
Wir werden dennoch gerne prüfen, ob es einen Workaround für diesen MySQL-Client-Fehler gibt.
Hallo,
hier mal 3 Links:
http://www.liveconfig.com/de/handbuch/server.sslcert.html
https://www.liveconfig.com/dow…/32bit/bash_ld_preload.so
https://www.liveconfig.com/dow…/64bit/bash_ld_preload.so
und weitere diverse Verlinkungen zu Beiträgen aus dem Forum.
Danke für den Hinweis. Die Handbuch-Dateien enden nun mit ".xhtml" statt bisher ".html" - ab sofort wird das weitergeleitet. Die beiden Downloads sind theoretisch obsolet (ShellShock sollte in jeder halbwegs aktuellen Distribution kein Thema mehr sein), werden aber gleich wieder online genommen.
Gefühlt wird ohne Nachfrage gar kein Support-Ticket beantwortet, ich hab letztens mal mit nem Anwalt gedroht und dann ging das Ganze einmal.
Jetzt habe ich schon wieder seit 6.6.:
Ja, seit dem 06.06. 23:40. Das ist Wochenende, kurz vor Mitternacht zu Sonntag.
Das von Ihnen beschriebene Anliegen ist nicht betriebskritisch (Ihre Infrastruktur funktioniert ja), daher lassen wir hier nicht sofort alles stehen und liegen und fahren am besten noch persönlich bei Ihnen vorbei.
Zu Drohungen mit Anwälten sage ich mal besser gar nichts...
ZitatDer Gipfel der Frechheit war in meinen Augen die Aussage, dass man bestimmte Sachen nicht braucht oder nicht so macht (konkret wegen meiner Nachfrage, wieso man nur 10 Emailadressen pro Postfach anlegen kann) (schon klar, mit Weiterleitungen gehen mehr)
Meinen Sie Alias-Namen? Dieses Limit ist inzwischen auch konfigurierbar. Wenn Sie es als "Gipfel der Frechheit" empfinden, dass wir das Produkt nicht (nur) nach Ihren Vorstellungen entwickeln, sollten Sie besser eine Individualentwicklung beauftragen. Mit einem kleinen sechsstelligen Betrag sind Sie da schon dabei.
Sie wissen genau, dass wir in dringenden Fällen jederzeit telefonisch zur Verfügung stehen und wir auch schon direkt auf Ihrem Server Support geleistet haben. Dass Sie dann hier im Forum (halbanonym) so herumpoltern enttäuscht mich dann schon etwas.
Mit freundlichen Grüßen
Klaus Keppler
Was mich persönlich noch mehr nervt sind das diverse Seiten dieser Webseite nicht mehr vorhanden sind. Auch wichtige Anleitungsseiten etc, und das schon seit etlichen Tagen.
Welche Seiten vermissen Sie denn konkret? Inzwischen sollte wieder alles online sein.
Ja, das ist in der Tat ein Problem (dass OpenSSL 1.0.2 benötigt wird was nicht bei Debian Jessie dabei ist).
Aaaaber:
1.) in Kürze wird Apache 2.2.30 freigegeben, der u.a. dieses Thema adressiert. Aufgrund der großen Verbreitung kann man wahrscheinlich davon ausgehen, dass der relevante Patch in die Versionen von Debian 6 & 7 portiert wird.
2.) LiveConfig wird die eigenen DH-Parameter unter Debian 8 mit in die Zertifikatsdateien (.pem) schreiben. Somit werden die dann auch berücksichtigt, wenn eben der SSLOpenSSLConfCmd-Befehl nicht verfügbar ist.
Im kommenden Update der 1.9er-Preview ist das bereits enthalten (dauert nur noch ein paar Tage bis wir die online stellen können).
