Hi there!

We are aware of the xneroll issue, and are trying to come up with a solution. What you are experiencing could be two separate problems. XEnroll component is used only generate certificates and if you use existing certs, it should not matter.

The "ssl_error_rx_record_too_long" problem has not been reported before. Does it occur when an application serves pages, or when a new certificate is created? Could you please describe steps to reproduce this problem?

Thank you,
Best regards.
UltiDev Team.

Hello, Simone!

Thank you very much for excellent screencast showing how to reproduce the problem. One thing that it really helped us understand is that some requests are going through and some fail.

Would it be possible for you to send us your project so we could test it locally on XP VM? If you could, please attach password-protected ZIP file to your reply and send us password separately.

Another thing we would like to ask you: does this problem occur only with certificates generated by non-UWS/XEnroll? Or did you see the same problem with UWS certs as well?

Best regards,
UltiDev Team.

Here https://dl.dropbox.com/u...UWS/MvcApplication2.zip you can find a simple asp.net mvc 3 project that uses combres for compression and minification and that doesn't work unless you disable compression (compilation debug="true").
This is the first problem.
For the second one, I'm trying to reproduce it on a pet project: by now, trying and trying, I found that the WS behaves differently for different browser requests:
Attached vs2010 debugger

chrome post request (/Account/Logon) --> the debugger enter 2 times (?) in the Action method, steps to the RedirectToAction instruction, but nothing happens (SSL error)

Firefox --> as Chrome, except there is only one enter in the action method

i.e. 8+ --> it definitely works: one entry in the action method, redirect works!

I think I'm going crazy...

bye

If you want you may download the "final" product pointing to https://dl.dropbox.com/u...ers/PS100Installer4.zip in the .zip file launching PS100IVServerSetup.exe everything will be installed, the production web app will be registered within UWS on the tcp port 2378 and so you can freely test the behaviour.
If the installer goes ok, you should login to the app with "admin" as both user name and password: the UI is localized in italian, sorry, we are working on globalizing it.
btw I don't think it's a matter of compression enabled or not (why would it works in win7?)

thankyou
regards
Simone

Hi there!

Could you please try using IE and letting us know what kind of result you are getting. For us Internet Explorer worked while Chrome was giving the error.

Best regards,
UltiDev Team.

Hello, Simone.

Thank you for clarification.
No, we haven't yet found what is causing it. We are working on it though.

Best regards,
UltiDev Team.

Hello, Simone.

At this point we are quite confident that this problem is a manifestation of two Microsoft bugs working together:

1. On Windows XP http.sys always negotiates client certs even when instructed not to. Since hardly anyone uses http.sys on XP, especially with SSL, and even more so with client certificates, nobody seems to have noticed this problem. Microsoft is clearly aware of the problem as this is not happening on Windows 7, for example.

2. When client cert is negotiated with the client (usually a browser), as always happens on XP with http.sys configured for SSL (see problem 1), server tries to help the client with presenting eligible client certs by sending it server's list of trusted root certs, which on XP contains about 370 certs (compare to barely 40 on Windows 7). This huge number of certs is above what SSL protocol allows, so most clients deem it SSL error and quit - thus the error you have reported. On Windows 2003 this can be worked around by changing registry settings, and we'll test and try to fix it. On Windows XP, unfortunately, registry fix does not work, so the only way to make this problem go away is to remove some trusted root certificates on Windows XP, which UWS installer can't be tasked with, as this can easily be considered as malicious.

Fixing either of these problem would be a big help, although for SSL to work well with client certs, both would have to be fixed. But if client certs are not involved, fixing either would do. Unfortunately, our experience of working with Microsoft tells us that these issues are very unlikely to be fixed, especially given that XP is circa 2001, and three generations removed from the latest version: Windows 8. We will file this problem with Microsoft support, but realistically, SSL support on XP out of the box is unlikely.

Best regards,
UltiDev Team.

Simone,

It's not server certificates that need to be deleted, it's trusted root certificates. Unfortunately, different users may need different set of trusted root certs, and any software replacing or removing significant portion of trusted root certificates is virtually guaranteed to be deemed malicious. You could consider creating a whitepaper for your users that will suggest combining trusted root certs required by Windows XP itself with all root certificates of Windows 7 - this would drastically reduce number of root certs and allow SSL authentication to work as well as at Windows 7. However, UWS installer cannot be required to do this automatically due to problems described above. If users decided to do it, they should do it on their own risk.

Best regards,
UltiDev Team.

Thank you, Simone. We are glad this workaround makes life easier for you.

Best regards,
UltiDev Team.