Hallo,
gerade eben ist es passiert: Ich habe mich von einem anderem Browser eben mal im LiveConfig Forum angemeldet, wo ich noch nicht HTTPS Everywhere eingerichtet habe.
Daher mal aus neugier:
Es ist doch ein gültiges SSL Zertifikat für http://www.liveconfig.com vorhanden; ich kann verstehen, dass aus Lastgründen (?) die öffentlichen Einträge nicht via SSL Übertragen werden.
Aber warum ist der Login nicht SSL gesichert?
Moin,
muss das Thema aus aktuellen Anlass nochmal anschieben. Einige Kunden möchten gerne den zugewiesenen Traffic einsehen können!
vG
Andreas
+1.
Inhalt gelöscht
Prinzipiell stehe ich dem positiv gegenüber, allerdings möchte ich entscheiden, welche generierten Daten wann und wie das Netzwerk verlassen.
Und nach einem kurzem Check beim SSL Zertifikat ist SSL3 auch noch aktiviert ;(.
Ich muss allerdings dennoch bei einem Punkt widersprechen:
(...)
Wir wissen also nicht, bei welchem Kunden, welchem Server, welcher Lizenz oder welcher Domain usw. der Fehler aufgetreten ist - uns interessiert lediglich der Ort innerhalb des Programms.
(...)
Naja, (in)direkt schon. In meiner Lizenzübersicht steht zu jeder verwendeten Lizenz die IP-Adresse des Servers. Somit ist über diese Zuordnung klar, welcher Lizenznehmer mit welcher Lizenz und ggf. mit welcher Domain der Fehler aufgetreten ist.
Prinzipiell ist dies für mich nicht tragisch, aber sollte doch etwas anders kommuniziert werden.
und warum nicht via .htaccess ?
ErrorDocument 400 /errors/badrequest.html
ErrorDocument 401 /errors/authreqd.html
ErrorDocument 403 /errors/forbid.html
ErrorDocument 404 /errors/notfound.html
ErrorDocument 500 /errors/serverr.htmlMoin,
ich denke auch, dass die wenigsten DNS Einstellungen ändern.
[ Ansonsten wäre noch eine API zu Cloudflare (DNS) genial. ]
Ein kleiner Schönheitsfehler ist mir beim Durchklicken aufgefallen:
Das mySQL Logo https://demo18.liveconfig.com:…m/server/logo32-mysql.png
( https://demo18.liveconfig.com:…servers/manage/details/db )
fehlt 
Was ich mir sonst noch für die Version 1.8 wünschen würde wäre MariaDB (zum Auswählen, oder als Dual-Betrieb).
Grüße
Ja und nein. Rechtlich ist es besser, abzuweisen - inwieweit die Absender bei False-Positives mitspielen, steht auf einem anderen Blatt.
+1
Ich tendiere persönlich dazu, den Benutzer entscheiden zu lassen - sowie, wenn Spam-Ordner, dem Benutzer (ähnlich wie web.de/GMX) einen Bericht über den Spam zukommen zu lassen.
++1
_____________
ob er es tatsächlich verwenden kann, hängt davon ab, ob du Quota installiert und eingerichtet hast.
Über den Sinn, ob die Vergabe von 100GB bei einem Kontingent von 50GB, lässt sich streiten; dies wird Overselling genannt. D.h. es werden Ressourcen verkauft, die nicht existieren. Im Webhosting-Bereich (leider!) gang und gäbe.
quotaoff -avug
quotacheck -avugm
quotaon -avugdann müsste es gehen.
alle drei Befehle nacheinander ausführen...
was passiert, wenn du
mount -o remount /mnt/wwweingibst?
Quota ist auch installiert?
yast2 -i quotaNach den fstab einmal ein remount :
beispielhaft, ändere ggf. den mount Punkt
mount -o remount /Nachdem du Quota eingerichtet hast, musst du es auch noch einmal initialisieren und einschalten:
quotacheck -avugm
quotaon -avugNaja, den Teil könnte man ja auch in eine gesonderte Datei ausgliedern.
Aber: für das Liveconfig Login würde ich mir das hier mal anschauen:
https://www.liveconfig.com/de/kb/2
http://www.liveconfig.com/de/demo
Grüße
Ja, dies schreibst du direkt in die VirtualHost rein.
ungetestet!!, keine Garantie
CODE entfernt, da er so nicht funktioniert
-> mod_proxy_connect muss auch noch eingerichtet werden. mit allowCONNECT sollte es dann gehen.
http://httpd.apache.org/docs/2.0/mod/mod_proxy.html
(ich teste das heute Abend mal)
Hey,
ja, klar ist das machbar.
Für den LC Login kannst du problemlos auch die API Funktion nutzen. Dann kannst du den LogIn direkt in dein CMS integrieren.
Ansonsten möchte ich noch das Stichwort Apache mod_proxy und SSL Proxy in die Runde werfen 
(google mal ;)).
Für die SSL Zertifikate schaue mal bei StartCom vorbei. Die bieten dir auch kostenlose SSL Zertifikate, die so gut wie von allen Systemen vertraut wird. Auch bieten die eine recht günstige Wildcard Option an. Zum rumprobieren völlig ausreichend meiner Meinung nach. Und welcher CA man mehr Vertraut ist Vertrauenssache, alle haben etwas auf dem Kerbholz
Grüße
gelöscht
__________
Zitat von Debian Security Announce
The oldstable distribution (squeeze) is not affected by this vulnerability.
For the stable distribution (wheezy), this problem has been fixed in version 1.0.1e-2+deb7u5.
For the testing distribution (jessie), this problem has been fixed in version 1.0.1g-1.
For the unstable distribution (sid), this problem has been fixed in version 1.0.1g-1.
deb7u7 ist nicht betroffen (siehe oben)
Testen kannst du es via https://filippo.io/Heartbleed/
weltmeister...
Naja finde ich nicht so gut. Die Option mit 000default ist okay. Außerdem hat der Benutzer wenig damit zutun. Denn sobald einer unter der IP-Adresse SSL aktiviert hat, sagen wir mal domain1.de (kann auch vom Admin gesetzt sein), würde der Aufruf von https://domain2.de ebenfalls zu domain1.de weitergeleitet sein.
Aber besser wäre folgendes (so hab ich es eingerichtet):
2 IP Adressen.
Alle Kunden ohne SSL haben die IP-Adresse 1.
Alle Kunden mit SSL haben die IP Adresse 2.
So ist dem rel. gut "vorgebeugt". Sollte ein Kunde SSL deaktivieren, ja dann sieht es wieder anders aus. Das müsste ich mir glatt nochmal überlegen
oder pauschal jedem ein selbst signiertes SSL Zertifikat geben
Moin,
hast du auch den privaten Key aktualisiert?
ZitatX509_check_private_key:key values mismatch
Tipp:
erstell mal einen neuen privaten Key + CSR + Certifikat. Kommt es dann immer noch?
Update hat alles geklappt. Momentan bin ich dabei die SSL Zertifikate welche eventuell betroffen sind auszutauschen und stelle hier leider wieder fest das hier das aktualisieren nicht klappt. Erst wenn in Liveconfig eine Domain angefasst wird, wird auch das neue Zertifikat geschrieben. Nur das Zertifikat tauschen reicht leider immer noch nicht.
Dies scheint auch die Dienste wie Postfix oder Dovecot zu betreffen.
http://www.liveconfig.com/de/f…tsaktualisierung-gt-vHost
:o:):D
Moin,
aus aktuellem Anlass etwas was ich bemerkt habe:
Wenn ich das SSL Zertifikat unter dem Menüpunkt Hosting -> SSL-Zertifikat aktualisiere wurde dies nicht für die Subdomains aktualisiert. ... Erst als ich den vHost bearbeitet habe (quasi einmal einen anderen toggle gedrückt und wieder zurück) wurde das neue Zertifikat eingepflegt. Wäre doch gut, wenn dies schon über den austausch eines neuen Zertifikates gehen würde
Anbei: Es wäre auch gut, wenn ich das SSL Zertifikat für LC (Port 8443) direkt im Admin Menü austauschen könnte
Debian 6, aktuelle stable Version und Liveconfig 1.7.1 sowie 1.7.2-r2825
Grüße
