Trusted Publisher Checks for Azure Trusted Signing #25824
+417
−16
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
X509Chain
class. 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
,.ps1
and.psm1
files have the correct copyright header