WS03 Certificate Services Web enrollment from other Windows versions

Posted on Updated on

Certificate Services are the Public Key Infrastructure (PKI) services from Microsoft for Windows Server 2003. A PKI consists of a hierarchy of 1 or more Certificate Authority (CA) entities. A component of Certificate Services is Web, used for enrollment of certificates via a web based way. Enrollment can be simply translated in this case as “requesting & receiving”. On WS08(R2) Certificate Services has become a part of Active Directory (AD) and is renamed as Active Directory Certificate Services (AD CS).

When you browse to a CA’s Certificates Services Web (http://DOMAIN/certsrv) from a system with Vista, WS08 or higher, you receive the following error if the CA is running WS03 SP2 (with WS03 pre-SP2 you get another error; more about this later):

Figure 1

This error isn’t some web server error, network error, browser error or something like that. No, it’s an error coming from Certificate Services Web itself. These are the details:

Title: Microsoft Active Directory Certificate Services

Title within the web page itself: Microsoft Active Directory Certificate Services —

Title of the error: Error

Error: The certificate enrollment page you are attempting to access cannot be used with this version of Windows. To enable Web certificate enrollment for clients running Windows Vista, your administrator must update all Windows CA Web enrollment pages. To learn more about this issue and the steps needed to update Web enrollment pages to support all versions of Windows, see:

Note: the titles’ “Active Directory Certificate Services” doesn’t refer to the new name since WS08, so don’t be confused. The CA is definitely running WS03 and not WS08(R2).

It could be interesting to know a little bit about COM and ActiveX, but you can skip the next section if you want.

First a little bit about (D)COM…

The event source DistributedCOM refers to Distributed COM (DCOM), the “network” (“distributed”) version” of Component Object Model (COM). COM is a model based on objects, representing software components. Some software pieces (components) are built based on this model and they are often called “COM objects”. COM makes it possible to create modular software components that can be called and loaded at runtime and on-demand across process boundaries, making interprocess communication possible. It’s similar to CORBA and Java Beans. COM was introduced by Microsoft in 1993 and was the successor of the older Object Linking and Embedding (OLE) technology, which was introduced in 1991, targeted compound documents only and built on top of an even earlier technology called Dynamic Data Exchange (DDE). DDE was born in 1987 and made it possible to send and receive message in “conversations” between applications; OLE was building on that and became the first object based framework for software componentry and interprocess communication, but still only limited to compound document scenarios… This changed with the next version, launched in 1992 and included in Windows: OLE 2. This was the first “general-purpose” object based framework for software componentry and interprocess communication. As already said, the technology has been replaced with a new, more modern COM in 1993. Besides all this Microsoft also released a similar mechanism for use in Visual Basic (VB): Visual Basic Extensions (VBX). In 1994 OLE was updated with a successor for VBX, called OLE custom controls (OCX). At the same time Microsoft stated OLE 2 was just renamed to “OLE”, wasn’t officially an acronym anymore and was a collection name for all their component technologies. So the name OLE as a specific technology name “died” and became a synonym for all the Microsoft implementions of this technology type. How confusing is that?! Anyway, in 1996 Microsoft used OCX in IE, renamed all their OLE technologies related to the Internet to ActiveX (calling ActiveX objects “ActiveX controls”) and began starting to rename other OLE pieces to ActiveX too, except for the compound document part. Later in 1996 COM got a “network version”, called DCOM, meant to compete with other network technologies like CORBA. Microsoft launched an extension to COM, called Microsoft Transaction Server (MTS), with Windows NT 4. This was included with Windows 2000 and renamed COM+. It included a lot of new features, including support for distributed transactions and event publication and subscription. These events are called COM+ Events and make use of the Microsoft Message Queuing (MSMQ) technology. Components using this system are called Queued Components. The introduction of the .NET Framework made the whole OLE/COM/… technology set legacy, although it’s still possible to make use of those mechanism from .NET applications through COM Interop. A COM object is exposed through one or more interfaces, defined with the Interface Definition Language (IDL). Different threading models exist for COM objects at the “COM server side”. Every COM object and thread is assigned to a conceptual entity called an apartment. There can be only 1 COM object related to an apartment, which can have multiple threads assigned to it though. The way threads are assigned to an apartment is called the apartment model. For example, Single-Threaded Apartment (STA) is a model that states only 1 thread can be assigned to an apartment (and thus to a COM object).

A COM object is of a certain type (class). A class is identified by a class ID (CLSID) and an object by an application ID (AppID). Both IDs are Globally Unique Identifiers (GUIDs). COM objects can be called by other software (COM clients) that tries to make use of the functionality of those COM objects. Of course the COM objects should be loaded by and made available through some kind of a (local or remote) COM server (COM provider), which actually exposes the object’s interface. For example, a weather application could be implemented as a COM object and be used by Internet Explorer (IE), so IE is the COM client communicating with a COM server that hosts that COM object. A COM object is reusable and can also be consumed in complete different scenarios and exposed by different COM servers, even on the same system and simultaneously. A COM server can be implemented by an executable and thus run as a standalone process, outside other processes and exposing COM interfaces to COM clients (local or remote). A COM server can also be implemented by a DLL (typically with the .dll or .ocx extension) and thus run inside another process, while offering COM interfaces inside that process (but not outside). The first type is logically called an out-of-process COM server, while the 2nd type is called an in-process COM server. The 2nd type can be implemented in a special way though (as a DLL Surrogate), making it possible to be loaded in a surrogate executable (by default that’s the DLL Host Manager, dllhost.exe, which can appear more than once on a Windows system), which then acts as an out-of-process COM server, so it gets the same benefits as the first type of COM server. COM server files contain already the COM objects they should take care of. In the case of IE and the weather application, the weather COM object is typically implemented in a DLL, serving as an in-process COM server, which is loaded into IE, which as a whole is the COM client. Both types of COM servers can be used as a Windows service. A lot of Windows services are actually in-process COM servers containing a COM object which represents the “real” Windows service functionality and being implemented in a DLL file; such DLLs are loaded by generic Windows service host processes (svchost.exe). As you probably know, the Service Control Manager (SCM) sets up and maintains this whole set of Windows services.

If the COM object resides on the local system, it’s all about simple, classic COM. When COM clients and servers on different systems talk to each other (so over the network), we speak of DCOM. DCOM implies the DCOM network protocol. If a COM server can serve calls from over the network, it’s a DCOM server. DCOM should be considered as more than just calling a COM object over the network: it’s used A LOT for all kinds of remote scenarios, including for remote management purposes, and you would be surprised which mechanisms build on top of it. (D)COM is a powerful, but difficult technology. It has its benefits, but also its disadvantages. It’s becoming more and more something legacy though and a lot of scenarios already have a more modern solution now (for example, WMI (Microsoft’s implementation of WBEM) will use WinRM (Microsoft’s implementation of WS-MAN) as the transport protocol, although DCOM will still be supported for compatibility). (D)COM uses Remote Procedure Call (RPC) as the underlying mechanism for the transport of so-called Remote COM messages. For local COM this kind of RPC is called Local RPC (LRPC, or Leightweight RPC), also named Local Procedure Call (LPC), for the transport of so-called Local COM messages. Oh yes, have you heard of (COM) monikers? Well, these are special COM objects which identify other COM objects you might need. So they have some kind of an intermediate and referring role. COM clients calling them are called moniker clients, while COM servers hosting them are called moniker providers.

When a COM server is started, COM objects aren’t active yet. You need activation permissions to activate (create/instantiate) a COM object: there is a Local Activate (LA) and Remote Activate (RA) permission. If an activation is attempted when an object’s COM server hasn’t been launched yet, you also need launch permissions for that object: a Local Launch (LL) and a Remote Launch (RL) permission exists. Last but not least, there are also Local Access (Local Access calls, LC) and Remote Access (Remote Access calls, RC) permissions which determine who can call the COM object. Asking activation (and so possibly a launch) occurs through the “DCOM Server Process Launcher” Windows service (with the technical name “DcomLaunch”). The activation information has been registered in the registry by the COM server at installation time. Oh, if you wonder what this launch is all about, it depends a little bit on the type of COM object. For instance, for an out-of-process COM object not related to a Windows service (type “Local Server”), the related executable is started. For a COM object related to a Windows service (whether out-of-process or in-process) (type “Local Service”) the service is started.

I’m not going deeper about (D)COM in this blog post, as it would take me way too far. You know more than enough for this article.

Side note: the event source DistributedCOM is technically registered with the name “DCOM” (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\System\DCOM). No DLL is configured here, but there is a referral to a GUID ({1B562E86-B7AA-4131-BADC-B6F3A001407E} ) for more information through the REG_EXPAND_SZ named value providerGuid. A provider with this GUID is registered in the registry at the location HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\{1b562e86-b7aa-4131-badc-b6f3a001407e} (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers is the place where event providers are registered), which contains the provider’s name (Microsoft-Windows-DistributedCOM) and the DLL that is used for the event logging (oleres.dll).

Side note: for completeness it could be interesting to know what OLE DB is. It stands for “Object Linking and Embedding, Database” and is also called OLEDB or OLE-DB. It has nothing to do with the technology that was formerly called OLE, but it’s a set of interfaces exposed through COM to access data from different kinds of sources in a uniform way. OLE-DB is a successor of ODBC and extends the functionality with non-relational databases too (so it’s broader than just SQL). ODBC, by the way, stands for Open Database Connectivity, is similar to JDBC and offers applications access to DBMS systems in a uniform way, with ODBC drivers as intermediates for the translation, while the ODBC Driver Manager (DM) takes care of the loading of those drivers. ODBC drivers exist for many, many DBMS systems, like MySQL, Oracle, SQL Server,… An OLE DB-ODBC bridge exists to make it possible for applications to use OLE DB, while under the hood the requests are forwarded to ODBC. ODBC was first released as version 1.0 in 1992 and the latest version is 3.8 (included in Windows 7). OLE DB also has some kind of translation engine between applications and data sources and it’s called an OLE DB provider, while the applications using OLE DB are called OLE DB consumers. The future of OLE DB is unclear and it seems it will become something legacy soon. Even the older ODBC is called better for performance… Another data source interface is Jet Data Access Objects (DAO), which was launched with version 1.0 in 1992 under the name of VT Objects, but is deprecated now, leaving version 3.6 as the latest one. Also old and forgotten is Remote Data Objects (RDO), which could connect with ODBC. Anyway, the latest is ActiveX Data Objects (ADO), a set of interfaces exposed through COM and using OLE DB “behind the scene”. The .NET variant of ADO, ActiveX Data Objects for .NET (ADO.NET), is quite different though, but builds on OLE DB too. Don’t be confused with ADO.NET Entity Framework (EF), which is the object-relational mapping (ORM) framework of ADO.NET.

The error… And the solution…

Ok, the error… Well, Certificate Services Web uses an ActiveX control called Xenroll. If you browse to Certificate Services Web and Xenroll isn’t installed or the installed version is older then the one from the site, the site’s Xenroll COM object is downloaded and installed (you need the permissions to install of course). Xenroll isn’t supported on systems with Vista, WS08 or higher though, so you can’t use Certificate Services Web from them. Again, we’re not talking about AD CD Web here, but only about the Certificate Services Web from a WS03 CA!

If your CA runs WS03 pre-SP2 the error tells us “Downloading ActiveX control” and nothing else happens. If your CA is running WS03 SP2 though the enrollment pages are already a little bit smarter: they still use Xenroll and it’s still not supported on Vista, WS08,… but they are already aware of the fact that those newer Windows versions can’t install/run Xenroll (even a manual installation would fail). That’s why WS03 SP2 Certificate Services Web shows a different error, i.e. the one from figure 1. It says you should install an update on your CA, so new, updated enrollment pages get installed which can be used from older and newer Windows versions. So WS03 SP2 was aware of the issue and of the existence of an update that fixes all this. So why didn’t WS03 SP2 include the fix already then? Well, let’s say this was a timing issue: at the time SP2 had to be released that fix wasn’t available yet.

But what does this fix make so special? Well, it updates the enrollment pages, so they can detect the client OS version. If an older (pre-Vista) Windows version is detected, Xenroll is used, otherwise a set of COM objects, together called CertEnroll, is taken. AD CS Web works the same way, but Xenroll doesn’t make it possible to use the full functionality; so using AD CD Web (on WS08) from a pre-Vista system only allows limited functionality. Anyway, CertEnroll is already installed on Vista/WS08 and later systems, but of course it’s always possible newer versions of CertEnroll can be available through AD CS Web, causing a new download and install attempt. Similarly, Xenroll is installed on pre-Vista systems, but those can be upgraded too when Certificate Services Web would provide a new version. Of course it’s always possible to uninstall the Xenroll or CertEnroll; in this case the web enrollment site will cause a download and installation attempt. Note that IE settings determine how executing, downloading and installing ActiveX controls works.

Microsoft KB article 922706 (, titled “How to use Certificate Services Web enrollment pages together with Windows Vista or Windows Server 2008″, deals with the issue too. To download the update, please browse to (“Update for Windows Server 2003 (KB922706)”). The update is from the 25th of February 2008, has a file size of 544 KB and is implemented by the WindowsServer2003-KB922706-v7-x86-ENU.exe executable. You may have to restart after installation, although this wasn’t needed when I tested it on 2 servers.

It’s recommended to back up %systemroot%\System32\Certsrv folder before installation (you never know, right?). When you install the update, you have to click “I Agree” on the 2nd page. A few different phases pass by while installing, including backing up.

Figure 2

Figure 3

Figure 4

Figure 5

After installation of the update you can access the page the way it should be:

Figure 6

Some background information

Xenroll is implemented by the DLL xenroll.dll in %systemroot%\system32, containing 2 COM classes:

  • CEnroll Class: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{127698e4-e730-4e5c-a2b1-21490a70c8a1}
  • CEnroll Class: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{43F8F289-7A20-11D0-8F06-00C04FC295E1}

Both classes have the same name, but have a different CLSID. The “C” is a prefix for “Class”. It’s clear Xenroll is an in-process COM server/object, based on the 2 COM classes.

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

CertEnroll, on the other hand, is used on Vista/WS08 and later. If you surf to the web enrollment site, make a choice, then another one, you arrive at a page that actually loads CertEnroll. You can see the proof of this by comparing the currently loaded add-ons in IE before and after arriving at this page. The name of the add-on is “X509 Enrollment WebClassFactory”.

Figure 13

We see the CLSID is {884e2049-217d-11da-b2a4-000e7bbb2b09}, located in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{884e2049-217d-11da-b2a4-000e7bbb2b09}. The base of CertEnroll is a standalone COM server/object, implemented by CertEnrollCtrl.exe in %systemroot%\System32 and also %systemroot%\SysWOW64 for 64 bit Windows. The file’s description sounds logic: “Certificate Enrollment Control”. The 64 bit version is always used on 64 bit Windows, even from 32 bit IE, as this causes no real problem, because CertEnroll runs in its own process. If you want to use the 32 bit version of CertEnroll you have to take care of that explicitly (for example, if you create an application that would use CertEnroll, you can explicitly call for the 32 bit version).

Figure 14

Figure 15

Figure 16

When IE has the add-on loaded, we can see in Task Manager CertEnrollCtrl.exe is indeed started (and it certainly wasn’t before the page was loaded!):

Figure 17

In Process Explorer we can see this process also contains the DLL CertEnroll.dll, from the same folder as the executable.

Figure 18

The DLL is described as “Microsoft® Active Directory Certificate Services Enrollment Client”, referring to the new name (Active Directory Certificate Services), even when connected to WS03 SP2 (CertEnroll is also used for AD CS, hence the new name). It’s obvious the control can be considered as an “enrollment client”.

Figure 19

This DLL contains a lot of COM classes, some of them shown in the next 4 figures:

  • X509 Certificate Template AD Writable: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{8336e323-2e6a-4a04-937c-548f681839b3}
  • ObjectId: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{884e2000-217d-11da-b2a4-000e7bbb2b09}
  • Etc.

The DLL is an in-process COM server/object based on all those classes and is loaded by CertEnrollCtrl.exe.

Figure 20

Figure 21

Figure 22

Figure 23

Digital signatures, SSL and IE

It’s interesting to know xenroll.dll is digitally signed, while the Xenroll files aren’t.

Figure 24

Figure 25

This has an impact on the experience in Internet Explorer (IE). With Xenroll there isn’t a single problem. But CertEnroll is a different story. There is an IE setting that determines the behavior for running an ActiveX control that’s unsigned or not signed “correctly” for example, with an expired certificate). This setting exists for every IE zone. For example, if your site belongs to the “Local Intranet” IE zone, this zone’s setting is of importance. To check or change this setting, select Internet Options from IE’s Tools menu and select the Security tab in the Internet Options dialog box. Select the right zone and click the button “Custom level…”. A new dialog box pops up, showing many setting in the section Settings. All the settings are categorized; go to the category “ActiveX controls and plug-ins” and look for the setting “Initialize and script ActiveX controls not marked as safe for scripting”. This setting determines if “unsafe” ActiveX controls (i.e. which are unsigned or not signed “correctly”) may be initialized and “scripted” (executed). Possible values are Disable, Enable and Prompt.

Anyway, if the value is Disable, you actually tell IE that ActiveX controls like the one from CertEnroll can’t be executed, so web enrollment fails. You get the error from figure 27:

Figure 26

Figure 27

This is the content of the popup:

Title: “Message from webpage” (this sounds a bit unprofessional, isn’t it?)

Text: “In order to complete certificate enrollment, the Web site for the CA must be configured to use HTTPS authentication.”

When the value is Prompt, you will get this prompt:

Title: “Internet Explorer”

Text: “An Active control on this page might be unsafe to interact with other parts of the page. Do you want to allow this interaction?”

Figure 28

If you don’t accept (by clicking “No”), you get the same result as if the value had been Disable. If you do accept though (by clicking “Yes”), you get the same result as if the value had been Enable:

Figure 29

Title: “Web Access Confirmation”

Text: “This web site is attempting to perform a digital certificate operation on your behalf:


You should only allow known Web sites to perform digital certificate operations on your behalf.

Do you want to allow this operation?”

Now, take a good look at this box. I said “a GOOD look”. This message actually comes from the ActiveX control itself. When you get at the page that needs CertEnroll, CertEnrollCtrl.exe is started as a separate process. This doesn’t mean though IE actually uses it as an add-on. That depends on the value of the IE setting we were talking about. So even if you don’t allow the control to do its work, the exe will still be started (and it keeps running…!). If you would kill that process the error from figure 27 pops up after clicking Yes when prompted or when figure 29 is the current situation.

Oh well, that being said, what’s this message all about? Don’t be afraid, it’s not bad stuff, although you would think it’s an error or a warning at first sight. This message is by design and cannot be got rid of. I’m sorry, but that’s the way it is… Or not? It depends. On Vista SP2 the code flow is different from the flow on Windows 7. On Vista SP2 CertEnroll “thinks” it’s not running to be a browser add-on if “Initialize and script ActiveX controls not marked as safe for scripting” is enabled and thus skips the message (incorrectly actually, although most people would like the control to behave this way J). On Windows 7 CertEnroll seems to be smarter and always shows the message, as it’s intended to be. Well, it’s intended to show the warning when it runs as a browser add-on, but not in other scenarios. For example, you could create an application that calls CertEnroll; even if this application is ran from the web (but not as a browser add-on!), CertEnroll won’t show the message. Note that the Vista SP2 behavior is overwritten by the intended behavior (like on Windows 7) after installing a certain hotfix (i.e. the one related to Microsoft KB 983557 (; “Error message when you try to request a certificate in Windows Vista or in Windows Server 2008: “The filename or extension is too long. (0x800700CE)””)), as those include a newer CertEnroll that’s behaving correctly. The “incorrect” version is 6.0.6002.18005, while the correct version on Vista is 6.0.6002.22401.

It could be that CertEnroll doesn’t work in IE on Windows 7 or WS08R2 under certain circumstances. In that case the fix related to Microsoft KB 2078942 ( should probably help. The KB article is titled “The CertEnroll control does not work in Internet Explorer on a computer that is running Windows 7 or Windows Server 2008 R2”.

The message CertEnroll wants to tell us the web site wants to do an operation (related to digital certificates) on your behalf (i.e. through the CertEnroll control of course). It also warns us we should only let trusted sites do this. Then we have to decide what to do. In my opinion this message is acceptable. Of course defense-in-depth (multiple layers of security) is a good thing, but if the site belongs to a zone which may execute ActiveX controls (automatically or after prompting) and you are running with the right permissions, it should be okay. Of course there are sites which you want to let run ActiveX controls, but without giving them a chance to touch riskier stuff. In that case such a warning is very useful. On the other hand members of the zones “Local intranet” and “Trusted sites” could be considered secure enough, although that’s not always true: you could have different kinds of trust, even within the same intranet. Perhaps a redesigned zone system could offer the best solution, but in the meanwhile CertEnroll is probably doing the best job (especially because of the very sensitive nature of the operations involved here, don’t forget that!), although not the nicest, I agree…

The certrqma.asp page, by the way, is the page that needs CertEnroll.

One last thing: I must admit I don’t really understand the error from figure 27. I don’t see any reason why the CA’s web site should use SSL (so HTTPS) for authentication. I guess this is just a bad error that shouldn’t be interpreted literally. The whole story of this blog post is completely independent from whether you use HTTP or HTTPS for your CA’s web site (so yes, if you want, you can use HTTPS, that’s up to you).


Well, I hope this post was worth writing it. Thanks for reading and have a great time requesting certificates!! 😉




3 thoughts on “WS03 Certificate Services Web enrollment from other Windows versions

    prescription glasses for kids said:
    14/01/2013 at 00:17

    Hi there! I could have sworn I’ve visited this website before but after looking at some of the articles I realized it’s new to me.
    Anyways, I’m definitely delighted I stumbled upon it and I’ll be book-marking it and checking back regularly!

    cupula digital said:
    17/01/2013 at 21:19

    Hi there every one, here every person is sharing these
    know-how, thus it’s fastidious to read this weblog, and I used to visit this webpage every day.

    prescription glasses for kids said:
    30/01/2013 at 09:11

    If you desire to increase your knowledge just keep visiting this web site and be
    updated with the latest news posted here.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s