Nach SSL-Aktivierung, Probleme mit FF, ungültiges Sicherheitszertifikat

Hallo,

ich habe bei meinem Provider das RAPIDSSL Zertifikat bestellt. Das ist auch mittlerweile aktiv.
AlphaSSL Zertifikate günstig vom SSL Spezialisten kaufen

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?

Grüße

Hallo,

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. 

Zum Beispiel mit diesem Webdienst kann man das auch online testen: SSL Server Test (Powered by Qualys SSL Labs)

Die ganze Zertifikatsituation bedarf meiner Ansicht nach einer „Wartung“.

 

Viele Grüße

 

HTH

Hallo HTH,

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. :slight_smile: Peace!

Güße

 

Hall hajo808,

lass die Seite mal bei dem Link oben testen und wende dich mit dessen Anmerkungen noch mal an deinen Hoster, damit er die beseitigt. 

Hallo,

hä, es wurde doch schon beseitigt!?

Gr

@hajo808 schrieb:

Hallo,

hä, es wurde doch schon beseitigt!?

Gr

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. 

Hallo,

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.

Grüße

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  Undecided 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.

Hallo,

nun kam Folgende Antwort.

Hallo xxxx,

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.

Grüße

@hajo808‍ Selten so viel Blödsinn gelesen … Übrigens schau mal hier: https://www.thomas-krenn.com/de/wiki/SSL\_3.0\_POODLE\_Attack

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“?