A question about Auto-Enrolment

Can someone please help me with the following question, thanks

I was reading the following article

https://technet.microsoft.com/en-us/library/cc778245(v=ws.10).aspx

At first glance it seemed to contradict itself (I think I know the answer but want to check hence my post)

The article says

  • On the Issuance Requirements tab of the selected certificate template, selecting This number of authorized signatures and making the value greater than 1 disables subject autoenrollment based on this template.
  • On the Issuance Requirements tab of the selected certificate template, selecting This number of authorized signatures and setting the value to 1 requires the requester to sign the request with a private key from a valid certificate in their certificate store. This certificate must contain the application and issuance policies that are specified in the Application policy and Issuance policies lists on the same tab. If an appropriate certificate exists in the requester's certificate store, autoenrollment signs the request with this certificate's private key and obtains and installs the requested certificate automatically.

So when it comes to The number of Authorised Signatures the first bullet point states this disable auto-enrolment but the second bullet point says obtains and installs the requested certificate automatically

What I believe it is saying is if you have a code signing certificate with the appropriate Application Policies (EKU) and Issuance Policies in this code signing Cert (e.g. to match the requirements of the template). As long as this code signing cert is in your X509 store on your PC, you can auto-enrol and if it is not you have to get someone who has this code signing cert to sign you CSR

Is that basically correct?

If so what X509 store should this code signing cert be  in LocalMachine\Personal or CurrentUser\Personal or other?

Thanks All

Ernie


September 14th, 2015 2:12am

On Mon, 14 Sep 2015 06:08:58 +0000, BrantEH wrote:

Is that basically correct?

No. You need to go back and reread the article. There is no contradiction
between the two statements. It is actually very simple:

1. Requiring 0 or 1 signing certificate means autoenrollment is possible.
2. Requiring 2 or more signing certificates means autoenrollment is not
possible.

Also, there is no requirement to use a code signing certificate for

Free Windows Admin Tool Kit Click here and download it now
September 14th, 2015 3:39am

Hello Paul

Thanks very much for taking the time to reply, I will go back and re-read the article.

When is comes to "setting the value to 1 requires the requester to sign the request"

in order to 'sign' I believe this means sign the CSR. 

therefore I believe the person or entity doing the signing would need  a certificate that has the 'Key Usage" of Digital Signature (80)

Which a certificate with EKU of 'code signing' has

What other types of certificate (other than EKU of code signing) can be used to sign the CSR please?

Thanks again for your assistance

Ernie

 

 

September 14th, 2015 4:22am

As Paul said, there is no restriction in EKU to sign the request. In the Issuance Requirement tab you can specify any EKU listed in the drop-down box. Whatever you select, it will be required to sign requests for that particular template.

In practice, Certificate Request Agent EKU is used when "enroll on behalf of" is used. But any other EKU can be selected.

Free Windows Admin Tool Kit Click here and download it now
September 15th, 2015 1:21am

Hello Vadims

Thanks too for taking the time to reply, I will take a closer look at that tab and its options etc.

putting the EKU to one side a moment does the KU still require the 'digitalSignature' 

Basically I want to understand the nuts and bolts here

what I am thinking is (with present knowledge) at the end of the day it comes down to cryptographic primitives (algorithms) , so as far as I understand a signing operation would typically be hash the data then encrypt hash with private key, then append output to original data by way of a signature (e.g. data now signed) therefore for the CSR to be signed a cryptographic primitive needs to be available e.g. 'digitalSignature' and the purpose of the KU extension is to restrict use of a certificate  to the cryptographic primitives listed there.

Is that correct please? if not I would be grateful if you could expand on any gaps etc/

Thanks 
Ernie

September 15th, 2015 1:50am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics