This content has been marked as final. Show 12 replies
I guess its one of those inexplicaple pathes from MS.
I guess it somehow disables the MS Windows High Encryption Pack which lists the Crypt providers.
Plus I am also facing a problem.Have you ever tried to customize the CMS using your own plugins ,servlets etc..
as the documention for CMS_SDK is not comprehensive .. I am facing a lot of problems understanding the internals of CMS.
Can you through some light on this.
ANy help would be welcomed.Thanks in advance
as we are also evaluating your software at the moment it would be nice to get this patch. (I couldn�t find it anywhere on your website) Without it further testing seems not possible :(
Please answer here ASAP or contact me at firstname.lastname@example.org
thanks in advance
ps: The Problem even occurs with Windows XP where no patch Q323172, is installed...
This patch is available only throught Product Trekker ===>
If you have a contract, you should have a login/password too.
This patch is included in the version 4.7SP1
If you don't have access to Product Trekker, please contact the support here ===>
I had the same problem some time ago, but finally found something that fixed it (thanks to Tony Genovese and Dhiva from doegrids.org):
- Microsoft Q323172 patch and newer versions of Internet Explorer activate the "kill bit" of ActiveX Control "xenroll.dll", which is the responsible of submitting certificate requests.
- This causes xenroll.dll to become inactive. In order to solve this, Q323172 patch and newer versions of IE provide a new "xenroll.dll" ActiveX Control.
- The problems appear when using this new ActiveX Control with Sun Certificate Server 4.7. The .html end-entity forms are not updated, so they can't find the newer version of "xenroll.dll".
- Some things to look for and change:
I changed this definition in most of the Man*.html files,
although I am only using ManUserEnroll.html at this time.
I also needed to change the definition in these files:
University of the Balearic Islands
I ran into the same issue and found a partial work-around (after about 10 days of research and trial and error.)
The problem is that this issue is not simply a server-side problem. Updating the certificate server's xenroll.dll files and changing the class IDs in the appropriate files (manually if you have customized them as I have) only takes care of half of the problem.
Each client machine uses xenroll.dll and looks for its specific class ID. If a client machine has not been updated but the server has, you will not receive an error - you simply will not get any cryptographic providers in the enrollment forms drop-down list.
For client OS's that automatically update, like Windows ME and XP, chances are the changes have already been applied and you will not have an issue.
Our primary problem has been with the Windows 2000 clients. The only solution we've been able to devise is to manually alter the enrollment forms to redirect users to a Help Page when there are no cryptographic providers present. This can best be accomplished in the FindProviders Providers VBscript function that populates the enrollment form.
Not the most elegant solution, but not a minor SNAFU on Microsoft's part either...
You're quite correct. We solved this problem by adding a message in the HTML form telling the user that if the cryptographic providers list is empty, he has to install the famous Q323172 hotfix (we also added a link for downloading the patch).
"...Each client machine uses xenroll.dll and looks for its specific class ID. If a client machine has not been updated but the server has, you will not receive an error - you simply will not get any cryptographic providers in the enrollment forms drop-down list."
Not the most elegant solution, too :)
<OBJECT classid="clsid:127698e4-e730-4e5c-a2b1-21490a70c8a1" id="IControl1"><height="0"></OBJECT>
<OBJECT classid="clsid:43F8F289-7A20-11D0-8F06-00C04FC295E1" id="IControl2"><height="0"></OBJECT>
On Error resume next
Set IControl = Null
' clear error queue
err.Number = 0
' Test the latest control to see if it loaded.
provider = IControl1.enumProviders(0,0)
if err.Number = 0 then
' Yes it did.
Set IControl = IControl1
' The new control did not load. Try the old one...
err.Number = 0
provider = IControl2.enumProviders(0,0)
if err.Number = 0 then
Set IControl = IControl2
Set GetIControl = IControl