Durable EKU checking for matching code signing certificates

TL;DR

• The problem: renewing an expired certificate often changes its subject line formatting, which silently breaks application updates
• Why Subject Matching fails: certificate authorities frequently alter required subject fields over time, even if your company details remain unchanged
• The solution: Advanced Installer 23.9 adds an "Expected Identity OID" check for Microsoft Trusted Signing users in the Updater settings
• How it works: The Updater checks Microsoft's static publisher identity OID instead, keeping update validation stable and secure across future renewals

Why is Subject Matching Not the Perfect Solution?

On paper, it makes sense to validate a certificate by using the Subject field because it is readable, contains the company name, and is the first thing that is noticed when a certificate is inspected.

The problem is that the Subject line is not something you can control, since it is determined by the certificate authority that issues the certificate, and CA requirements shift over time.

A field that was optional two years ago can become mandatory today, and vice versa. Trying to check only the CN or the O field helps, but it is a partial fix because it reduces the odds of an accidental mismatch, but it also weakens the security the check is meant to provide.

A company name isn’t unique in and of itself, nor is cryptographically difficult to reproduce.

What we actually want is a value that is tied to the certificate identity as a publisher, rather than formatting choices made by the CA issuer.

That is the idea behind Expected Identity OID, a new field available in the Advanced Installer Updater certificate validation settings that complements the existing Subject check.

If you inspect a certificate issued by Microsoft Artifact Signing, the Microsoft cloud code signing service, you will find an Enhanced Key Usage extension that includes two entries:

1. One is the standard Code Signing OID, 1.3.6.1.5.5 and so on, which carries every code signing certificate regardless of the issuer
2. The second one is an OID, such as 1.3.6.1.4.1.311 and so on. Every OID with the 1.3.6.1.4.1.311.97 prefix belongs to a namespace Microsoft uses specifically for identity verification in Trusted Signing

When Microsoft verifies a publisher identity for code signing, it assigns a policy OID that corresponds to that verified identity.

This is what makes it useful in this situation: when a certificate under this identity gets renewed, the OID remains the same because the underlying verified identity hasn’t changed.

The Subject line can shift all it wants, but this value doesn’t move.

However, it’s important to be precise about what this replaces and does not.

It is not a replacement for the standard Code Signing EKU check, and it is not the same as checking the Subject field. It is a third independent check that happens to be far more resistant to the type of drift that breaks renewals.

Another caveat is that it only applies to certificates issued through Microsoft Artifact Signing. That per-identity OID namespace is assigned only by Microsoft’s own service. Certificates from other authorities don’t carry an equivalent value.

Now that you have a general idea about the issue and how to fix it, let’s jump to Advanced Installer and navigate to the Updater page.

As shown above, a new field called Expected Identity OID is now available, and this is where you will enter the Enhanced Key Usage that we discussed.

With Expected Identity OID configured, the Updater checks for that specific policy OID in the new certificate's Enhanced Key Usage extension.

If it's present, the update package is trusted, regardless of what the Subject line appears. If it's missing or doesn't match, the update is rejected.

This turns certificate renewal from a Subject-line guessing game into a single, stable value you can set once and stop worrying about.

We also have a video describing and showcasing this new feature, which you can watch below:

Conclusion

Certificate renewal shouldn't be something you dread every year because it means re-testing your update pipeline against a Subject line that might have quietly changed shape.

Expected Identity OID gives publishers who use Microsoft Trusted Signing a way to validate updates against something that's directly tied to their verified identity, rather than formatting details that are out of their control.

If you're issuing certificates through Artifact Signing, it's worth setting this up now, before your next renewal forces the issue.

If you're on a different certificate authority, the Subject-based check is still your tool for the time being, so you can just keep it scoped and keep an eye out here in case that changes.

Have you had a chance to test durable EKU checking before your next certificate renewal?

Download Advanced Installer 23.9 to unlock new features and enhancements, including:

- Enhanced security with durable EKU checking
- CLI-driven SBOMs
- VMware 26H1 repackaging
- Updated 26H1 MSIX dependencies
- Seamless file and prerequisite customization

If you’re new to Advanced Installer, you can take a look at the feature list.