SSL Error: certificate verify failed

Der Fehler wiederholte sich bis alle Versuche aufgebraucht waren, so dass das Backup aus S3 nicht ausgeführt werden konnte.

Ich habe zunächst auf die aktuelle Version von s3sync geupgraded, da ab der Version 1.2.3 laut README.TXT / Changelog ein Problem adressiert wurde das ggf. die Ursache für mein heutige Problem sein könnte:

Version 1.2.3
Fix SSL verification settings that broke in new S3 API.

Nach de Upgrade bekam ich dann zunächst den Fehler
You didn’t set up your environment variables; see README.txt
weil s3sync sein s3config.yml nun an einem anderen Ort erwartet. Ich habe also noch die s3config.yml an einen der nun verwendeten Pfade abgelegt:

$S3CONF/s3config.yml
$HOME/.s3conf/s3config.yml
/etc/s3conf/s3config.yml

Anschliessend konnte s3sync wieder auf sein s3config.yml zugreifen – aber ich erhielt weiterhin einen SSL-Fehler:

certificate verify failed (OpenSSL::SSL::SSLError)

Da ich wie im Betrag beschrieben den Weg über “ssl_cert_file” gewählt hatte und das im Readme verwendete Certificate genutzt habe, habe ich angenommen, dass dieses nun abgelaufen sei. Ich habe daher von der Konfigurations-Direktive “ssl_cert_file” umgestellt auf “ssl_cert_dir”.

Die unter http://mirbsd.mirsolutions.de/cvs.cgi/src/etc/ssl.certs.shar bereitgestellten certificates habe ich angelegt und in meinem s3config.yml mit

ssl_cert_dir: /home/user/s3sync/certs

eingebunden.

Seither läuft wieder alles bestens – auch mit SSL.

Fazit: Das im Readme von s3sync gegebene Beispielzertifikat kann offenbar nicht mehr verwendet werden. Man sollte gleich den besseren Weg über “ssl_cert_dir” gehen.

S3 command failed:
list_bucket lstesting max-keys 200 prefix delimiter /
With result 403 Forbidden
S3 ERROR: #

Mit den Parametern -v -d kann man den http Body ausgeben lassen:
$ s3cmd.rb -v -d listbuckets
list all buckets {}
Trying command list_all_my_buckets with 100 retries left
Response code: 403
S3 command failed:
list_all_my_buckets
With result 403 Forbidden
RequestTimeTooSkewed
The difference between the request time and the current time is too large.

Ursache war also eine verstelle Uhrzeit die sich nach einem Reboot noch nicht rasch genug aktualisiert hatte. Mit korrekt synchronisierter Uhrzeit ging es dann wieder ohne Probleme.