Sorry, running iFolder 3.8.0.3 on the server:

server:/var/log/apache2 # rpm -qa | grep ifolder
ifolder3-enterprise-3.8.0.10191.1-5.1.i586
novell-ifolder-enterprise-plugins-3.8.0.10191.1-3.2.i586

Try this:

-Exit the client.
-Make sure both iFolderApp.exe and Simias.exe are not running in task manager.
-Rename the following folder: %localappdata%\simias to something like oldsimias
-Launch iFolder
-The simias folder should get re-created with a new DB and corresponding files.
-The iFolder server info wizard should eventually prompt for you to enter in the IP or DNS and login info.
-At the point of authentication, you should get prompted to accept the cert. then you should be all set.

Typically, from what I've seen, reestablishing a new local DB in the simias dir seems to fix the certificate prompt..not sure why.

On a side note, if you do go through this process and you did have existing iFolders linked to your client, you will need to merge the server copy back down to your local instance.

Hope this helps.

Cool, that fixed it for the Windows XP machine, thanks! On the Win7 x64 box, it's still being contrary though; deleting the simias folders doesn't make it re-prompt for the SSL cert, so is it maybe storing the config somewhere else?

Try disabling the Windows or any third party firewall if enabled.  Also, run a repair on the app by exiting out of iFolder, kill any tasks running (simias/iFolderApp.exe) then going into the control panel/iFolder and repair the installed app from there.  If there is no repair option, run the installer over the current client.  Also, any recent .NET clients and or updates installed?  If so, try backing out one by one until you get the proper results..you may need to go to my earlier post on cleaning the simias directory in the local appdata folder as you go through the motions.

 

The other thing to mention is to make sure your a local admin to ensure everything is installed/registered properly on the system.  Should the above fail, try logging on to that Windows 7 system with another account/profile.  Is this the only Windows 7 device failing or are they all failing to prompt for the cert??

Cool. I built a brand-new unpatched Windows 7 x32 Enterprise VM, only thing installed was the iFolder client. This doesn't connect either, and gives the same error. It doesn't ask for me to approve the SSL cert either. I've attached the simias log file in case it helps out any?

If it makes any difference, this is running on openSuSE 11.3 32-bit, but I'm not sure why that would make it not work with Win7 when it works with other OSes.

I have a random question. I just can't get this figured out; was wondering if there might be a chance that someone could create me a temp account on one of their iFolder servers (even with a space cap of like 1KB) so that I could try to connect a win7 machine to it and see whether the problem is with the iFolder client (or something else on the client machine,) on the network, or something not set up correctly on my server? It's kind of driving me crazy not being able to figure out what's going on, and there just aren't any other projects like iFolder that I've been able to find. However, this problem is making it to where I won't be able to use iFolder if I can't get it figured out; it's wonderful being able to sync my XP and linux machines, but my win7 machine is pretty critical :)

Chris,

I had what seemed like identical symptoms that you are experiencing.  My problems started when I switched from a self-signed web server certificate to a CA signed certificate.  Whilst the web interfaces functioned as normal, the iFolder 3 client for Windows x64 (running on Windows 7) would not connect to the server.  My Mac OS X client was unaffected.

The Windows client had previously connected but stopped almost as soon as I made the switch with the certificates.  Looking at the iFolder client logs, it seemed that the client was simply timing out; I was convinced it was because of the new certificate I'd installed.  I tried numerous things including generate a new certificate from a different CA and completely un-installing and reinstalling the client software.  Nothing worked.

However, the solution was, for me, much more trivial in the end.  I noticed that the apache error log was always logging the warning "RSA server certificate CommonName (CN) 'fqdn' does NOT match server name!?".  This seemed to be inconsequential so I had ignored it but in my desperation to find a solution to the client connectivity problem I decided to fix it: I uncommented the ServerName directive in the /etc/apache2/vhosts.d/vhost-ssl.conf file and entered the FQDN of the server and restarted apache.  I then entered the URL https://fqdn:443/ into the set up dialog of the iFolder client.  Lo and behold - the client connected.

I don't know if this will actually help you but since it worked for me it might give you a clue about where else to look.

AWESOME! Thank you! I'm not totally there yet, but at least it's giving me hope! I'd seen those errors before as well, but wasn't sure how to address them because from what I could see, everything was reporting the hostname correctly.

 

I'm still able to log in through the web and linux clients fine, and on Windows it's now at least giving me an "invalid credentials" error. So it's at least talking to the server :)

 

I'll keep digging :o)

That ended up being it!! :D The user auth problem was because I still had the 3.8.0 client installed from my troubleshooting, so installing the 3.8.0.3 client fixed that. But the Apache fix is what took care of the problem!! Thank you so much!!! :D