Als nächstes habe ich im Backend Folgendes eingestellt.
Als nächstes habe ich die htaccess angepasst. Bezogen auf diese Diskussion und die Antwort von Moritz Naczenski.
RewriteEngine on
#RewriteBase /shopware/
# Https config for the backend
RewriteCond %{HTTPS} !=on
#RewriteRule backend/(.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteRule shopware.dll shopware.php
RewriteRule files/documents/.* engine [NC,L]
RewriteRule backend/media/(.*) media/$1 [NC,L]
RewriteCond %{REQUEST_URI} !(\/(engine|files|templates|themes|web)\/)
RewriteCond %{REQUEST_URI} !(\/media\/(archive|banner|image|music|pdf|unknown|video)\/)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ shopware.php [PT,L,QSA]
# Fix missing authorization-header on fast_cgi installations
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
# Block access to VCS directories
RedirectMatch 404 /\\.(svn|git|hg|bzr|cvs)(/|$)
# Restrict access to root folder files
RedirectMatch 404 /(composer\.(json|lock)|README\.md|UPGRADE\.md)$
# Staging environment
#SetEnvIf Host "staging.test.shopware.in" SHOPWARE_ENV=staging
# Development environment
#SetEnvIf Host "dev.shopware.in" SHOPWARE_ENV=dev
#SetEnv SHOPWARE_ENV dev
DirectoryIndex index.html
DirectoryIndex index.php
DirectoryIndex shopware.php
# Disables download of configuration
# Deny all requests from Apache 2.4+.
Require all denied
# Deny all requests from Apache 2.0-2.2.
Deny from all
# Enable gzip compression
AddOutputFilterByType DEFLATE text/html text/xml text/plain text/css text/javascript application/javascript application/json
ExpiresActive on
ExpiresDefault "access plus 1 month"
Header append Cache-Control "public"
Header unset ETag
FileETag None
# Match generated files like:
# 1429684458_t22_s1.css
# 1429684458_t22_s1.js
Header set Cache-Control "max-age=31536000, public"
ExpiresActive on
ExpiresDefault "access plus 1 year"
# Disables auto directory index
Options -Indexes
Options -MultiViews
# php_value memory_limit 256M
# php_value max_execution_time 120
# php_value upload_max_filesize 20M
php_flag phar.readonly off
php_flag magic_quotes_gpc off
php_flag session.auto_start off
php_flag suhosin.session.cryptua off
php_flag zend.ze1_compatibility_mode off
# AddType x-mapp-php5 .php
# AddHandler x-mapp-php5 .php
Header append X-Frame-Options SAMEORIGIN
Danach habe ich alle Browser Caches gelöscht und auch nochgmal CCleaner drüber laufen lassen.
Wenn ich nun mit der neusten Version von Chrome und Edge benutze, wird die Seite ganz normal mit https:// angezeigt… Nur FF gibt mir diese Meldung aus.
Und andere Benutzer der Seite, bestätigten diese Warnmeldung.
Warum meckert FF rum? Zufällig jemand eine Idee? Der Provider sagte, auf dem Server ist alles ok. o0?
die certificate chain ist nicht vollständig. Wahrscheinlich werden einige Browser auf Mobile Devices die Seite ebenfalls nicht laden. Der Desktop Browser von Google Chrome lädt die „fehlenden“ Komponenten nach, unter Android nicht. Derjenige, der das Zertifikat installiert hat, muss auch noch die restlichen Komponeneten der Chain auf dem Server installieren.
vielen Dank für diese qualifizierte Antwort.
Ich habe Deine Aussage so an den Provider weitergegeben und siehe da, es hat sich da doch igw. ein Fehler eingeschlichen.
Jetzt funktioniert alles so wie es soll. Peace!
Hä wofür, sind Fragen zu den Ergebnissen des SSLabs-Testvorhanden?
Korrigiert worden ist die unvollständige certificate chain, die anderen Angaben im Test beziehen sich auf Serverkonfigurationen, wichtig sind die farbig hinterlegten Warnmeldungen. Es sollte Grade A als Gesamtbewertung erscheinen.
Die Browser sind mittlerweile „strenger“ bei der Ausgabe von Warnmeldungen geworden und/oder stellen dies um. Wenn man nicht ständig bei jedem Browserupdate und auf den verschiedenen Browsertypen (Desktop/Mobile) testen möchte, ist der einfachste Weg, einen Server zu betreiben, der Grade A erreicht.
ah ich verstehe. Ich hatte die url nicht nochmal getestet. Ich habe mich da auf die Antwort vom Provider verlassen.
Grade C ist wirklich nicht ok.
…das Zwischenzertifikat hatte ich natürlich mit installiert. Scheinbar hat RapidSSL allerdings mal wieder das Zwischenzertifikat ausgetauscht (das machen die ständig, die Firma hat offensichtlich Langeweile), und obwohl ich gestern Morgen ein positives Ergebnis hatte, hatte ich nun ebenfalls wieder ein negatives Ergebnis bei der Überprüfung. Ich habe daher das Zwischenzertifikat noch einmal ausgetauscht und nun erhalte ich wieder die Rückmeldung, dass alles in Ordnung ist. Daher bitte zur Sicherheit noch einmal den Cache des Shops leeren, dann sollte es wirklich funktionieren.
Viele Grüße aus Obertshausen
Ich werde das jetzt nochmal weiterleiten, bis Grade A erreicht ist.
Zumal das Zertifikat an sich überhaupt nichts mt der Konfiguration zu tun hat bzgl des Poodle-Angriffs bspw.
Der Hoster selbst hat die Sicherheitslücke für den Poodle-Angriff offen! Das ist also nicht nur ein kleines Problem und nicht nur ein Problem auf deiner Webseite. Ich will nicht wissen wie viele Kundenwebseite da noch angreifbar sind.
Da haste dir ja einen super Hoster ausgesucht Meiner Meinung nach solltest du den Hoster wechseln, da das nicht gerade kleine Sicherheitslücken sind, welche der Hoster zu verantworten hat. Und diese liegen wie @hth bereits gesagt hat an der Server Konfiguration und nicht am Cert.
Übrigens gibt es mittlerweile mti https://letsencrypt.org/ einen Service, welcher es dir ermöglich ein SSL Zertifikat 100% kostenlos zu bekommen.
aktuell können wir da nichts weiter tun, da einige unserer Kunden noch auf die Unterstützung von SSL3 angewiesen sind, und wir den Dienst daher nicht abstellen können. Wir haben jedoch alle notwendigen Sicherheitsvorkehrungen getroffen, damit die aufgeführten Sicherheitsschwachstellen bei uns nicht ausführbar sind. Ihre Webseite und Ihre Daten sind daher sicher. Übrigens werden wir gegen Ende des Jahres SSL3 dann vollständig deaktivieren, dann wird sich der Wert auch auf A ändern. Falls Ihnen dies dennoch wichtig ist, können Sie jederzeit einen eigenen Server bei uns bestellen, dann können wir Ihnen den Server auch so einrichten, dass direkt Grade A erreicht wird. Aktuell nutzen Sie ein Shared Hosting Paket, was bedeutet, dass Sie sich den Server mit anderen Kunden teilen, und daher auf größt mögliche Anwendungskompatibilität geachtet werden muss.
Die POODLE Attacke (Padding Oracle On Downgraded Legacy Encryption) ist ein Angriff auf den CBC-Modus der Verschlüsselung von SSL 3.0. Im Gegensatz zu den SSL-Attacken BEAST und Lucky 13 gibt es keinen umsetzbaren Work-around , defacto gibt es daher keine sicheren CBC SSL 3.0 Cipher Suiten.[1] Um garantiert eine sichere Verschlüsselung zu erreichen, muss SSL 3.0 komplett vermieden bzw. deaktiviert werden.
ferner, damit du siehst wie gefährlich eine solche Sicherheitslücke sein kann:
Bei erfolgreicher Ausnutzung der Schwachstelle, können über eine man-in-the middle Attacke sensible, verschlüsselte Informationen einer SSL 3.0 Verbindung offen gelegt werden.[1] Rapid7 schreibt dazu:
*Irgendwas mache ich falsch - hab gerade im Shared-Hosting zwei domains getestet, und beide sind A - eine davon mit LetsEncrypt-Zertifikat*
[Thread kapern]
Seit dem 21.03. ist LetyEncrypt bei All-Inkl. eingebunden (zumindest bei Business) - man kann es über die Domain-Einstellung => SSL per Click beantragen und sofort einbinden. Gibt es schon Erfahrungen mit LetsEncrypt => Shopware => Browser-„Unverträglichkeiten“?
Peace!
Meiner Meinung nach solltest du den Hoster wechseln, da das nicht gerade kleine Sicherheitslücken sind, welche der Hoster zu verantworten hat. Und diese liegen wie