Ich habe Probleme beim Aktivieren des Socket-Transports “ssl” in PHP. Wenn ich mein Skript ausführe, erhalte ich den Fehler:
Warnung: fsockopen()
[function.fsockopen]: keine Verbindung zu ssl://www.my.site.com:443 (Kann den Socket-Transport “ssl” nicht finden – haben Sie vergessen, ihn zu aktivieren, als Sie PHP konfiguriert haben?)
Ich verwende IIS6 unter Windows und habe bisher Folgendes getan, um zu versuchen, es zum Laufen zu bringen:
die Erweiterungen php_openssl.dll und php_sockets.dll in php.ini auskommentiert
sichergestellt, dass PHP die INI-Datei lädt, an der ich Änderungen vorgenommen habe (das ist es, und es lädt definitiv andere Erweiterungen, also bin ich mir ziemlich sicher, dass dies nicht das Problem ist)
Stellen Sie sicher, dass sich php_openssl.dll und php_sockets.dll an der richtigen Stelle befinden
kopierte ssleay32.dll und libeay32.dll in den PHP-Hauptordner, den WINDOWS-Ordner und den WINDOWS/system32-Ordner
Stellen Sie sicher, dass die Windows-Pfadvariable den Speicherort von PHP enthält
stellte sicher, dass die Dateiberechtigungen für alle relevanten Dateien korrekt waren.
Ich habe IIS nach so ziemlich jeder Änderung neu gestartet, aber ich hatte kein Glück. Ist irgendetwas offensichtlich, dass ich falsch mache? Gibt es trotzdem eine Möglichkeit, dies in kleineren Teilen zu beheben? (Also kann ich das Problem durch den Ausschlussprozess herausfinden …?)
Leider sind Windows/IIS nicht mein Fachgebiet – mir wurde die Verantwortung übertragen, weil sonst niemand etwas zu wissen scheint.
wie Ihre php.log aussieht, wenn Sie die Protokollierung nicht aktiviert haben, tun Sie dies bitte.
– RageZ
10. November 2009 um 5:45 Uhr
Um den Kommentar von @RageZ zu erweitern: Ist ‘display_startup_errors’ in php.ini eingeschaltet?
– Ben Dunlap
10. November 2009 um 6:00 Uhr
Ja, wir haben die Protokollierung aktiviert … aber da ich der n00b bin, habe ich völlig vergessen, >_< zu überprüfen. Der Fehler, den wir erhalten, ist: "PHP Warning: PHP Startup: Unable to load dynamic library 'C:\ PHP\ext\php_openssl.dll' - Zugriff verweigert." Nachdem ich das gesehen hatte, dachte ich, es könnte ein Berechtigungsproblem mit php_openssl.dll gewesen sein, aber wir haben es mit einer anderen DLL in diesem Ordner verglichen (von der wir wissen, dass sie geladen wird) und sie scheinen dieselben Berechtigungen und Gruppen zu haben. Gibt es etwas anderes, das das Laden dieser DLL verhindern könnte?
– Jeline
11. November 2009 um 0:18 Uhr
Zikatomo
Ich hatte ein Problem in Windows 7 mit PHP 5.4.0 in der Befehlszeile unter Verwendung des Xampp 1.8.1-Servers. Das habe ich getan:
Umbenennen php.ini-production zu php.ini (im Ordner C:\xampp\php\)
Bearbeiten php.ini und auskommentieren extension_dir=ext.
Auch auskommentieren extension=php_openssl.dll.
Danach hat es gut funktioniert.
Mit WampServer 2.2 bearbeite ich nur php.ini in C:\wamp\bin\php\php5.3.13 dann auskommentieren extension=php_openssl.dll.
– Rubens Mariuzzo
26. Mai 2013 um 0:14 Uhr
Nur das Auskommentieren der Erweiterung = php_openssl.dll und das Neustarten von Apache hat auch für mich funktioniert.
– Layton Everson
2. Juni 2013 um 0:27 Uhr
Vielen Dank. Es hat mich fast zum Weinen gebracht 🙂
– M. Ahmad Zafar
28. Juni 2013 um 6:01 Uhr
Danke, Wamp hatte eine andere php.ini-Datei als die php.ini in “C:\wamp\bin\php\phpversion\php.ini” verwendet. Ich musste die open_sll-Erweiterung in dieser php.ini-Datei auskommentieren und nicht in der php. ini vorgeschlagen von wamp. Ich hoffe, das hilft jedem, der das gleiche Problem hat.
– csblo
24. Juli 2014 um 8:39 Uhr
hat bei mir am 5.6.11 funktioniert, ich kann jetzt eine https-URL mit $data = file_get_contents($url) lesen;
– medloh
11. Juli 2015 um 0:09 Uhr
Erfolg!
Nachdem ich die Protokolldateien überprüft und sichergestellt hatte, dass die Berechtigungen für php_openssl.dll korrekt waren, googelte ich die Warnung und fand weitere Dinge zum Ausprobieren.
Also ich:
C:\PHP\ext zum Windows-Pfad hinzugefügt
libeay32.dll und ssleay32.dll zu C:\WINDOWS\system32\inetsrv hinzugefügt
den Server neu gestartet
Ich bin mir nicht sicher, welche davon mein Problem behoben hat, aber jetzt ist es definitiv behoben! 🙂
@RubensMariuzzo danke, aber ich habe es bereits gelöst, das Problem war mit meinem 64-Bit-System und die Lösung bestand darin, ein paar DLLs an einigen Stellen zu kopieren, ich erinnere mich nicht an die genauen Schritte.
– Codierungs_Idiot
26. Mai 2013 um 7:58 Uhr
@taarradhin, libeay32.dll und ssleay32 werden nicht benötigt, Sie benötigen nur 3 Dinge:
– Schrittmacher
15. Juli 2015 um 8:13 Uhr
@coding_idiot, 1)extension_dir muss auf den Ordner zeigen, der beidephp_sockets.dll und php_openssl.dll sind in und 2) Sie müssen die Zeilen haben extension=php_openssl.dll und extension=php_sockets.dll und 3) Stellen Sie sicher, dass ihre Werte nicht durch denselben Schlüssel unten überschrieben werden. Dies ist sehr häufig. Nur diese 3 und du bist fertig.
– Schrittmacher
15. Juli 2015 um 8:15 Uhr
Ich reiße heute mein Herz dafür heraus und definitiv sind diese 3 Dinge nicht genug. Auch das Kopieren der beiden DLL-Dateien funktioniert nicht. Sehr ärgerlich, dass es keine wirkliche, einfache XAMPP/Windows10/64-Bit-Lösung für dieses Problem gibt … Ich erwäge, XAMPP, egal welche neueste Version, zu diesem Zeitpunkt von Grund auf neu zu installieren.
– CK MacLeod
3. März 2017 um 21:09 Uhr
In XAMPP Version 1.7.4 hat der Server keine extension=php_openssl.dll-Zeile in der PHP-INI-Datei. Wir müssen extension=php_openssl.dll in der Datei php.ini hinzufügen
Es muss zwar manuell hinzugefügt werden, aber der ext-Ordner enthält glücklicherweise php_openssl.dll.
– Valentin Despa
29. Januar 2013 um 8:38 Uhr
Beim Versuch, E-Mails mit SSL-Verschlüsselung zu senden, ist Laravel 4 auf das gleiche Problem gestoßen.
Mit WAMPServer 2.2 unter Windows 7 64bit habe ich nur php_openssl in der php.ini aktiviert, WAMPServer neu gestartet und funktionierte einwandfrei.
Habe folgendes gemacht:
Klicken Sie auf WampServer -> PHP -> PHP-Erweiterungen -> php_openssl
Starten Sie WampServer neu
Einfach auskommentieren extension=php_openssl.dll
Starten Sie Apache Service neu und das sollte helfen.
Tal
Ich bin auch gerade auf dieses Problem gestoßen, als ich mit Laravel herumgespielt habe.
Ich verwende wampserver für Windows und musste die Datei /bin/apache/apacheversion/bin/php.ini nach /bin/php/phpversion/php.ini kopieren
Ajay Singh
Ich verwende XAMPP und bin auf den gleichen Fehler gestoßen. Ich hatte all diese Schritte ausgeführt, den Pfad für Umgebungsvariablen hinzugefügt, alle möglichen Verzeichnisse der DLL nach /php, /apache/bin, /system32, /syswow64 usw. kopiert, aber immer noch diesen Fehler erhalten.
Nachdem ich das Apache-Fehlerprotokoll überprüft hatte, bemerkte ich das Problem mit der Verwendung von Klammern im Pfad.
PHP: Syntaxfehler, unerwartetes ‘(‘ in C:\Programme (andere)\xampp\php\php.ini in Zeile 707 0 Serverzertifikat enthält KEINE ID, die mit dem Servernamen übereinstimmt
Wenn Sie den Server im Verzeichnis “Program Files (x86)” installiert haben, kann derselbe Fehler aufgrund der nicht maskierten Klammern auftreten.
Um dies zu beheben, öffnen Sie die Datei php.ini und suchen Sie die Zeile mit „include_path“ und schließen Sie den Pfad in doppelte Anführungszeichen ein, um diesen Fehler zu beheben.
wie Ihre php.log aussieht, wenn Sie die Protokollierung nicht aktiviert haben, tun Sie dies bitte.
– RageZ
10. November 2009 um 5:45 Uhr
Um den Kommentar von @RageZ zu erweitern: Ist ‘display_startup_errors’ in php.ini eingeschaltet?
– Ben Dunlap
10. November 2009 um 6:00 Uhr
Ja, wir haben die Protokollierung aktiviert … aber da ich der n00b bin, habe ich völlig vergessen, >_< zu überprüfen. Der Fehler, den wir erhalten, ist: "PHP Warning: PHP Startup: Unable to load dynamic library 'C:\ PHP\ext\php_openssl.dll' - Zugriff verweigert." Nachdem ich das gesehen hatte, dachte ich, es könnte ein Berechtigungsproblem mit php_openssl.dll gewesen sein, aber wir haben es mit einer anderen DLL in diesem Ordner verglichen (von der wir wissen, dass sie geladen wird) und sie scheinen dieselben Berechtigungen und Gruppen zu haben. Gibt es etwas anderes, das das Laden dieser DLL verhindern könnte?
– Jeline
11. November 2009 um 0:18 Uhr