I am running OSX Sierra 10.12.5 with PHP 5.6.30 and have a local Wordpress / WooCommerce setup with the "woocommerce-gateway-paypal-express-checkout" plugin installed. I am seeing an error in the admin relating to my OpenSSL version:
WooCommerce Gateway PayPal Express Checkout requires OpenSSL >= 1.0.1 to be installed on your server
I also have other issues with cURL request to https pages, as well as the Wordpress update check not working; which I understand to be related.
In my php info, I have this entry for OpenSSL
OpenSSL support enabled
OpenSSL Library Version LibreSSL 2.2.7
OpenSSL Header Version LibreSSL 2.2.7
Openssl default config /private/etc/ssl/openssl.cnf
From the command line, the version is reported as:
openssl version
OpenSSL 0.9.8zh 14 Jan 2016
which openssl
/usr/bin/openssl
Lastly, the server environment reported by WooCommerce status is:
### Server Environment ###
Server Info: Apache/2.4.25 (Unix) LibreSSL/2.2.7 PHP/5.6.30
PHP Version: 5.6.30
PHP Post Max Size: 8 MB
PHP Time Limit: 31
PHP Max Input Vars: 1000
cURL Version: 7.51.0
SecureTransport
I am at a loss as to how to fix this. I understand that the LibreSSL is a branch of OpenSSL, and is more secure. I have searched for a solution, and several seem to suggest running brew install openssl and then brew upgrade openssl. This doesn't seem to fix the problem. I know there are several similar or related questions, but most of the responses were either a couple of years old, or seemed to cause other problems.
I have several machines with this problem and would really like to get a better understanding for what is going wrong.
Related
Since a day or so I can not access the databases on two of my servers any longer
I use
mysql -h host.sld.TLD -P 3306 -user user
which I have configured to allow my user from my host without password
but get the above error.
However, when I use
telnet host.sld.TLD 3306
I get
5.5.5-10.8.5-MariaDB-1:10.8.5+maria~ubu2004(si4cyW'Y��-n;{ypDA\)VU)mysql_native_passwordC
I am using homebrew's mariadb (currently 10.9.3) on my machine, which I can reach from the outside. One each of the 'failed' remotes is on ubuntu with 10.8 and one on a Mac also with 10.8, and outgoing works from both. OpenSSL is version 1.1.1s on both Macs
I have installed a number of different mariadb versions all have the same issues, as do their perl libraries. mysql itself works.
What am I doing wrong here?
This issue has been fixed in MariaDB 10.9.4 which was released yesterday. Brew still offers 10.9.3, usually it takes a couple of days until latest 10.9 release will be available via brew.
The issue doesn't affect the server itself, but Connector/C and command line tools which link against Connector/C.
See also: MariaDB connector in Python cannot connect to remote server
It appears sometime in June of this year our SSL validation inside of Artifactory started to fail for https://files.pythonhosted.org. As a result we are no longer able to resolve remote lookups for python packages not hosted locally.
The error when I click Test on the remote repository settings page with https://files.pythonhosted.org as the hostname:
Connection to remote repository failed: Certificate for doesn't match
any of the subject alternative names:
[r.shared-319-default.ssl.fastly.net]
When I try to validate the SSL using openssl on the host linux server:
openssl s_client -connect files.pythonhosted.org:443
subject=/CN=r.shared-319-default.ssl.fastly.net
If I pass the servername flag to openssl it finds the right cert:
openssl s_client -servername files.pythonhosted.org -connect files.pythonhosted.org:443
subject=/CN=*.pythonhosted.org
How do I go about fixing this in the UI?
server: CentOS Linux release 7.7.1908 (Core)
artifactory version: EnterpriseX license 7.3.2 rev 70302900
EDIT
Appears this is most likely caused by the version of artifactory this specific instance is running. I was able to check a newer version than what this instance is running and it works correctly.
EDIT2
The system.yaml contained the following
extraJavaOpts: -Djsse.enableSNIExtension=false
this was disabling artifactory from resolving SNI enabled domains. Fixed!
I tested the reported scenario. Executing an openssl command to retrieve the certificate from the Python registry is returning certificates with a different CN apart from the expected one.
Command:
openssl s_client -showcerts -connect files.pythonhosted.org:443 </dev/null
I couldn't confirm if this is an issue with a redirect. However, executing the command to retrieve the certificate with server name in specific appears to be revealing the actual certificate for the remote site.
So, Could you please try using the following command, collect the certificate and use this certificate to replace the already amended certificates in support of this remote connection?
openssl s_client -showcerts -connect files.pythonhosted.org:443 -servername files.pythonhosted.org </dev/null
I'm not familiar with the artifactory you mentioned. But I can give you a hint on the certificate part, in general, your issue is caused by the website files.pythonhosted.org support SNI and your client-side cannot recognize the SNI support.
To check the server website ssl information, you can visit:
https://www.ssllabs.com/ssltest/analyze.html?d=files.pythonhosted.org&s=151.101.1.63
In the result, you can see a line "Certificate #2: RSA 2048 bits (SHA256withRSA) No SNI" which means there are 2 certificates in the server, and for more explanation, you can check
https://support.cpanel.net/hc/en-us/articles/360055289933-Why-is-SSLLabs-Certificate-2-RSA-2048-bits-SHA256withRSA-No-SNI-test-showing-an-error-
And OpenSSL older version cannot handle SNI correctly as well, that's why your openssl command is not returning the expected result. Actually, the same command
openssl s_client -showcerts -connect files.pythonhosted.org:443
with OpenSSL 1.0.2k-fips on Oracle Linux 7, it returns:
r.shared-319-default.ssl.fastly.net
with OpenSSL 1.1.1 FIPS on Centos 8, it returns: *.pythonhosted.org
So the issue may be related to https://www.jfrog.com/jira/browse/HAP-556
https://www.jfrog.com/jira/si/jira.issueviews:issue-html/BI-167/BI-167.html
I use SSH keys in my wp-config since a long time. Updates, plugin installation and removal, all worked well. After the last apt-get update wp is asking for the FTP password when I try to install for example a plugin.
There was no change done to the wp installation nor the file or directory permissions. I did not update wp either.
define('FTP_PUBKEY','/home/wp-user/wp_rsa.pub');
define('FTP_PRIKEY','/home/wp-user/wp_rsa');
define('FTP_USER','wp-user'); define('FTP_PASS','');
define('FTP_HOST','127.0.0.1:22');
Ubuntu 14.04
WORDPRESS VERSION: 4.7.6
PHP VERSION: 5.5.9-1ubuntu4.22
WEB SERVER INFO: Apache/2.4.7 (Ubuntu) OpenSSL/1.0.1f
EDIT:
I added below to my wp-config to see if it changes something.
define('FS_METHOD', 'ssh2');
No I'm getting a different error message in the WP backend:
The ssh2 PHP extension is not available
...but ssh2 is installed and loaded:
# php -m |grep ssh2
ssh2
Seems to be a bug in libssh2-php...
https://bugs.launchpad.net/ubuntu/+source/php-ssh2/+bug/1617294
Installing the WP plugin below allows me again to install/update as before.
https://en-ca.wordpress.org/plugins/ssh-sftp-updater-support/#description
I was trying Qualys SSL Labs test and It told me that the server is vulnerable to OpenSSL Padding Oracle vulnerability (CVE-2016-2107). I googled around on how to fix this, and although the OpenSSL version installed on my system (Ubuntu 14.04) should be patched for that according to this link I was still getting this error.
I tried upgrading OpenSSL but it was already the newest version, so I installed manually a newer version following the instructions here which went fine, but that didn't fix anything. Looking at the info from Nginx, It seems it still runs with the previous version:
nginx -V
nginx version: nginx/1.10.2
built with OpenSSL 1.0.1f 6 Jan 2014 (running with OpenSSL 1.0.2g-fips 1 Mar 2016)
while OpenSSL has clearly been updated:
openssl version
OpenSSL 1.0.2j 26 Sep 2016
Any idea how to get all this sorted out?
Note that yes, I did restart Nginx, I even tried sudo service nginx upgrade and even rebooted the server.
I use engine AES-NI increase performance of openssl speed (hardware acceleration) with my chip is supported engine AES-NI (Intel(R) Xeon(R) CPU E5620 # 2.40GHz).
I try install openssl version 1.0.2-chacha and 1.0.1l
Version 1.0.2 chacha when test speed openssl with command:
openssl speed aes-256-cbc
then error:
Error: bad option or value
Version 1.0.1 when config with nginx then error:
nginx: [warn] ENGINE_by_id("aesni") failed (SSL: error:25066067:DSO
support routines:DLFCN_LOAD:could not load the shared
library:filename(/usr/lib/x86_64-linux-gnu/openssl-1.0.1/engines/libaesni.so):
/usr/lib/x86_64-linux-gnu/openssl-1.0.1/engines/libaesni.so: cannot
open shared object file: No such file or directory error:25070067:DSO
support routines:DSO_load:could not load the shared library
error:260B6084:engine routines:DYNAMIC_LOAD:dso not found
error:2606A074:engine routines:ENGINE_by_id:no such engine:id=aesni)
I know for versions of openssl >= 1.0.1, AES-NI does not work via an engine and will not show up in the openssl engine command. It is active by default on the supported hardware.
I see one command in https://www.ruby-forum.com/topic/6873426#1168394 say "no configuration option and it will work as long as your cpu supports it".
But I do not find official sources.
Please suggest a solution for use version openssl and config with nginx.
In OpenSSL >= 1.0.1 AES-NI is enabled by default in the EVP interface, and there is no aesni engine. So in nginx there is no configuration option to enable AES-NI for OpenSSL versions >= 1.0.1 as it is enabled by default in OpenSSL (as long as your CPU supports it). For OpenSSL versions < 1.0.1 there is no official support for AES-NI though there is a patch available.
[http://openssl.6102.n7.nabble.com/having-a-lot-of-troubles-trying-to-get-AES-NI-working-tp44285p44301.html]