Bug 869665 - shim: Fedora Secure Boot CA certificate issues
shim: Fedora Secure Boot CA certificate issues
Product: Fedora
Classification: Fedora
Component: shim (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Matthew Garrett
Fedora Extras Quality Assurance
Depends On:
Blocks: 869613
  Show dependency treegraph
Reported: 2012-10-24 10:04 EDT by Florian Weimer
Modified: 2013-10-24 22:24 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-10-24 22:24:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Actual updated certificate. (803 bytes, application/octet-stream)
2012-10-30 13:22 EDT, Peter Jones
no flags Details

  None (edit)
Description Florian Weimer 2012-10-24 10:04:44 EDT
The certificate is a bit odd:

        Version: 3 (0x2)
        Serial Number: 2574709492 (0x9976f2f4)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=Fedora Secure Boot CA
            Not Before: Oct 10 17:14:58 2012 GMT
            Not After : Jan 10 17:14:58 2013 GMT
        Subject: CN=Fedora Secure Boot CA
        Subject Public Key Info:
        X509v3 extensions:
            Netscape Cert Type: 
                Object Signing CA
            X509v3 Key Usage: 
                Certificate Sign, CRL Sign

It's too short-lived, Basic Constraints are not set, and the (mostly meaningless) self-signature should use SHA-256 (because that's the hash algorithm mandated throughout the UEFI specification).
Comment 2 Peter Jones 2012-10-30 13:19:46 EDT
I've attached the wrong file here.  Sorry.  Will update shortly with the correct one.
Comment 3 Peter Jones 2012-10-30 13:22:19 EDT
Created attachment 635698 [details]
Actual updated certificate.
Comment 4 Peter Jones 2012-10-30 16:57:07 EDT
It should be noted, though, that nothing in secure boot seems to care about any of: Basic Constraints, Auth Key Id, Subject Key Id, or Validity dates.  To a certain degree this seems to be correct - those fields aren't necessary for validation of a signature, and the system clock is something that can be set by an attacker.

SHA-256 is clearly what we need to have there, as there's no (current) guarantee that anything else will be implemented in system firmware.

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