Hi, I know a standalone CA ignores the certificate templates as is standard for the enterprise authority... but how do you go around configuring it so it only Issue / display WebServer and Server Authentication certs via the certsrv? Delete them from the registry?? (http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/1c7126de-e212-47c9-a0c1-217f10720d48) Basically we want a CA with only a few "templates" a user can pick from... but we don't want to link it to the client secure domain hence the standalone approach. I've never used the Microsoft Policy Web Enrollment - is this a better way of doing it? I suppose we could deploy it building a "custom" domain, then editing the templates to require details and not get them from AD ...just seems like this is a "work around" not a solution. Cheers for the advice (as inane as the question is :) )

Because a standalone CA never uses certificate templates the web enrollment pages are not referencing any templates but rather uses a list of OIDs to be used in the enhanced key usage when requesting the certificate. The OID list is static in the file certrqma.asp and is not related to any templates. Although you can restrict the OID list, you still need to remeber that if the user manages to generate and send an arbitary request including the missing OIDs then the CA is not going to be able to block that. At the bottom line you really need to consider either using an enterprise CA or enforce application policy restriction on the CA certificate itself. /Hasain

As ever Hasain thank you for your great response... So a few followup Q's as my background isn't Microsoft CA (bet you never would have guessed that lol!) - To restrict the MS CA to use only specific OIDs reading Brian K's book this is via [EnhancedKeyUsageExtension] unless I misunderstood the chapter correct? is there a URL / reference where I can look up the list of Certificate OIDs? Excerpt from Brian Ks book: [EnhancedKeyUsageExtension] OID = 1.3.6.1.5.5.7.3.2 ; Client Authentication OID = 1.3.6.1.5.5.7.3.1 ; Server Authentication Second Question - so based on what you said even if I restrict through this method theres still a potential a user could (if generated correctly) submit a certificate type not specified ? - If I build it via enterprise and make the user submit details in the application and not build it from AD (remembering we are not using the actual live secure domain here) and only publish the two or three templates I want can the user in theory still get a certificate type I didnt want them to??? Final Question - Day 2 we need to add 1.3.6.1.5.5.7.3.4 ; Secure Email can this be added later via a certutil command ? I assume not as the CA certificate is bound to the restrictions when its created using the [EnhancedKeyUsageExtension] method so we couldnt add it in later like we could if we used Enterprise CA and Publishing Templates. OIDs still cause me the most amount of hassle :) so thanks for the assist Thank you most kindly :)

Q1: Yes, Using the EnhancedKeyUsageExtension section in capolicy.inf is the correct method to set the policy/extension on the CA certificate level. You can find the Microsoft specific OIDs her http://support.microsoft.com/kb/287547 but for other OIDs you either need to look at specific RFCs or find the OID in a OID repository like the http://www.oid-info.com/cgi-bin/display Q2: You can not override the restriction if it is set in the CA certificate (using the capolicy.inf method..) or if they are defined by the certificate template when using an enterprise CA. In such case you can only override all other non restricted attributes in the certificate request. If you for example allow for an arbitrary subject name and the CA allows the Client Authentication extension and malicious user can submit a request for the domain admin etc.. Q3: Remember that when using the EnhancedKeyUsageExtension section in the capolicy.inf, you need to renew or reissue the CA each time you add/remove/change the allowed OIDs. There is not certutil command that could allow you to do that. Using an enterprise CA and certificate templates gives you a more flexible control in terms of allowed extensions based on the template information rather than being set directly on the CA certificate. /Hasain