Re: SecureBoot certificates
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: SecureBoot certificates
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: SecureBoot certificates
On 6/14/23 09:29, stan via devel wrote: On Tue, 13 Jun 2023 11:05:53 -0400 "Chris Murphy" 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? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: SecureBoot certificates
On Tue, 13 Jun 2023 11:05:53 -0400 "Chris Murphy" 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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: SecureBoot certificates
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: SecureBoot certificates
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: SecureBoot certificates
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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: SecureBoot certificates
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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: SecureBoot certificates
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: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: SecureBoot certificates
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: SecureBoot certificates
On Friday, May 26, 2023 11:18:32 AM EDT Gary Buhrmaster wrote: > On Fri, May 26, 2023 at 2:20 PM Steve Grubb 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: SecureBoot certificates
On Fri, May 26, 2023 at 2:20 PM Steve Grubb 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). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
SecureBoot certificates
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
