UEFI shim verification against microsoft-uefica-public.pem fails with 20131003 saucy images

Raring & 12.04.2 images are also affected, haven't checked quantal but I presume it's affected as well.

$ sbverify --cert microsoft-uefica-public.pem /mnt/EFI/BOOT/BOOTx64.EFI
warning: data remaining[1230256 vs 1355656]: gaps between PE/COFF sections?
PKCS7 verification failed
139756278539968:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:pk7_smime.c:342:Verify error:certificate has expired
Signature verification failed

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            33:00:00:00:08:1e:b1:7e:9c:15:fc:83:7a:00:01:00:00:00:08
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011
        Validity
            Not Before: Jul 2 22:25:14 2012 GMT
            Not After : Oct 2 22:25:14 2013 GMT
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, OU=MOPR, CN=Microsoft Windows UEFI Driver Publisher
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:e9:22:4f:b6:d3:3b:3c:16:1b:48:41:e4:9e:ee:
                    ed:19:cb:7b:fe:03:a6:bd:6b:f1:eb:28:7d:d6:c2:
                    89:1b:10:a5:bf:b3:99:7d:4c:bf:38:23:e7:62:36:
                    39:3d:d8:54:d7:84:24:d3:ea:e2:53:c5:5b:e3:3e:
                    26:a8:8c:01:c6:99:e0:ed:ab:ad:e1:31:d1:b5:a2:
                    1a:02:57:32:a8:52:3c:b4:93:a7:87:7b:b5:f8:b2:
                    fc:f4:4b:9e:c6:d7:87:6d:2b:be:36:1a:13:36:88:
                    8c:3d:cb:d1:5e:74:f6:71:7c:6e:0f:8c:2f:7e:cb:
                    f8:8d:a5:d5:e7:b3:31:f0:3f:2b:31:36:d6:1d:fe:
                    a3:e4:13:50:00:d1:ce:ea:3e:09:b5:fe:dc:30:b4:
                    1f:79:77:e5:02:83:2c:9f:c0:70:07:63:e7:e6:8c:
                    43:81:0b:91:c9:73:63:d9:45:b9:84:5a:07:ae:bd:
                    ee:6d:c4:56:74:2e:11:87:73:25:cf:95:e5:6d:25:
                    fb:6e:bf:a3:71:f1:55:69:1b:30:bd:e7:d2:1d:b1:
                    e4:01:6e:e3:6d:2f:20:87:e2:da:80:00:67:ec:58:
                    4a:07:09:57:0d:82:4f:82:3a:17:80:15:06:a7:7c:
                    62:1b:8b:e6:22:d7:a0:a6:57:e6:1f:8e:90:20:2f:
                    36:e7
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Extended Key Usage:
                Code Signing, 1.3.6.1.4.1.311.80.2.1
            X509v3 Subject Key Identifier:
                C0:4C:FC:78:2F:95:15:DD:D5:65:5D:BA:FF:32:97:39:6A:93:52:A6
            X509v3 Authority Key Identifier:
                keyid:13:AD:BF:43:09:BD:82:70:9C:8C:D5:4F:31:6E:D5:22:98:8A:1B:D4

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://www.microsoft.com/pkiops/crl/MicCorUEFCA2011_2011-06-27.crl

            Authority Information Access:
                CA Issuers - URI:http://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt

            X509v3 Basic Constraints: critical
                CA:FALSE
    Signature Algorithm: sha256WithRSAEncryption
         84:08:31:43:9e:4e:63:e8:8d:00:e1:b0:c0:67:8d:70:bb:89:
         f4:66:e9:02:7a:b2:81:77:92:6d:5d:ef:81:75:b3:24:0e:72:
         9f:94:3f:1e:6b:d9:4a:0f:27:c9:2e:69:6a:50:01:c0:74:7f:
         6b:f7:57:4c:09:e8:48:5a:5e:b6:d7:02:42:44:dd:d7:32:36:
         c2:8e:9d:fa:d5:8e:c5:09:8b:74:51:62:34:23:25:52:d9:23:
         0c:1d:0d:da:e7:31:08:b0:a0:14:4b:d9:e9:26:5d:ac:56:eb:
         dc:ce:75:12:cf:36:27:a6:85:8d:41:87:6e:de:19:d3:5e:0e:
         27:95:7a:68:96:aa:e9:ea:15:00:98:32:74:50:fe:7c:72:38:
         5a:a...

Above produced with:
$ sbattach --detach signature /mnt/EFI/BOOT/BOOTx64.EFI
$ openssl pkcs7 -inform DER -in signature -text -print_certs

I believe this is a bug in sbsigntool, not in the shim data. The expired signature is not in the path to the CA, my understanding is that this is present only as part of the timestamping service.

Both shim and TianoCore include the following code:

static int check_cert_time(X509_STORE_CTX *ctx, X509 *x)
        {
#if defined(OPENSSL_SYS_UEFI)
  /* Bypass Certificate Time Checking for UEFI version. */
  return 1;
#else
      [...]
#endif
        }

So effectively, we don't do verification of signature times in UEFI. So this is a bug in sbsigntool.

This bug was fixed in the package sbsigntool - 0.6-0ubuntu5

---------------
sbsigntool (0.6-0ubuntu5) saucy; urgency=low

  * debian/patches/ignore-certificate-expiries.patch: ignore certificate
    expiries when verifying signatures. Closes LP: #1234649.
 -- Steve Langasek <email address hidden> Fri, 04 Oct 2013 01:43:03 +0000

as commented on IRC, I don't believe an SRU is warranted for only this bug. It's not user-affecting, sbverify is only used in our test environment; and having confirmed that sbverify is buggy, that can be worked around by e.g. using faketime. We probably want that as an interim solution *anyway*, because any SRU of sbsigntool is going to be blocked by the one already in progress, needed to fix other issues that would block building of the shim-signed package.

This has popped up again in Precise given that we need to do builds of shim-signed for Secure Boot validation. I'm uploading the package to the precise queue now.

Hello Para, or anyone else affected,

Accepted sbsigntool into precise-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/sbsigntool/0.6-0ubuntu4~12.04.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

This bug was fixed in the package sbsigntool - 0.6-0ubuntu4~12.04.2

---------------
sbsigntool (0.6-0ubuntu4~12.04.2) precise; urgency=medium

  * debian/patches/0001-Support-openssl-1.0.2b-and-above.patch: handle the
    case where we can't get the issuer certificate, which typically happens
    after 1.0.2b; but it appears that 1.0.1f includes that check too, which
    fails in sbsigntool. (LP: #1474541)
  * debian/patches/ignore-certificate-expiries.patch: ignore certificate
    expiries when verifying signatures. (LP: #1234649)

 -- Mathieu Trudel-Lapierre <email address hidden> Tue, 24 May 2016 14:41:24 -0400

The verification of the Stable Release Update for sbsigntool has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.