Today went through many Mediathat some apps and components in the recently released Windows 11 no longer work since 01.11.2021 and that the cause for this is a certificate that expired on 31.10.2021. In the meantime Microsoft has pointed out in a blogpost and also a patch for some affected components published.
Unfortunately, none of the available sources provided detailed information about what exactly the problem was. So let's get to the bottom of it ourselves.
Symptoms
The error manifests itself in the fact that in the case of Snipping Tool, when you click on "New" (to create a screen snapshot), the following error message appears:
A problem with Windows prevents you from opening "screen clippings". Refreshing the PC may fix this problem.
Exactly the same thing happens when using the "new" Snip & Sketch application, which is supposed to inherit the Snipping Tool.
The same applies to the "Getting Started" app...
Cause
If you trace back the system library called by the apps and look at the signature of the package, you will notice that its signature certificate expired on 10/31/2021, but a Countersignature (English Timestamp, according to RFC 3161) is present.
A countersignature is actually intended to precisely prevent code signatures from being classified as invalid after the signature certificate has expired. Why didn't that work in this case?
If you take a closer look at the properties of the code signing certificate, you will see that it is based on the "lifetime signing" principle. Extended Key Usage with object identifier 1.3.6.1.4.1.311.10.3.13.
This extended key usage - if it is present in a code signing certificate - causes exactly the observed behavior: Despite countersignature, the signed code is no longer recognized as valid when the certificate expires.
Limits the validity period of a signature to the validity period of the certificate. This restriction is typically used with the XCN_OID_PKIX_KP_CODE_SIGNING OID value to indicate that new time stamp semantics should be used.
Microsoft, IX509ExtensionEnhancedKeyUsage interface (certenroll.h)
Solution
The solution is therefore - as Microsoft is now implementing - to distribute a new package that has been re-signed with a code signing certificate that is still valid.
From an organizational point of view, the question arises as to whether the system library in question was signed with the correct certificate. After all, it usually makes sense to include the lifetime signing EKU in a certificate in order to explicitly make the code expire after the certificate expires. Presumably, the wrong signing certificate was used here.
The incident shows once again how important it is to have one's own PKI and, in this case in particular, code signing processes under control, and that gross errors can happen even to the best of the best.
But why...?
One might be tempted to question the point of a Lifetime Signing Extended Key Usage. Why not just omit the countersignature if you want the code to expire along with the signing certificate.
In fact, there is a reason to use a countersignature anyway: The possibility of Certificate revocation. The revocation of a certificate can be done with the following reason codes:
| Code | Designation | Description |
|---|---|---|
| 0 | Unspecified | This is the default setting and indicates that there is no specific reason for the revocation. |
| 1 | Key Compromise | The private key of a certificate was stolen or otherwise known to unauthorized third parties. |
| 2 | CA Compromise | The private key of the certification authority was stolen or otherwise known to unauthorized third parties. |
| 3 | Affiliation Changed | If the content of the certificate (e.g. the name of the user) has changed, a new certificate must be issued. |
| 4 | Superseded | The revoked certificate was replaced with a new certificate. |
| 5 | Cessation of Operation | The operation of the service belonging to the certificate was discontinued, for example, because there is a new service under a different name. |
| 6 | Certificate Hold | The certificate is revoked temporarily. This revocation type is the only one where the revocation can be subsequently undone. |
| 8 | Remove from CRL | If a certificate was revoked with reason "Certificate Hold" and delta revocation lists are used, the revoked certificate is kept in the delta revocation list with this code until the entry in the main revocation list is removed. |
| -1 | Unrevoke | If a certificate has been revoked with reason "Certificate Hold", this code can be used to unblock it via command line. Likewise, in the auditEvent 4870 the undoing of a certificate revocation is marked with this code. |
When a code signing certificate is revoked, the trust status of the signed code is determined by whether a countersignature exists and the reason for revoking the certificate:
| Countersignature available | Lock reason code | Impact |
|---|---|---|
| no | all | Any signature performed with the certificate is considered invalid, regardless of when the signature was performed. |
| yes | Unspecified Cease of Operation Affiliation Changed Superseded Certificate Hold | Signatures that from the lock date have been performed are considered invalid. Signatures that before the lock date were carried out are still considered valid. |
| yes | Key Compromise CA Compromise | Any signature performed with the certificate is considered invalid, regardless of when the signature was performed. |
English 
Deutsch