I am having the exact same problem. I found out something that may or may not be useful in tracking this down. I won't be able to get back to it until next week, but maybe it will help someone help us in the meantime.

I went to the server itself, into a web browser on the server. I typed https://localhost, and I was immediately greeted with a page saying there was a problem with the certificate, but I continued and I got to the web access screen. However, if I typed in https://<servername>, nothing happened at all. So, by using "localhost" it seems the web access is being hit, but by using &lt;server name&gt;, or even &lt;server IP&gt;, nothing happens at all. I don't know why that is, because I am not a Tomcat expert, but it seems that this might be why the install fails. I tried to use localhost in the install, but then I got a warning telling me that if I did that external VI clients would not work, so I did not continue.

I think that KB article either is not the same thing, is sort of misleading, or is not including everything. Because, AFAIK, spaces and dashes would be ASCII characters. That KB only talks about non-ASCII characters. Anyway, I believe this is a bug that needs to be fixed. Spaces and dashes are perfectly acceptable characters in passwords in Windows, and are used by some to make passwords more secure by allowing long, complete sentences to make an easily remembered but complex password.

OK, I have been through this trhead and my installation problems persisted. I changed passwords, shortened them to 8 charactters, using only alpha-numeric, still the installation errors persisted.

I finally found it: my server has a service already listening on port 443...  VirtualCenter 2.5 now uses both port 80 AND 443 by default. If your VC server already binds 443 to some other application (which was a non-issue in VC 2.0 and below), then you hit the wall. The most obvious fact that tells you have this issue is this: when you start the VI client, you can loging using "localhost" but not the DNS name of your server. A quick look at the netstat command with VirtualCenter Server service stopped should also reveal port 443 in use.

The VI 2.5 client relies on ports 80, 443 and 902 (by default) to communicate with the VI server (but I can tell you that if port 443 is missing, you won't connect). I removed my other 443 port using application and everything came back to normal.