Add Password parameter, and change Test-TargetResource to match the Subj... #3
Conversation
…ubject name, instead of looking for equal to
|
Windows 2012 will use Import-PfxCertificate, Windows 2008 will use certutil. |
|
I don't think it's a good idea to have any kind of wildcard matching on a DSC resource's key property. Adding support for PFX passwords is a good idea, but using a [string] for this is not secure. Off the top of my head, I don't remember if we can just stick a [securestring] argument in there and have itwork, or if DSC will only encrypt PSCredential parameters for you (with corresponding MSFT_Credential objects in the MOF file.) Will test that soon. |
| Write-Verbose "Removing $CertificateLocation." | ||
| dir $CertificateLocation | Remove-Item -Force -Confirm:$false | ||
| Write-Verbose "Removing $name from $CertificateBaseLocation." | ||
| gci $CertificateBaseLocation | ?{$_.Subject -match $name.Replace('*','')} | Remove-Item -Force -Confirm:$false |
There was a problem hiding this comment.
This is to support matching a wildcard certificate, such as *.mysite.com.
Possibly a better method would be to match on a Thumbprint, instead of a certificate name. Thoughts?
|
You could use a wildcard certificate while still using the I do agree that using a thumbprint might have been a better choice. The question now would be whether we should make a breaking change on the resource now to change its API, or just leave it as-is. |
|
Ok, I'll see what I can do here. |
Add Password parameter, and change Test-TargetResource to match the Subject name, instead of looking for equal to.
This has been tested on Windows 2008R2 and 2012R2.