janxb CAA will Verantwortung der CAs auf Admins verlagern: Wir hätten das Zertifikat niemals ausgestellt, hättest Du den CAA entsprechend gesetzt. Du hast kein CAA? Dann selbst Schuld.
Ein Client kann CAA nicht prüfen, sondern muss sich darauf verlassen, dass alle CAs sich daran halten. In der Vergangenheit hat dies bei anderen Prüfpflichten der CAs nicht funktioniert...
Mit TLSA kannst Du für den Client prüfbar die CA limitieren. Dazu setzt Du das Certificate Usages Feld auf 0 oder 2.
Alternativ zu HPKP würde ich einen CAA-Record im DNS empfehlen, erfüllt meines Wissens nach den gleichen Zweck...
Du meinst TLSA?
CAA limitiert, welche CAs Zertifikate ausstellen sollen, nicht welche Zertifikate gültig sind.
Was Du aber nicht berücksichtigst, ist, dass ein Zertifikat bereits dann als kompromittiert anzusehen ist, wenn die Vertrauenswürdigkeit in Frage steht. Der Server selbst braucht nicht kompromittiert sein, es reicht z.B. die personelle Umstrukturierung in einem den Web-Auftritt erstellenden DevOps-Team. Ja, man kann dies auch durch HSM und Shamir's Secret Sharing in den Griff bekommen, nur habe ich dies in der Praxis abgesehen hiervon noch nicht gesehen.
Die hier gezeigte Konfiguration ist korrekt und kann nicht erklären, warum nur der zuletzt aktivierte virtual Host Block berücksichtigt wird. Auch die von Dir am Montag geposteten Listen und NameVirtualHost Direktiven sind korrekt, solange mod_ssl aktiv ist; das ist aber augenscheinlich der Fall.
Das nächste wäre, in den nicht gezeigten Dateien zu suchen, und dabei insbesondere auf die Include Reihenfolge und doppelt vorkommende Direktiven zu prüfen. Dazu müsstest Du aber den kompletten Inhalt von /etc/apache2 zur Verfügung stellen (als tar, zip o.ä).
Erstmal ja - oder ist die Migration unter Debian 7 möglich, ohne größere Probleme zu bereiten?
Dein Problem ist Debian 7. Ab Juni gibt es dafür nicht einmal minimalen Support. Wenn für irgendein genutztes Programm eine Sicherheitslücke veröffentlicht wird, musst die dann wahrscheinlich vorhandenen Patches selbst portieren bzw. die Lücke auch selbst schließen. Wenn Du aktuell keine Zeit für ein Upgrade hast, musst Du Dir jetzt sofort die Zeit nehmen, das Upgrade zu planen, Anfang Juni brauchst Du ein funktionierendes Konzept.
Der Workaround funktioniert aber ohnehin nur, wenn zu jedem Zeitpunkt zwei Zertifikate gültig sind und Du zu jedem Zeitpunkt sicherstellen kannst, dass nur eines der beiden kompromittert wird.
mainziman: Das Problem für den rechtmäßigen Betreiber ist aber, daß er ein kompromittertes Zertifikat nicht tauschen kann, ohne dass die Seite über Monate nicht mehr erreichbar ist. Also nutzt man das kompromitterte Zertifikat weiter?
mod_socache_shmcb... gibt es das für Apache 2.2?
Ich beantworte mal selbst, da ich es in einer alten Konfigurationsdokumentation noch gefunden habe: shmcb scheint tatsächlich unter Apache 2.2 möglich zu sein. Das Modul habe ich allerdings nicht gefunden, möglicherweise war dies unter Apache 2.2 noch nicht modular.
Public Key Pinning ist auch bei Angriffen auf die Verbindung ein Problem. Ohne Aufnahme in die mit Browsern ausgelieferten Dateien kann niemand prüfen, dass der richtige Key gepinnt wird.
HSTS-Header dürfen nach RFC 6797 nicht über unverschlüsselte Verbindungen übertragen werden. Statt dessen sollte ein permanent redirect (301) erfolgen.
Ich gehe inzwischen dazu über, keinen Redirect mehr vorzunehmen. Wenn heute ein Browser unverschlüsselten Content anfordert, dann ist das entweder bewusst so oder ein Fehler des Browsers.
Gehen wir mal systematisch vor. Zunächst das, was auffällt:
/etc/apache2/mods-available/ssl.conf:
CodeSSLSessionCache shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)
Hast Du mod_socache_shmcb aktiviert (gibt es das für Apache 2.2)?
Sind alle <VirtualHost> Blöcke für Port 443 auf *:443 gesetzt, auch in default-ssl.
Was sagt apachectl configtest?
Willst Du bei Apache 2.2 bleiben?
Mal ne ganz doofe Frage, für die ganzen Experten hier.
Kann ich selektive MX Records erstellen, also z.B. mail1@domain.de geht an mx1.de und mail2@domain.de geht an mx2.de?
Nein. Aber wenn der MX1 die Annahme an mail2 ablehnt, muss der Absender an MX2 die Zustellung versuchen. Dabei kann der Absender aber ein Limit setzen, welches mindestens 2 sein sollte.
Nun das scheint so "Standard" zu sein, denn ich hab nie etwas willentlich unterdrückt. Könntest du mir behilflich sein, da dran was zu ändern (link o.ä.) damit mir das nicht wieder passiert.
Es gibt mehrere Wege:
Nicht alles davon funktioniert bei jeder Fehlerursache. Daher kannst Du diese Maßnahmen gerne auch kombinieren.
Welche Version von Apache nutzt Du?
Anpassung auf die verschiedenen Registrare kostet eben. Wer Domains mit den individuellen Besonderheiten der verschiedenen Registrare braucht, sollte sich an einen spezialisierten Domain-Provider wenden. Bei Netcup gibt es eben Domains billig und nur mit dem Umfang, den alle Registrare gemein haben.
Das letzte was nach syslog passierte, war
May 16 10:47:01 v22018035818363324 CRON[2562]: (root) CMD (/sbin/fstrim / >/dev/null 2>&1)Du wirst aber aufgrund >/dev/null 2>&1 nie herausfinden, ob und wie dies für das Problem verantwortlich ist. Wer schon Fehlermeldungen unterdrückt, sollte wenigstens Fehler ordentlich abfangen.
In Zukunft gibt es jedoch Schadenersatzanspruch bei DSGVO-Verstößen und das ist ja auch der Anreiz
Auch Schadenersatz ist nicht neu, nur Ansprüche auf Schmerzensgeld kommen nun hinzu.
Also hört mit dem Beschweren auf: Wer aktuell gewissenhaft mit personenbezogenen Daten umgeht, wird sich nach dem 25.05. fragen, was dieser Hype eigentlich sollte. "Datenschleudern" hätten ohne GDPR früher oder später Probleme bekommen, nun scheint unzutreffend das Kalenderdatum Panik zu verursachen, statt zutreffend der gefährliche Umgang mit Daten.
Fast Nichts aus GDPR ist neu. Z.B.
Ich mein, theoretisch brauchen Firmen jetzt nen double-optin um mir mail zu schicken.
Brauchst Du heute auch schon.
Könnte also dazu übergehen sämtliche SPAM mails und email newsletter die ich nach dem 25 bekomme, für dich ich mich aber nie aktiv angemeldet habe, selektiv abzumahnen, ...
Das geht heute auch schon.
Auch wenn der Webserver die IP-Adresse nicht in einer Logdatei speichert, verwendet der Webserver während seiner Antwort die IP-Adresse. Das ist nach Art. 3 Nr. 2 GDPR eine Verarbeitung eines personenbezogenen Datums nach Art. 3 Nr. 1 GDPR. Damit besteht auch ohne Speicherung die Pflicht geeignete Maßnahmen zu treffen um die Mitteilungen nach Artt. 12, 15 GDPR zu übermitteln und zu erleichtern. Das macht man üblicherweise in der Datenschutzerklärung.
Doch, weil Du für die Anzeige im Browser des Anwenders die IP-Adresse verarbeiten musst.
Aber die Datenschutzerklärung wäre natürlich kurz.
wenn Du keine IP-Adressen verarbeitest, wie funktioniert dann Deine Webseite?
