Bug 1411213 (expired-secure-boot-certs) - pesign-bundled Red Hat Test Certificate and CA expired in 2013
Summary: pesign-bundled Red Hat Test Certificate and CA expired in 2013
Keywords:
Status: CLOSED NOTABUG
Alias: expired-secure-boot-certs
Product: Fedora
Classification: Fedora
Component: pesign
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-09 06:35 UTC by David Ward
Modified: 2018-01-09 18:54 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-01-09 18:53:26 UTC
Type: Bug


Attachments (Terms of Use)

Description David Ward 2017-01-09 06:35:34 UTC
The test certificate and CA that are packaged and installed into an NSS database at /etc/pki/pesign-rh-test are expired. These certificates originate from an additional source file (certs.tar.xz) which is used when building the pesign package for Fedora.

Note that as a result, these expired certificates are currently being used when building unofficial kernel packages, including the Fedora kernel stabilization branch: https://copr.fedorainfracloud.org/coprs/jforbes/kernel-stabilization/


$ certutil -L -d /etc/pki/pesign-rh-test

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Red Hat Test CA                                              CT,C,C
Red Hat Test Certificate                                     u,u,u
$ certutil -L -d /etc/pki/pesign-rh-test -n "Red Hat Test CA"
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            00:f7:18:65:cc:12:02:b7:d3
        Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
        Issuer: "CN=Red Hat Test Certifying CA,O="Red Hat, Inc.",L=Cambridge,
            ST=Massachusetts,C=US"
        Validity:
            Not Before: Mon Jul 09 19:12:43 2012
            Not After : Tue Jul 09 19:12:43 2013
        Subject: "CN=Red Hat Test Certifying CA,O="Red Hat, Inc.",L=Cambridge
            ,ST=Massachusetts,C=US"
[...]
$ certutil -L -d /etc/pki/pesign-rh-test -n "Red Hat Test Certificate"
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            00:f7:d9:05:dc:fd:96:96:21
        Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
        Issuer: "CN=Red Hat Test Certifying CA,O="Red Hat, Inc.",L=Cambridge,
            ST=Massachusetts,C=US"
        Validity:
            Not Before: Mon Jul 09 19:12:44 2012
            Not After : Tue Jul 09 19:12:44 2013
        Subject: "CN=Red Hat Test Certificate,O="Red Hat, Inc.",L=Cambridge,S
            T=Massachusetts,C=US"
[...]

Comment 1 Fedora End Of Life 2017-02-28 10:54:29 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 2 David Ward 2017-05-08 04:36:26 UTC
The expired certificates have not been replaced in 'rawhide' (or Fedora 26).
Changing version back to 'rawhide'.

Comment 3 Jan Kurik 2017-08-15 08:16:53 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 4 David Ward 2017-12-21 04:15:39 UTC
The expired certificates have not been replaced in 'rawhide' (or Fedora 27).
Changing version back to 'rawhide'.

Comment 5 Peter Jones 2018-01-09 18:53:26 UTC
It doesn't make any difference that the certificate has expired - nothing in the Secure Boot verification chain can safely use the validation window like HTTPS does.  It's just a vestigial artifact of using CMS-like signing.

There's two big problems with using the validation window in this for something like SB:

One issue is that we don't have a trustworthy clock anyway.  If you're trying to do an attack against Secure Boot, you're basically trying to get persistence once you've already got root - either you're trying to install a "bootkit" or you're trying to use a vulnerable OS /as/ a "bootkit".  So an attacker has all the privilege they need to just change the system clock anyway.  

The other issue is that honoring the validation window means /hardware components expire/.  SB's verification is how option ROMs on PCI peripherals are verified, and they need to keep working after the certificate expires.  If anything honors the validation window, that means one day you reboot your machine and your HBAs and video cards simply do not work - your machine looks like it just bricked itself during a reboot.

So in a lot of ways having an expired certificate as the "test" cert is actually the best possible option, because it means we can find anything that's erroneously checking the window.


Note You need to log in before you can comment on or make changes to this bug.