This is an intriguing solution to ad-hoc credentials encryption for automation.
However, I downloaded the script and attempted to execute it as written. Unfortunately, in its current form the script does not work.
First, it appears to require being run from a machine that is domain joined. I don't see any reason why this is necessary. For starters, since there is no requirement to be on a domain joined machine to generate a self-signed certificate, there should be no reason to force such a requirement. It is certainly possible to make the script adapt to use Active Directory if on a domain joined machine, but this should be dynamic not a static requirement.
Next, it the method used to capture credentials. Why not simply use Get-Credential? This is already built in for all supported version of Windows, so it is relatively native.
Even on a domain joined system, the script itself does not work, and based on what I see here, is overly complex for the steps necessary to acheive the goal
1. generate self-signed cert (
New-SelfSignedCertificate -Type Custom -Subject "CN=Whomever" -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2","2.5.29.17={text}upn=whomever@email.com") -KeyExportPolicy NonExportable -KeyUsage DigitalSignature,KeyEncipherment -KeyAlgorithm RSA -KeyLength 2048 -CertStoreLocation "Cert:\CurrentUser\My"
)
The cert should NOT be allowed to be exported and be limited to the machine where it was created. If portability is required, then use ADCS to generate a real cert for this purpose to at least have the ability to revoke the certificate should the encrypted information end up in the wrong hands
2. encrypt/decrypt credentials using generated self-signed certificate
3. delete self-signed cert AND the private key which renders anything encrypted with said cert completely useless
#Remove Self-singed cert and private key
$curUser = $env:USERNAME
$ssCert = get-childitem Cert:\CurrentUser\my|Where-Object {$_.Subject -eq 'CN=CJ Ramseyer'}
$certPrivKey = certutil -store -user my $ssCert.SerialNumber|findstr "unique container name"
$splitPrivKey = $certPrivKey -split ':'
$r = "C:\Users\$curUser\AppData\Roaming\Microsoft\Crypto\Keys\" + $splitPrivKey[1].trim()
Remove-Item Cert:\CurrentUser\my\$($sscert.thumbprint) -Force
remove-item $r -Force
This removes the certificate itself along with the private key completely rendering any encrypted data useless, therefore increasing security greatly.
Lastly, there should not be any support to using a remote filesystem. Allowing the cert and private key to be exported along with the encrypted credentials then becomes a huge security risk. If, for example, AD Enterprise Admin credentials are what has been encrypted and the encryption key plus the credentials are allow to be taking from the system where this was generated, anyone getting ahold of this would gain the 'keys to the kingdom'. By preventing the cert from being exported, AND not supporting storing the encrypted credentials beyond the local system, security is enhanced.
It should be mentioned that this entire solution should also probably not be a single monolithic script, but built as a module
Microsoft
