Beiträge von da2401

Hallo zusammen,

ich habe seit gestern nachmittag auch das o.g. Problem.

Supportanfrage über Kontaktformular wurde bereits gestellt, allerdings wird das wohl in diesen Tagen noch dauern.

Kann mir einer sagen, was das Problem bzw. die Lösung hierzu ist, damit der Fehler "???VIR_DOMAIN_SHUTDOWN???" nicht wieder auftritt?

Ist halt doof, dass das genau am Wochenende passiert ist - jetzt liegt der Familien-Mailserver vermutlich bis Montag flach.

Zitat von schousda

Dazu passend: Fefes Blog

Erstens unpassend, da SHA-256-Zertifikate, 2. hab ich das heute auch gelesen.
Drittens ist - ungeachtet der Seriösität einer CA - das (mutwillige) Zurücksetzen eines Datums kein Sicherheitsproblem, höchstens ein Vertrauensproblem.

Da ich aber kein Geflame lostreten will, kann dieser Thread geschlossen werden, zumal das ursprüngliche Problem des TOs (also: meines) bereits gelöst ist.

So, Problem gelöst. Ursache war der Zugriff über VPN / wackeliges WLAN. Hier hat es mir im Plesk Automation beim Speichern der Zertifikatsauswahl wohl die Connection immer abgerissen. Beim Neuladen der Hosting-Config sah es so aus, als ob das Zertifikat korrekt selektiert war - war es aber nicht.

Zitat von killerbees19

Wenn Dir der Webserver trotz dieser Einstellungen immer noch das falsche Zertifikat für genau diese (Sub)domain ausliefert, würde ich einmal beim Support nachfragen. Die können genauer nachschauen, warum das so ist.

Was ich hier mit tue .

Hier nochmals die genauen Umstände:

• Expert Light mit einer Domain und einer externen Domain. Über http tut alles. Beide Domains zeigen auf dasselbe Verzeichnis (/httpdocs)
• Wo$ign Free SSL Certificate mit insgesamt 4 SubjAltNames, externe sowie interne Domain, jeweils mit und ohne www. Gültigkeit: 3 Jahre
• Private key per openssl mit 4096 Bit (RSA) erzeugt.
• CSR per openssl mit sha256 erzeugt und beim CA das o.g. Zertifikat ausstellen lassen.
• Für Wo$ign wird zusätzlich zum intermediate- auch noch das von $tartSSL signierte cross-intermediate-Zertifikat benötigt.
• Private Key, das erstellte Zertifikat sowie die beiden intermediate-Zertifikate (CA) über die entsprechenden Textfelder im WCP hochgeladen.
• über die SSL-Unterstützung der entsprechenden Webseite das Zertifikat ausgewählt
• für beide Domains (intern, extern) jeweils separat das identische Zertifikat (priv.Key, Cert, CAs) hochgeladen, um beiden Domains das Zertifikat zuweisen zu können

Spaßeshalber habe ich für dieselbe Konstellation manuell bei LE ein Zertifikat ausgestellt - dieses nimmt er auch nicht.
Momentan tippe ich auf das Vorhandensein verschiedener Domainnamen im Zertifikat ...ich werde noch testweise eines ausstellen für meineDomain.tld / www. meineDomain.tld und schauen, ob es damit tut.

Hallo,

ich versuche gerade verzweifelt, für einen Bekannten in einem Expert-Tarif ein eigenes SSL-Zertifikat zu nutzen.
(Bitte keine Diskussion, ob der Anbieter sicher ist etc.)

Der private Schlüssel (4096 Bit) wurde selbst generiert, der CSR per SHA256 ging an den Zertifikatsausgeber.
Das Zertifikat enthält 4 Domain-Namen (eigeneDomain.tld, www. eigeneDomain.tld, externeDomain.tld, www. externeDomain.tld).

Sowohl per Upload der Dateien (privater Schlüssel, eigenes Zertifikat und intermediate-Zertifikate) als auch
per Copy&Paste über die Textfelder werden die Zertifikate korrekt im System hinterlegt, in den Hostingeinstellungen
kann ich die Zertifikate wählen und augenscheinlich erfolgreich speicern/aktivieren.

Trotzdem wird mir beim Aufruf der Seiten per https immer noch das Netcup-Zertifikat ausgeliefert.
Nutze ich die Zertifikate + die CA-Zertifikatskette in meinem vServer, klappt alles problemlos.

Hat schon jemand erfolgreich ein FreeSSL-Zertifikat von diesem Anbieter per WCP integrieren können?

Mein vServer startete zwar automatisch hoch, hing aber auf der Konsole in der fsck-Rückfrage fest.
Nach einem [F]ix konnte zwar hochgefahren werden, allerdings fehlten ihm 2 Verzeichnisse (inkl. darin befindlicher Dateien) -> /var/run/mysqld sowie /etc/security.
In diesem Zustand war ein Login nicht möglich. Dies konnte ich über das Rettungssystem korrigieren.

Nachdem ich mich wieder einloggen konnte, wollte jedoch mein MySQL immer noch nicht starten, da 3 Binaries kaputt waren (Input/Output Error).
Diese habe ich umbenannt und aus den Repository-Binaries nachinstalliert.

Laufen tut zwar nun wieder alles, aber habe ich Bauchschmerzen, da die 3 Binaries mit I/O-Errors immer noch auf der Platte herumfahren.
Hier komme ich wohl nicht umher, ein Backup der root-Partition einzuspielen bzw. die Partition plätten und neu aufsetzen ...