Amazon fails

In case this helps a problem solver: I was able to save to Amazon S3 with a site hosted with hostmonster.com, but it doesn't work on a site running Ubuntu Server 8.04 LTS on the Rackspace cloud. The problem for me seems to do with the file name of my server's SSL certificate. One error:

S3::putObject(): [77] error setting certificate verify locations: CAfile: /etc/ssl/certs/ca-certificates.crt CApath: none  in /home/[...]/sites/all/modules/backup_migrate/includes/S3.php on line 357.

turns into the error:

S3::putObject(): [60] SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in /home/[...]/sites/all/modules/backup_migrate/includes/S3.php  on line 357.

when I copy the .crt file in order to create ca-certificates.crt which the module seems to be expecting. It appear the module doesn't set the .crt filename, and Amazon looks for the default name ca-certificates.crt? I'm not sure how to fix this though.

This is most likely an issue with your network config, have a look for HTTP request status:Fails in your status resport.

I had the same error trying to run backups on a local domain. I *think* https request needs to be resolved via DNS for this to work, as soon as I tried it out on an globally accessible domain it works fine.

Did you have any luck with this?

Did you have any luck with this?

Update:

Replies do not seem to be threading. I was addressing @checkmark

I have another problem with S3:

S3::putObject(): [6] Couldn't resolve host 'mybuckupname.s3.amazonaws.com' v súbore /var/www/html/sites/all/modules/backup_migrate/includes/S3.php na riadku 357.

I have seen this issue on various servers, and it is because of a server misconfiguration -- curl is not properly configured to find the CA file (as post #1 implies). And/or the ca certificate file it does find doesn't contain the proper certificates for Amazon S3 (there is a curl bug on Redhat that implies this: https://bugzilla.redhat.com/show_bug.cgi?id=525496 -- but I haven't actually gotten to a Redhat system to try it out on).

At any rate, as a workaround you can hack the backup module to avoid client-side certificate validation by editing backup_migrate/includes/S3.php and on line 1161 changing
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, 1);
to
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, FALSE);

I might consider making that change to that file if it helps people work with S3 better. Does anybody know what the security implications of not validating the certificate would be? As I understand it, blindly trusting the certificate wouldn't affect the level of encryption at all but could it leave users vulnerable to a man-in-the-middle attack or some such?

This just started happening on two of my sites on 9 and 10 November with the error:

S3::putObject(): [60] SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in /[***]/sites/all/modules/backup_migrate/includes/S3.php on line 357.

I'm using the European buckets on S3.

Odd, I changed line 1161 to "False" and I still got the same error.

I do not know how to read for the errors, but I get the same error message as sean69 "Could not run backup because the file could not be saved to the destination."

I am using Site5. What hosting services are you guys using?

Thanks klflote, the hack you suggested works.

I'm also interested in knowing the security implications of the hack in #6. I'm not qualified to weigh in too heavily on this, but here are my thoughts, and I'd like to know others' opinions on this:

If we accept that it's impossible for anyone to redirect the amazon s3 bucket url to a different address, then the hack above is no problem. The CA certificate check is useful only by giving assurance that a 3rd party (the Certificate Authority) has done some research (how much depends on the price of the SSL certificate) to confirm that the domain is owned by the person who claims to own it. If we trust that the bucket URL is owned by Amazon, then this check isn't necessary. The only flaw I can see is if someone can maliciously redirect the intended bucket URL to some other URL where they have setup a sophisticated Amazon bucket spoofer that would fool the Drupal site into still uploading the database.

Any thoughts?

Just ran into this on a fresh 8.04 LTS as well on Rackspace. I had encountered this problem earlier elsewhere so it's not a Rackspace problem as far as I can tell. Ubuntu Hardy just needs an updated CA cert.

apt-get install ca-certificates

should do the trick.