Arun -

I'm having the same exact issue.

I've spent over 2 weeks now trying to get my cloud installation up and running. Yesterday, I was able to access the store and download images. But due to other configuration issues, I reinstalled Eucalyptus using the UEC 11.04 cloud install and then updated and upgraded my installation.

Now I'm getting the same error and there doesn't appear to be anything online about how to fix it anywhere.

I'm guessing it may have to do with upgrading the system and tomorrow am going to try another fresh install with no upgrades.

Have you made any progress?

Well, it's nice to know I'm not the only one....

Arun and Zoran - Did you both update/upgrade your Ubuntu installations?

I'm wondering if some new update may have introduced this issue.

My knowledge of what's happening when you click on the store tab is very limited...since I can't find the EMI images anywhere on my machine, I'm assuming my machine is going out to the Internet and getting them from some location.

Eucalyptus staff - Is there somewhere we can download those images directly instead of going through the store?

How does the store "work"?

And is this an issue with the web server that is storing the images (meaning not a problem we are introducing)? Or some configuration issue on our end?

I'm so close to having a running cloud...

So if your store isn't working (still can't figure out why), you should be able to just download the necessary parts by following the URLs in the working "response":

//OK[1,["{\"states\": [{\"status\": \"uninstalled\", \"actions\": {\"install\": \"http://localhost:52780/api/images/aHR0cHM6Ly9pbWFnZXN0b3JlLmNhbm9uaWNhbC5jb20vYXBpL2ltYWdlcy9rYXJtaWMtYW1kNjQtMjAwOTEwMjc=/install\"}, \"image-uri\": \"https://imagestore.canonical.com/api/images/karmic-amd64-20091027\"}, {\"status\": \"installed\", \"eki\": \"eki-F3BD10E3\", \"image-uri\": \"https://imagestore.canonical.com/api/images/karmic-i386-20091027\", \"emi\": \"emi-DD6E105C\", \"actions\": {}, \"eri\": \"eri-07FC1141\"}, {\"status\": \"uninstalled\", \"actions\": {\"install\": \"http://localhost:52780/api/images/aHR0cHM6Ly9pbWFnZXN0b3JlLmNhbm9uaWNhbC5jb20vYXBpL2ltYWdlcy9sdWNpZC1hbWQ2NC0yMDEwMDQyNy4x/install\"}, \"image-uri\": \"https://imagestore.canonical.com/api/images/lucid-amd64-20100427.1\"}, {\"status\": \"uninstalled\", \"actions\": {\"install\": \"http://localhost:52780/api/images/aHR0cHM6Ly9pbWFnZXN0b3JlLmNhbm9uaWNhbC5jb20vYXBpL2ltYWdlcy9sdWNpZC1pMzg2LTIwMTAwNDI3LjE=/install\"}, \"image-uri\": \"https://imagestore.canonical.com/api/images/lucid-i386-20100427.1\"}, {\"status\": \"uninstalled\", \"actions\": {\"install\": \"http://localhost:52780/api/images/aHR0cHM6Ly9pbWFnZXN0b3JlLmNhbm9uaWNhbC5jb20vYXBpL2ltYWdlcy9tZGItYXBwbGlhbmNlLTIwMTAwMTIw/install\"}, \"image-uri\": \"https://imagestore.canonical.com/api/images/mdb-appliance-20100120\"}, {\"status\": \"uninstalled\", \"actions\": {\"install\": \"http://localhost:52780/api/images/aHR0cHM6Ly9pbWFnZXN0b3JlLmNhbm9uaWNhbC5jb20vYXBpL2ltYWdlcy9tZWRpYXdpa2ktZGVtby1pMzg2LTAuMQ==/install\"}, \"image-uri\": \"https://imagestore.canonical.com/api/images/mediawiki-demo-i386-0.1\"}]}"],0,5]

For example, the karmic i386 link above points to:
https://imagestore.canonical.com/api/images/karmic-i386-20091027

Once accepting the certificate, that shows a page listing the individual needed components:
Image: http://imagestore.canonical.com/files/karmic-i386-20091027/image.tar.gz
Kernel: http://imagestore.canonical.com/files/karmic-i386-20091027/kernel
Ramdisk: http://imagestore.canonical.com/files/karmic-i386-20091027/ramdisk

From the contents above you know what to assign for eri, emi, and eki codes.

So you can manually add images to the cloud. Still would be nice to get the store working though.

So it turns out the error is being thrown by the Python-based Image Server Proxy.

You can see this process running (ps aux | grep proxy) and it will tell you where it's keeping it's log file.

Viewing the log file you see the same error that appears in web interface. I compared the ca-certifiates.crt file that was on my working cloud controller with the one on my non-working cloud controller and they were identical.

Does anybody know what a CRLfile is? Or if that's even needed?

I googled to a blog where they said one should update certificates:

sudo update-ca-certificates

but that didn't help.

Alright, to make sure I didn't screw things up, I did a fresh UEC 11.04 server install with cloud, sc, cc, and walrus.

Installation process went fine.

As soon as the system started up, I went to the website and the Store tab. Still getting the Error 60 message.

This definitely leads me to believe that this issue is now an external/3rd party issue because this same installation DC worked without flaw 4 days ago.

I'm going to perform a full system update/upgrade and see if that resolves anything.

If not, I can only assume that whatever website or webpages the Image Server Proxy was attempting to access has somehow changed or modified things (possibly its cert) such that the default UEC 11.04 install no longer works.

If anybody else has performed a recent UEC 11.04 install and gotten the Cloud image store to work, please post and let us know...Thanks!

Tried apt-get update/upgrade on the clean installation. Still no success...

Few more things left to try...

I'm too getting the same error
ERROR 60 : Server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
Pls help... Would be great if someone comes up with a solution...

I have tried for several hours to figure out which server certificate that is invalid or where the image-proxy makes the call. Anyone that has a hint on resolving this?

Do you know when this might be fixed for good?

Same issue here after a vanilla install of 11.04 and I can't get to the store without the following error:

Error 60: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt
CRLfile: none

Guys,

I don't see a solid solution for this issue yet. A fresh installation to install images, I still see the error no matter what I modified. Where is this bug coming from and what steps to take in action?

Thanks in advance
Gokhan Gun

I was also almost desperate until I found this link:
http://realmike.org/blog/2011/01/02/ssl-certificate-error-with-gwibber-a...

The problem is that the certificate of canonical, which is signed by Godaddy, is not trusted by the host (all the trusted CA is listed in the /etc/ssl/certs, and our CLC host cannot find this certificate in the trusted list). So what we need to do is to download the certificate of imagestore.canonical.com, and add it to the trusted list (it's not CA, but it's fine, just like when browsing the website you add an exception).

So first you go to https://imagestore.canonical.com/. The page cannot be found but it doesn't matter. If you are using Firefox, you can click the left side of the url, or if you see any small lock indicating that you can view the certificate file, click it and export the file to the server (the cloud controller). Then follow the reference link, copy the certificate to /usr/share/ca-certificates/; run "sudo dpkg-reconfigure ca-certificates" to install it. Then check your website again and you will see the list of the images appearing in the "store" page :DDDDDD

Hello everyone,

Are there any news on that subject? I also face the same error, and so far I have tried everything listed in the post except for those changes in fetch.py.

Thanks a lot!

Any help?