Summary of the new feature / enhancement

[Updated based on feedback below]

Azure has a new Trusted Signing service in public preview. One of the features is rotation of the signing cert. This breaks how PowerShell currently validates signed scripts.

PowerShell only trusts the leaf cert in the chain and this cert will be rotated (by Azure or any other cert service). So a customer may initially sign a script and it works, but then after the cert is rotated new scripts won't work since the leaf cert has changed and old certs might have expired so old scripts also stop working in an execution policy that requires signing.

Proposed technical implementation details (optional)

Azure Trust Signing customer signing cert has a customer unique EKU. We would allow storing additional signing metadata in the registry:

• HKLM\Software\Microsoft\PowerShellCore\TrustedEnterpriseEKU as a string array representing the customer unique EKUs
  • example: 1.3.6.1.4.1.311.97.990309390.766961637.194916062.941502583
  • it will be up to users to properly put here a unique identifying EKU they trust
• This property is, by default, protected to be read-only except for LocalSystem and Admins

Existing AllSigned and RemoteSigned execution policies will respect the EKU if it has been stored in the registry (this is how the customer opts into this change in behavior):

• perform standard Authenticode validation (like Get-Authenticode), if valid then:
  • verify that the leaf cert contains the TrustedEnterpriseEKU as stored in the registry

This would allow for alternate signing services to also participate and work with PowerShell.

Cert revocation will continued to be handled by WinTrust and no change for PowerShell.