Open ripdog opened 12 years ago
Same issue on a MacOS local dev install.
I tried setting perms on cacert.pem as well, but it didn't solve the issue.
I had the same issue on Ubuntu 8.04 LTS. It disappeared when I upgraded to 10.04 LTS. It must be a curl or php5-curl version problem. I suggest we list our curl version numbers.
curl 7.18.0-1ubuntu2.3
php5-curl 5.2.4-2ubuntu5.23
curl 7.19.7-1ubuntu1.1
php5-curl 5.3.2-1ubuntu4.17
On my Mac :
port installed | grep curl
I do not have this problem on my local Linux VM.
uname -a
Linux lucid32 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:08:37 UTC 2011 i686 GNU/Linux
curl --version
curl 7.19.7 (i486-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
php -i | grep 'cURL Information'
cURL Information => 7.19.7
I don't know if this applies to any of you, but I had this problem until I changed the name of my S3 bucket to not contain the period character ('.'), as that caused the SSL certificate verification to fail. This is explained in the AWS documentation:
When using virtual hosted-style buckets with SSL, the SSL wild card certificate only matches buckets that do not contain periods. To work around this, use HTTP or write your own certificate verification logic.
Source: http://docs.amazonwebservices.com/AmazonS3/latest/dev/VirtualHosting.html
Changing my bucket name from photos.mydomain.com to photos-mydomain-com made the error go away.
Perhaps it might be better to use the path style URLs for resources in the S3 buckets instead to avoid this problem with the wildcard certs?
You're right. My test bucket had a period in it ! Good catch ;)
Perhaps it might be better to use the path style URLs for resources in the S3 buckets instead to avoid this problem with the wildcard certs?
Definitely something we should consider. For the DreamObjects adapter which basically extends the S3 one we are using path style URLs.
I'm updating the title to better reflect the actual problem.
Update: the cause of the problem was a
.
in the bucket name. Switching to path style URLs should fix it.Another issue from my Arch install.
Install step 3 was failing with error 500. In the logs:
cURL resource: Resource id #16; cURL error: SSL peer certificate or SSH remote key was not OK (51)", additional:},
This is the same error as mentioned in #727.
I tried setting perms on cacert.pem to 755 as the php file told to, and replaced it with a newer version from the upstream repo.
In the end, I had to modify
src/libraries/external/aws/lib/requestcore/requestcore.class.php
lines 612 and 613 from true to false, and comment line 614 to get around error.I ended up with this:
I can only assume I am now vulnerable to MitM attacks, but I really have no idea how else to get around this.