Build-WDACCertificate available parameters¶
Syntax¶
Build-WDACCertificate
[[-CommonName] <String>]
[[-FileName] <String>]
[[-BuildingMethod] <String>]
[[-Password] <SecureString>]
[-Force]
[-SkipVersionCheck]
[<CommonParameters>]
Description¶
This cmdlet constructs self-signed certificates that adhere to Microsoft's specifications for WDAC policy signing. With this cmdlet, you can dispense with Windows Server with a CA role to generate a certificate.
The generated certificates type is Code Signing, they employ SHA2-512 hashing algorithm with RSA 4096-bit encryption (the maximum supported key size for WDAC signing.)
Upon constructing a certificate, the cmdlet stores it in the Current User's personal store, then it exports that certificate in 2 files. One of the files has a .cer extension and encompasses only the public key, the other file has a .pfx extension and encompasses both public and private keys.
The PFX file is encrypted with SHA-256 encryption and safeguarded with the password supplied by the user. After the 2 files are exported, the cmdlet eliminates the certificate from Current Users personal store and then re-imports it using the PFX file, but this time it will store the private key using VSM (Virtual Secure Mode). In this method, the private keys are stored in the TPM and are highly secured with VBS (Virtualized-Based Security). The entire process happens in just few seconds.
Parameters¶
-CommonName¶
The common name of the certificate, it will also be assigned as the friendly name of the certificate.
Tip
If you enter a CommonName but do not enter a FileName, the FileName will be set to the same value as the CommonName for better user experience.
| Type: | String |
|---|---|
| Position: | Named |
| Default value: | Code Signing Certificate |
| Required: | False |
| Accept pipeline input: | False |
| Accept wildcard characters: | False |
-FileName¶
The name of the .cer and .pfx files that will be generated.
| Type: | String |
|---|---|
| Position: | Named |
| Default value: | Code Signing Certificate |
| Required: | False |
| Accept pipeline input: | False |
| Accept wildcard characters: | False |
-BuildingMethod¶
2 methods are used to build the certificates. Method 1 uses the Certreq and the Method 2 uses the New-SelfSignedCertificate.
| Type: | String |
|---|---|
| Position: | Named |
| Default value: | Method2 |
| Required: | False |
| Accept pipeline input: | False |
| Accept wildcard characters: | False |
-Password¶
The password to be employed to encrypt the .pfx file that encompasses the private and public keys of the certificate. It necessitates being in Secure String type. If it’s not supplied, the user will be prompted to input a password (and a second time to verify it). The minimum password length is 5 characters.
| Type: | SecureString |
|---|---|
| Position: | Named |
| Default value: | None |
| Required: | True |
| Accept pipeline input: | False |
| Accept wildcard characters: | False |
-Force¶
The cmdlet verifies whether there is any certificate with the identical common name as the certificate that is being created, on the system. If it detects one, it will prompt the user to for permission to remove them. If this parameter is employed, the prompt will be omitted as it will presume that the user acquiesced.
| Type: | SwitchParameter |
|---|---|
| Position: | Named |
| Default value: | None |
| Required: | False |
| Accept pipeline input: | False |
| Accept wildcard characters: | False |
Related Resources¶
- X500NameFlags enumeration
- Local Machine and Current User Certificate Stores
- Trusted Root Certification Authorities Certificate Store
- X509BasicConstraintsExtension Class
- Internet X.509 Public Key Infrastructure Certificate and CRL Profile - RFC2459
Additional Resources¶
To enhance the security and safeguarding of your certificate further, you can remove the certificate from the Personal store of the Current User certificates and then utilize the PFX file to import it anew in the same location, but this time you will mark additional boxes in the import wizard.
This video illustrates how to safeguard the Code Signing Certificate generated by the WDACConfig module, so that you will be compelled to either enter your security password or verify your identity every time the certificate is employed. By storing the certificate in this manner, only your user account will have access to it, and you will inherently possess administrator privileges to implement the signed WDAC policy on the system.
These options are only accessible in GUI and they are to deter automatic scripts from utilizing the certificates without authentication, this is why the Build-WDACCertificate cmdlet does not activate this security feature by default.
HSM (Hardware Security Module)¶
The most secure method of storing code signing certificates is to use a hardware security module (HSM) or a similar device. Furthermore, obtaining certificates from a regulated or publicly trusted certificate authority (CA) requires the use of an HSM. The HSMs must also comply with the Federal Information Processing Standards (FIPS).