xCertReq does not create req file from inf

[gammalost]

When running xCertReq, it throws an error after trying to create the .req file from the .inf file when it tries to use the .req file:

PowerShell DSC resource MSFT_xCertReq failed to execute Set-TargetResource functionality with error message: Certificate Request file 'C:\windows\TEMP\xCertReq-3a43205a-a1b6-40e6-a1c3-40a56
fc7c375.req' not found.
+ CategoryInfo : InvalidOperation: (:) [], CimException
+ FullyQualifiedErrorId : ProviderOperationExecutionFailure
+ PSComputerName : TB-Test1

I've tried to run certreq.exe manualy on the server with the "-q" option, with the same result. When running it without "-q" it gives a popup about not finding the template and "continue anyway" option, which in turn generates the required .req file.
Is this a known problem, or might there be some PEBCAK in the picture?

These are the parameters specified:
xCertReq RequestCertificate
{
Subject = "$($Node.NodeName)"
CAServerFQDN = 'TB-CA.thebachelorettes.local'
CARootName = 'thebachelorettes-TB-CA-ca'
KeyLength = '2048'
AutoRenew = $true
}

[PlagueHO]

Hi @gammalost - thank you for submitting this.

There are some current issues with xCertReq that have been fixed but not yet released. However, I don't think what you're seeing is caused by these.

I have a couple of questions:

1. Is your CA an Enterprise CA (e.g. AD Integrated) or Standalone CA? If your CA is a Standalone CA then it doesn't actually use Certificate templates - so xCertReq can't currently work with it. But if your CA is an Enterprise CA then this isn't the problem.
2. Is the WebServer certificate template on your CA enabled and issuable by the user account being used to run DSC (in your case, probably LocalSystem)? By default the DSC LCM runs as LocalSystem (from memory). This doesn't usually give it access to issue from an enterprise CA. So you usually need to use the PSDSCRunAsCredential to run the resource under a domain account that has access to issue using the WebServer template - you also need to check the WebServer template is even enabled.

If you could take a look at the above two items and let me know any other details based on my suggestions I can try and help further. Thank you!

[dcuomo]

@gammalost -
I seem to remember having a similar issue like this in the past. Could you try changing your subject param to something like:
Subject = "CN=$($Node.NodeName)"

[gammalost]

@PlagueHO

1. I'm trying to use this in conjunction with a server created using xAdcsDeployment as an Enterprise Root CA with Web Enrollment installed. The CA server is connected to a domain, but not the server I'm trying to request certificate from. In short I'm trying to request a certificate from a remote server not connected to the same domain as the CA.
2. As far as i can tell it should be enabled. I've tried to use the domain credentials for xCertReq, but it still results in the same error.

@dcuomo Thanks for input! Sadly this does not seem to fix it either.

The problem I'm having seems to be the creation of the .req file from the .inf. I can see the .inf gets created, but not the other one. As stated I can create the file when manually running certreq.exe without the -q option, but not with it. It might be a credential problem?

[gammalost]

When trying to do the same with a server connected to the same domain i get the same error as in issue 42. This seems to point more and more in the direction of access and credential as you pointed out @PlagueHO . Have this module been tested on requesting certificates from a CA in another domain?

[PlagueHO]

Hi @gammalost - ah - I haven't actually tried this issuing an enterprise cert from a machine not connected to the domain. Have you tried setting the PSDscRunAsCredential parameter (if you're using WMF5+) or the Credential parameter (if WMF4)? I actually suspect this won't work, because this effectively tries to force the certutil.exe commands to run under the context of this user - which probably isn't possible given that you're not in the domain.

I think I'll need to do some actual testing to replicate the issue. I should be able to build a non-domain joined server and try it out on my domain CA. I'll try and look at this in the weekend (this week is a bit of a shocker work wise).

[gammalost]

New and uncharted territory 😄 . I've tried setting PSDscRunAsCredential both as local and domain admin for the remote domain. This actually results in no .inf file at all, even with local admin credentials. The Credential parameter does not seem to matter (at least not at this point) as it still results in it failing when running the certreq -new part of the module. I am using a pure W2K16 environment if this is of interest to know.

Cool, looking forward to hear the results! Until then I'll continue testing.

[gammalost]

Hi @PlagueHO !
I've finally been able to request a certificate from a non-domain server through manual use of CertReq.

A prerequisite is having a IIS server somewhere as a frontend.

The problem with setting up a solution that is able to serve non-domain clients is that the two ADCS services Enrollment Web Service and Enrollment Policy Web Services needs to be installed.
These in turn creates their own site under the IIS Default Web Site which needs to be specified as parameters to CertReq.

To be able to use CertReq with this solution the following additional options needs to be specified in both CertReq -new and -submit:

• -UserName - Domain user
• -P - Password
• -PolicyServer - URL to Enrollment Policy Web Service (CEP)
• -Config - URL to Enrollment Web Service (CES)

This demand for such solution is possibly too small(?), but could possibly be worth adding in a later release of the module? 🙂

[gammalost]

Hi @PlagueHO .
I finally got around to implementing the functionality in your module. The only difference is that I've added two extra parameters for the CEP and CES URL, and added an if/else around CertReq -new and -submit for checking if the URLs and Credentials are passed.
If you're interested in checking out what have been done I can do a pull request.

[PlagueHO]

Hi @gammalost - sorry I missed your previous comment. This sounds like a really useful feature to me and would be great to have!

I do think though there would need to be a parameter added to specify that a Standalone CA is being used - the parameter would default to Enterprise CA if the machine is domain joined or Standalone if it wasn't.

If Enterprise CA is being used then use the existing process. if Standalone CA is being used then the following things would happen:

1. Parameters -UserName and -p would be passed to certreq.exe (would require the credential parameter to be provided)
2. Parameters -PolicyServer and -Config would be passed to certreq.exe (these would need to be set as parameters of the resource).
3. If in Standalone mode, the:

[RequestAttributes]
CertificateTemplate = $CertificateTemplate

would need to be removed from the .INF file because templates aren't applicable in standalone CA's.

Does this sound like it would work?

[PlagueHO]

Also, it might be worth updating xADCSDeployment to enable deploying Enrollment Web Service and Enrollment Policy Web Services. I've been meaning to add these but haven't had the time yet...

[gammalost]

AFAIK about CA's and requesting it looks sound. I'll implement the changes and make a pull request.

[gammalost]

One thing regarding the standalone/enterprise parameter. I don't think it should default to a value in the case of it being in a domain or not. This because both non-domain servers and servers in external domains can still request certificates from an enterprise CA (if the enrollment services is being used).
I'm more in favor of having this just defaulting to enterprise if the parameter is not specified.

The CA type parameter will in short terms only affect whether or not

[RequestAttributes]
CertificateTemplate = $CertificateTemplate

will be added to the inf file.

[PlagueHO]

@gammalost - cool - that sounds like a good idea to me. Just as long as the default is general Enterprise CA (to avoid a breaking change). Thanks for working on this!

[PlagueHO]

Hi @gammalost - I think this one can be closed now - is that correct?

[gammalost]

Yes 🙂