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" [...]
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
The expired certificates have not been replaced in 'rawhide' (or Fedora 26). Changing version back to 'rawhide'.
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
The expired certificates have not been replaced in 'rawhide' (or Fedora 27). Changing version back to 'rawhide'.
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.