Open mcraig88 opened 10 years ago
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.
You could use a wildcard certificate while still using the -eq
operator in PowerShell. The * character would just be part of the certificate's subject.
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.