To issue certs (better known as identity credentials) for webid project purposes, the Microsoft CA needs a certain configuration. Let’s enumerate the issues and the setup:
- Install the Enterprise Edition of Microsoft Windows 2008 R2
- With all dependencies, install what will be the Enterprise edition of the Active Directory Certificate Service (ADCS)
- From the feature options, select only the first feature. Enrollment website, web service interface, and enrollment policy servers are not required for webid
- ADCS will require installing a Domain Controller and its group policy management system, delivered by Active Directory (AD). This provides the certificate issuing UI and security system.
- AD will normally install an local DNS server, delivered by Active Directory. The DNS zones are X.500 namespaces within the data partition, and are multi-mastered with replication. Do not bother with DNSsec features or IPv6
- ADCS will install Active Directory of course, into which certificates and CRLs and other cert-related policy objects are published on ldap scheme URIs.
- You do not have to install the certificate enrollment website feature of ADCS, or therefore its IIS dependency
- Configuring the IIS7.5 role and its default website is worth installing anyways, even without the cert enrollment website. It can host the webid website showcasing the webid validation agent
Using the infamous mmc management console, install the Certificates, Certificate Authority, and Certificate Template plugins. It’s the template feature that allows us to get professional, and handle a million users over a multi-year project.
To make the User RDF template, duplicate the User template. Then, remember the gotcha that said duplication makes a version 3 template. As with any template using the version 3 feature of NSA’;s next generation cryptography profile, it is not usable in the old certificate enrollment website; and this is why we didn’t install it.
Here is how I configure my template (known for no particular reason as User RDF)
In that policy template design, you see that I do not store the certificate in the active Directory (since that’s not the way webid thinks about its world). I also do not store them in the certificate repository/database on the CA.
Concerning key usage, the certificates are enabled for making signatures (on SSL CertVerify messages) and the crypto controls over the use of RSA limit the key only to the purposes of engaging in key exchange for keys – consistent with webid and its exploration of SSL handshakes in the semantic web variant of the hypermedia concept.
In request handling, one notes that the enrolling users will be prompted (meaning group policy tools used by enrolling users will deliver UI allowing most cert fields to be specified by the user). In the security field, note the ACLs include Everyone group, and said group has the enroll privilege (and auto-enroll). This enables anyone with an account on WinNT to be self-enroll, assuming they have access to group policy tools on their workstation.
Of particular relevance to webid is the subject name tab:
Here, one must enable the request message to supply the users self-determine name – i.e. the webid URI. Note that EVEN THOUGH we will be subsequently using the Active Directory enrollment policy, we have just removed most of what that policy entails. Now, the policy is merely a useful bootstrap, and no longer imposes an enterprise-centric management culture on issuing certs. The Enterprise CA from Microsoft is now just a great, and best of class standalone CA, with full enterprise-management features. Don’t be tempted to install the standalone CA, or use the standard edition of a Microsoft Windows operating system prior to the 2008 R2 version.
Moving onto the CA itself, lets configure its properties, starting with the policy module. At the CA level, not the template level, I make the CA administrator responsible for the final decision to issue a certificate, essentially disabling auto-enrollment.
Concerning the exit modules publication of certs, we deny publication of certs to the file system (by the CA), enacting the webid rule that certs are controlled by the browser, once the user has control. This control is rather weak, even in rationale. But, you get the point for webid purposes – that the system is biased towards the user.
We then enable everyone to request certificate, but not everyone can perform certificate administration (issuing certificate given a pending certificate request). Note, that you do not have to be, currently, an AuthenticatedUser (in the ActiveDirectory/Domain Controller sense).
Concerning preparation for revocation and compromise recovery, we go beyond the remit of the webid world. We did not (perhaps recall) include pointers to revocation lists in our certs. We will however publish them on http endpoints (in the case that one later installs the certificate enrollment website in IIS in order to handle a major compromise.).
note, we also prepare the ground for, but do not yet execute the policy goal of, using http for delivering online statement about certificate status, in the eyes of the issuing system.
Finally, we setup a liberal enrollment agent policy, allowing everyone to actFor everyone else, for webid purposes, only. The idea is that mom can enroll her kids, etc.
One puts all the pieces together finally, using the particular CA’s template “add” template action:
which obviously adds the userRDF template to the list supported by this CA, as show in the following panel:
To act as a user and get a certificate, go to ones Persona certificate store, in the certificate plugin to the management console. Use the advanced operation task, and create a customer request (or since we set the UI to prompt anyways, just request a certificate).
Now lets go through the request wizard
Do use the active Directory enrollment policy (even though its been tune earlier to be a standalone control regime)
Select the UserRDF template of those offered, and note the blue prompt
Starting with the friendly name. Use the WebID URI.
For the private key, allow those crypto provider you trust, including any you install yourself using high assurance crypto boxes (like by Luna CA ether servers). Choose these according to volume requirements. A luna box can mint 500 signatures (i.e. SSL handshakes) a second… Make the resulting private key (of the user) as exportable, given the limits imposed by the users crypto provider.
Concerning the extensions one needs for webid validation protocol (a semantically-enhanced https), note the key usage and extened key controls. Independently, application policy statement will be added, to suit higher end Windows controls that go beyond PKIX profile for cert handling (see IETF docs).
On the matter of the subject name, note how I populated the URI alternative name (replace webid with a URI…) and was considering also placing the same URI in the more traditional common name field of the certificate subject field.
Having finally submitted the cert request, go ask the manager of the system to handle the pending request, and mint cert for you. He or she can email you a .p12 file usable in many browsers.