Using web Enrollment for webid URI names in certs

Not everyone can afford the enterprise edition of the Windows Operating System. Furthermore, not all use cases involve enrolling a million users, featuring auto rollover of certificate every 6 weeks or careful use of crypto modules that address the risks to private keys. Some folks just want to enroll using a web browser so they can play with technology; and play along with some actual systems as they learn about crypto and key management. Perhaps, folks might study NSA guidance on how certs relate to DoD office systems.

For webid purposes, one may also wish to use the web site enrollment feature of the Active Directory CA – a user interface onto the ADCS whose view is stripped down to a rather bald website. To make this site work for webid, we need to tune the deployment a little.




The text quoted above introduces the notion of specifying at the cert enrollment website form a “request attribute”; one that enables the user to specify the email SAN value to be added to the cert’s alternative name extension for the subject. Then, it shows how in a 2003-era CA (and later) one can go further with attributed requests, now specifying the URI and the other name forms of SAN (including one’s own definition of other-name).

In the limit, there are the following SAN extensions, including a custom name-form ({asn}Base64String)


To configure web enrollment for SANs:-

certutil –setreg policy\EditFlags +0x40000

Given this advice, I added the cert enrollment website to my (otherwise enterprise class) ADCS installation and duly commanded “certutil –setreg policy\EditFlags +0x40000”.


RESTART the certificate service!

Then, I used the web browser, adding “SAN:url= as a request attribute




We then see the CA administrator’s view, having received the user’s request to make a cert with a webid URI:-


Once issued, we see a view of the certificate view bearing the SAN URI (along with the status of the system as evaluated by the workstation opening the cert object):-


Back at the browser, post issuance, we download the cert to provision the browser.


And finally, we update the blogger page with the public key modulus and we also post the base64 of the cert (chain) into the same page (for experimental use by validation agents using certs). We obtain the modulus from the certificate viewer’s publicKey field (omitting the leading 00 byte, if present.


One advantage to using the certificate over the webid graph is that it contains an additional URI, usable by revocation management (assuming that the domain name ( has been made visible to the evaluator of the cert, embedded in a web page). obviously, the advantage of using the webid graph, over the certificate, is that others can be publishing similar URIs and the better graph-centric system will mashup the data sources.



About home_pw

Computer Programmer who often does network administration with focus on security servers. Sometimes plays at slot machine programming.
This entry was posted in webid. Bookmark the permalink.

Leave a Reply

Please log in using one of these methods to post your comment: 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