Certificate Enrollment from the Browser

  • Article

Back in Windows XP, an ActiveX control known as XEnroll could be used from the browser to request digital certificates on the client’s behalf. Certificate authorities and others would use this control when a customer purchased a certificate for code signing, server authentication, or other purposes.

In Windows Vista, XEnroll was deprecated (and prevented from loading in the browser) and replaced by CertEnroll. However, there are a few restrictions to be aware of when using the CertEnroll control:

  1. The control is only available on Windows Vista and later
  2. The control must loaded in a page delivered by HTTPS
  3. The control must be loaded by an <object> tag in the markup
  4. The control must be in the top-level frame

Prior to Windows Vista SP1, there was the additional requirement that the page must be in the Trusted Sites Zone. That requirement was removed for Vista SP1 and Windows 7.

Alex wrote a blog post about using the CertEnroll ActiveX control from JavaScript, which Vista+ users can see in action in these two pages:

You’ll note that the first page doesn’t work properly while the second one does. This demonstrates restriction #2. The CertEnroll control uses the SiteLock template to help ensure that it is being used securely. For Windows Vista SP1 and later, the control is configured to Allow running from https://* .

The SiteLock code will evaluate the hosting security context when asked if the control’s interface is SafeForScripting and SafeForInitialization. It will return E_FAIL if the security context is not permitted to use the control.  Within Internet Explorer, if a page attempts to load a control that indicates that it is not SafeForInitialization and SafeForScripting, the user will be shown an Information Bar.

An Information Bar is shown if SiteLock denies hosting of the control.

This information bar does not offer the user the option to override, as controls which have indicated that they are not safe to be loaded should never load in the browser.

The use of SiteLock is also responsible for restriction #3, and this is something that developers should be aware of. Web developers cannot instantiate any SiteLocked control via new ActiveXObject(); or equivalent methods because the JavaScript engine itself doesn’t know the security context and cannot provide it to the control. You must create an object tag and place it within your page’s markup in order for the SiteLock code to properly evaluate the security context and permit the control to be instantiated.

Restriction #4 isn’t a part of SiteLock itself, but is an attack-surface reduction technique which is useful for reducing attack-surface against ClickJacking or other UI-spoofing attacks. However, it appears that the CertEnroll team will be removing this restriction in an update.

Have a great weekend!

-Eric