9:20 a.m.
Hello,
I was poking around a F38 system to look over the Secure Boot certificates and
found something that may warrant attention.
sbattach --detach signature /boot/efi/EFI/BOOT/fbx64.efi
openssl pkcs7 -inform DER -in signature -text -print_certs > grub-certs.txt
Issuer: CN=Fedora Secure Boot CA
Validity
Not Before: Dec 7 16:04:24 2012 GMT
Not After : Dec 5 16:04:24 2022 GMT
Subject: CN=Fedora Secure Boot Signer
Not after Dec 5, 2022 ??? I think this is expired. But also
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
I think we should be on 3072 or higher at this point. But what about the
shim?
sbattach --detach signature /boot/efi/EFI/BOOT/BOOTX64.EFI
openssl pkcs7 -inform DER -in signature -text -print_certs > shim-certs.txt
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
CN=Microsoft Corporation UEFI CA 2011
Validity
Not Before: Sep 9 19:40:20 2021 GMT
Not After : Sep 1 19:40:20 2022 GMT
This is also expired.
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
And also not big enough. This raises a questions. Has Microsoft updated their
certificate? Is it well distributed such that switching to it will not brick
systems? Should Fedora get a new shim for Fedora 39? Can the update move to
3072 to be compliant with CNSA 1.0 requirements? And if so, that also means
moving to SHA-384. Or did I miss some system-upgrade step that updates the
bootloader?
TBH, I am surprised by this finding. But we're all busy and it *is* working.
Best,
-Steve
10:18 a.m.
On Fri, May 26, 2023 at 2:20 PM Steve Grubb <sgrubb(a)redhat.com> wrote:
Hello,
I was poking around a F38 system to look over the Secure Boot certificates and
found something that may warrant attention.
I *suspect* this is all wrapped into the issue that
shims must now have/use NX support to be signed,
and that first requires the kernel patches that
support NX to be merged.
The thread about the NX requirement and the
kernel patch is included (although a bit hard
to find) in the ticket
https://bugzilla.redhat.com/show_bug.cgi?id=2113005
I do not know where in the process the kernel patch
currently is (last I knew, it was still in review).
10:49 a.m.
On Friday, May 26, 2023 11:18:32 AM EDT Gary Buhrmaster wrote:
On Fri, May 26, 2023 at 2:20 PM Steve Grubb <sgrubb(a)redhat.com>
wrote:
> I was poking around a F38 system to look over the Secure Boot
> certificates and found something that may warrant attention.
I *suspect* this is all wrapped into the issue that
shims must now have/use NX support to be signed,
and that first requires the kernel patches that
support NX to be merged.
The thread about the NX requirement and the
kernel patch is included (although a bit hard
to find) in the ticket
https://bugzilla.redhat.com/show_bug.cgi?id=2113005
I do not know where in the process the kernel patch
currently is (last I knew, it was still in review).
I found at least one piece of the puzzle. The UEFI specification only goes up
to RSA 2048
https://uefi.org/specs/UEFI/2.10/32_Secure_Boot_and_Driver_Signing.html
I poked around on some other systems. Looks like Microsoft only issues CA
certificates with a 1 year expiration. So, they have expired certificates
everywhere. On RHEL 9 the grub bootloader certificate appears to be valid
until 2038 which coincides with when clocks may have a problem.
In any event, I better understand what's going on.
-Steve
9 p.m.
On Fri, May 26, 2023, at 10:20 AM, Steve Grubb wrote:
sbattach --detach signature /boot/efi/EFI/BOOT/BOOTX64.EFI
openssl pkcs7 -inform DER -in signature -text -print_certs > shim-certs.txt
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
CN=Microsoft Corporation UEFI CA 2011
Validity
Not Before: Sep 9 19:40:20 2021 GMT
Not After : Sep 1 19:40:20 2022 GMT
What version of shim do you have installed? What edition/spin are you using?
I have shim-x64-15.6-2.x86_64 and it's reporting
Not Before: Jun 27 21:22:45 2011 GMT
Not After : Jun 27 21:32:45 2026 GMT
A possible explanation is rpm-ostree derivatives may show a current version grub and shim,
but those are not copied to the EFI System partition. That's the job of bootupd but
I'm not sure if that's fully implemented yet in Fedora.
--
Chris Murphy
1:15 a.m.
On Tue, 2023-05-30 at 22:00 -0400, Chris Murphy wrote:
On Fri, May 26, 2023, at 10:20 AM, Steve Grubb wrote:
> sbattach --detach signature /boot/efi/EFI/BOOT/BOOTX64.EFI
> openssl pkcs7 -inform DER -in signature -text -print_certs > shim-certs.txt
>
> Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
> CN=Microsoft Corporation UEFI CA 2011
> Validity
> Not Before: Sep 9 19:40:20 2021 GMT
> Not After : Sep 1 19:40:20 2022 GMT
What version of shim do you have installed? What edition/spin are you using?
I have shim-x64-15.6-2.x86_64 and it's reporting
Not Before: Jun 27 21:22:45 2011 GMT
Not After : Jun 27 21:32:45 2026 GMT
A possible explanation is rpm-ostree derivatives may show a current version grub and
shim, but those are not copied to the EFI System partition. That's the job of bootupd
but I'm not sure if that's fully implemented yet in Fedora.
Yeah, that's likely it. There's a lot of discussion of this kinda thing
at:
https://github.com/fedora-silverblue/issue-tracker/issues/120
https://github.com/fedora-silverblue/issue-tracker/issues/355
and various other places linked from there...
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
8:57 a.m.
On Tuesday, May 30, 2023 10:00:53 PM EDT Chris Murphy wrote:
On Fri, May 26, 2023, at 10:20 AM, Steve Grubb wrote:
> sbattach --detach signature /boot/efi/EFI/BOOT/BOOTX64.EFI
> openssl pkcs7 -inform DER -in signature -text -print_certs >
> shim-certs.txt>
> Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
>
> CN=Microsoft Corporation UEFI CA 2011
>
> Validity
>
> Not Before: Sep 9 19:40:20 2021 GMT
> Not After : Sep 1 19:40:20 2022 GMT
What version of shim do you have installed? What edition/spin are you
using?
This is plain old F38. The shim is shim-x64-15.6-2.x86_64
I have shim-x64-15.6-2.x86_64 and it's reporting
Not Before: Jun 27 21:22:45 2011 GMT
Not After : Jun 27 21:32:45 2026 GMT
A possible explanation is rpm-ostree derivatives may show a current version
grub and shim, but those are not copied to the EFI System partition.
That's the job of bootupd but I'm not sure if that's fully implemented yet
in Fedora.
Appearantly not. But rpm -qf /boot/efi/EFI/BOOT/BOOTX64.EFI shows it is owned
by the shim. locate BOOTX64.EFI only shows one location, the previously
mentioned path.
I understand that certificate validation cannot take time and date into
account during boot because you have no idea if the system clock is accurate
until the whole OS can run a NTP sync. But I am just surprised my system has
binaries with expired signatures.
-Steve
12:31 p.m.
I also have a recently updated F38 with shim-x64-15.6-2.x86_64. The
BOOTX64.EFI file has two certificates
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
CN=Microsoft Windows UEFI Driver Publisher
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
CN=Microsoft Corporation UEFI CA 2011
The first one's validity is
Not Before: Sep 9 19:40:20 2021 GMT
Not After : Sep 1 19:40:20 2022 GMT
and the second's:
Not Before: Jun 27 21:22:45 2011 GMT
Not After : Jun 27 21:32:45 2026 GMT
Are these certs for different purpose, or is the second one supposed to
supersede the previous one?
On 5/31/23 09:57, Steve Grubb wrote:
> On Tuesday, May 30, 2023 10:00:53 PM EDT Chris Murphy wrote:
>> On Fri, May 26, 2023, at 10:20 AM, Steve Grubb wrote:
>>> sbattach --detach signature /boot/efi/EFI/BOOT/BOOTX64.EFI
>>> openssl pkcs7 -inform DER -in signature -text -print_certs >
>>> shim-certs.txt>
>>> Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
>>>
>>> CN=Microsoft Corporation UEFI CA 2011
>>>
>>> Validity
>>>
>>> Not Before: Sep 9 19:40:20 2021 GMT
>>> Not After : Sep 1 19:40:20 2022 GMT
>> What version of shim do you have installed? What edition/spin are you
>> using?
> This is plain old F38. The shim is shim-x64-15.6-2.x86_64
>
>> I have shim-x64-15.6-2.x86_64 and it's reporting
>>
>> Not Before: Jun 27 21:22:45 2011 GMT
>> Not After : Jun 27 21:32:45 2026 GMT
>>
>> A possible explanation is rpm-ostree derivatives may show a current version
>> grub and shim, but those are not copied to the EFI System partition.
>> That's the job of bootupd but I'm not sure if that's fully
implemented yet
>> in Fedora.
> Appearantly not. But rpm -qf /boot/efi/EFI/BOOT/BOOTX64.EFI shows it is owned
> by the shim. locate BOOTX64.EFI only shows one location, the previously
> mentioned path.
>
> I understand that certificate validation cannot take time and date into
> account during boot because you have no idea if the system clock is accurate
> until the whole OS can run a NTP sync. But I am just surprised my system has
> binaries with expired signatures.
>
> -Steve
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
10:05 a.m.
OK I tried this again and discover shim is signed twice.
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft
Corporation UEFI CA 2011
Not Before: Sep 9 19:40:20 2021 GMT
Not After : Sep 1 19:40:20 2022 GMT
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft
Corporation Third Party Marketplace Root
Not Before: Jun 27 21:22:45 2011 GMT
Not After : Jun 27 21:32:45 2026 GMT
This is the same for EFI/fedora/shimx64.efi and EFI/BOOT/BOOTX64.EFI which also have the
same sha256sum hashes.
So maybe there isn't actually a problem other than it's confusing that there are
two signatures that also have different validity periods? I'm not sure what it means.
--
Chris Murphy
8:29 a.m.
On Tue, 13 Jun 2023 11:05:53 -0400
"Chris Murphy" <lists(a)colorremedies.com> wrote:
OK I tried this again and discover shim is signed twice.
It has been awhile since I built a local kernel that I signed, but even
a locally built kernel was signed twice when using rpmbuild. I assume
that somewhere in the build plumbing there are two certificates and two
sign procedures. I just removed them because they were dummy
certificates (test) when I built locally, and I didn't need them.
So, this has been happening for years.
5:06 p.m.
On 6/14/23 09:29, stan via devel wrote:
On Tue, 13 Jun 2023 11:05:53 -0400
"Chris Murphy" <lists(a)colorremedies.com> wrote:
> OK I tried this again and discover shim is signed twice.
It has been awhile since I built a local kernel that I signed, but even
a locally built kernel was signed twice when using rpmbuild. I assume
that somewhere in the build plumbing there are two certificates and two
sign procedures.
If that's the case, one of those places is using an expired certificate.
I would have thought that signing tools would refuse to sign with an
invalid cert?
Maybe the build tools take an existing blob, signed way back when with
that expired cert, and re-sign it with a current cert?
6:20 p.m.
Chris Murphy wrote:
OK I tried this again and discover shim is signed twice.
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
CN=Microsoft Corporation UEFI CA 2011
Not Before: Sep 9 19:40:20 2021 GMT
Not After : Sep 1 19:40:20 2022 GMT
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
CN=Microsoft Corporation Third Party Marketplace Root
Not Before: Jun 27 21:22:45 2011 GMT
Not After : Jun 27 21:32:45 2026 GMT
Are you sure those are 2 independent signatures and not a signature chain?
Kevin Kofler
10:20 p.m.
On Wed, Jun 14, 2023, at 7:20 PM, Kevin Kofler via devel wrote:
Chris Murphy wrote:
> OK I tried this again and discover shim is signed twice.
>
> Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
> CN=Microsoft Corporation UEFI CA 2011
> Not Before: Sep 9 19:40:20 2021 GMT
> Not After : Sep 1 19:40:20 2022 GMT
>
> Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
> CN=Microsoft Corporation Third Party Marketplace Root
> Not Before: Jun 27 21:22:45 2011 GMT
> Not After : Jun 27 21:32:45 2026 GMT
Are you sure those are 2 independent signatures and not a signature chain?
No idea.
--
Chris Murphy
10:07 a.m.
On Wed, May 31, 2023, at 1:31 PM, przemek klosowski via devel wrote:
I also have a recently updated F38 with shim-x64-15.6-2.x86_64. The
BOOTX64.EFI file has two certificates
Ha! Yeah so I'm just repeating what you said two weeks ago.
I don't have an explanation for the dual signatures, whether or not it's a
problem.
--
Chris Murphy
364
days inactive
384
days old
12 comments
7 participants
participants (7)
-
Adam Williamson -
Chris Murphy -
Gary Buhrmaster -
Kevin Kofler -
przemek klosowski -
stan -
Steve Grubb