May 9, 2016 at 4:52 am #38742
I've been digging into what it takes to make my script profile more tamper proof on my personal workstation(s) and have started using a code signing self-signed certificate to sign my scripts. I then set the execution policy to AllSigned and ensure that my profile script and any modules it calls are digitally signed with this certificate.
To automate this entire process I've put together a script to generate the code signing certificate and then do the following:
– Export it to disk as a password protected PFX file
– Export into memory as a cer file (public key only).
– Delete from the Cert:\CurrentUser\My certificate store
– Re-Import just the public key into the Cert:\CurrentUser\TrustedPublisher store
– Copy the certificate from Cert:\CurrentUser\TrustedPublisher to the Cert:\CurrentUser\Root
The script is found here if anyone cares to tear it apart (run with the -Secure flag to create the scenario described above): https://github.com/zloeber/PowerShellProfile/blob/master/Scripts/New-CodeSigningCertificate.ps1
My question is, am I missing anything from a security point of view? Every example I've seen with makcert.exe goes through a process of creating a trusted root authority and then using it to create the code signing certificate. I've bypassed this two-tier approach entirely and it seems to work well enough for me.
May 9, 2016 at 5:01 am #38744
A self-signed certificate is, by definition, also a root certificate. As long as it's present in your trusted root certificate authorities store (either for machine or user), so the OS trusts it, then you should be fine.
For your own personal use, there's probably no difference one way or another. Using a separate root certificate would simplify matters if you wanted to issue multiple certificates and/or deploy this trusted cert to multiple computers.
May 9, 2016 at 5:01 am #38745
If the self-signed cert lives on your local machine, and your goal is to prevent something (malware?) from tampering with your scripts, the malware could simply tamper and then re-sign the scripts, no?
Like, I'd say that the default is "there is no security advantage whatsoever," and then ask what security advantage you are attempting to create.
May 9, 2016 at 5:02 am #38746
"If the self-signed cert lives on your local machine, and your goal is to prevent something (malware?) from tampering with your scripts, the malware could simply tamper and then re-sign the scripts, no?"
The way I read it, he needs to enter a password each time he wants to sign a new script, so that part's probably okay.
May 9, 2016 at 5:04 am #38747
Gotcha. Missed that.
I'm still generally an un-fan of self-signed certs. They miss most of the advantages of using certs. However, it looks in this case like you're solely after the integrity bit, and only locally, and if it's password-protected, then you should be reasonably good on the integrity bit.
May 9, 2016 at 7:08 am #38769
So possibly the directions I've found that describe creating a multiple tier self-signed certificate configuration were purely written around some makcert.exe limitations and not a security concern?
You must be logged in to reply to this topic.