Trusted Publisher Checks for Azure Trusted Signing#25824
Trusted Publisher Checks for Azure Trusted Signing#25824jborean93 wants to merge 4 commits intoPowerShell:masterfrom
Conversation
Add support for checking the Azure Trusted Signing publisher identifier alongside the thumbprint. This check will verify whether the unique Azure TS OID present in the EKU is in any certificate in the TrustedPublishers store. It will also check whether the OID is present in the untrusted store making it possible to distrust all certificates for that Azure identity.
|
This looks really good. |
There was a problem hiding this comment.
Pull Request Overview
This PR adds support for trusted publisher checks when using Azure Trusted Signing certificates in PowerShell's execution policy validation. The implementation allows PowerShell to trust Azure Trusted Signing certificates based on their unique publisher identifier (extracted from EKU OIDs) rather than only by certificate thumbprint.
- Introduces Azure Trusted Signing publisher identifier checking alongside existing thumbprint validation
- Adds comprehensive test coverage for the new trusted publisher functionality
- Enhances security by validating certificates against both trusted and disallowed certificate stores
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
SecurityManager.cs |
Implements Azure Trusted Signing publisher ID extraction and validation logic in certificate trust checking |
ExecutionPolicy.Tests.ps1 |
Adds comprehensive test suite covering various Azure Trusted Signing certificate trust scenarios |
| azurePublisherId == trustedIdentifier) | ||
| { | ||
| isTrusted = true; | ||
| break; |
There was a problem hiding this comment.
The break statement exits the loop early when an Azure publisher ID match is found, but the thumbprint check continues through all certificates. For consistency and performance, consider adding a break after setting isTrusted = true for the thumbprint match as well.
test/powershell/Modules/Microsoft.PowerShell.Security/ExecutionPolicy.Tests.ps1
Show resolved
Hide resolved
SteveL-MSFT
left a comment
There was a problem hiding this comment.
Since this is coming in late for 7.6, can you make this an Experimental Feature?
Co-authored-by: Copilot <[email protected]>
|
@SteveL-MSFT can do. Do you see any problems with this method or do you prefer the registry route mentioned in the issue? Any concerns about the EKU + thumbprint method for the unique identifier and whether the root or immediate issuer should be used? |
Was discussed in Security-WG, seems fine to us. Thanks! |
|
|
||
| // Do a final check to verify that the certificate has not been | ||
| // explicitly added to the "Disallowed" store. | ||
| if (isTrusted && !IsUntrustedPublisher(signerCertificate)) |
There was a problem hiding this comment.
I'd expect IsUntrustedPublisher() on top of the method - it makes no sense to check trust if certificate is blocked.
Also it would be nice to add the check in trace too.
|
This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days. |
PR Summary
Add support for checking the Azure Trusted Signing publisher identifier alongside the thumbprint. This check will verify whether the unique Azure TS OID present in the EKU is in any certificate in the TrustedPublishers store. It will also check whether the OID is present in the untrusted store making it possible to distrust all certificates for that Azure identity.
PR Context
Fixes: #21550
I need to spend some time to figure out how I could potentially add tests for this. It should be theoretically possible to generate certs with the same ID or at least have some test hook that changes what ID to check for but I'll think about it.The behaviour of the untrusted check might need to be adjusted to only check the thumbprint only. Currently if any cert with the Azure identity OID is present in the untrusted store then all certs with that same OID will be untrusted. If the PowerShell team only wants to reject specific certs then that logic will have to be adjusted.Edit: Tests added and untrusted check moved back to only untrusting by thumbprint. It is not easy to get the root CA thumbprint for an untrusted cert because Windows treats it as rejected and won't work with the
X509Chainclass. Upon reflection I think this behaviour is nicer as it allows you to reject specific timeframes/certs rather than the whole identity at once. Maybe an extra location could be used to reject identities entirely if desired.PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright header