IsBootSecure PK question

[Hero8414]

I ran IsBootSecure v3 on a ~5-year-old pre-built desktop PC from a major OEM that's running Win 10 22H2 (fully up-to-date). The app showed green: Secure Boot enabled/Secure Platform key, but...

The Certificate screen says the certificate expired back in 2022:

The Certification Path tab also says: This CA Root certificate is not trusted because it is not in the Trusted Root Certification Authorities store.

Is this something that needs to be updated, even if Secure Boot is running and using a secure PK? Would this be something the PC OEM has to do or...?

 

[AlanD]

There are two issues here:-

1. The CA Root certificate in the UEFI is not listed in Windows Certificate store. That should not matter as it is being used for a different purpose, so Windows would not need to know to trust it. Your UEFI code does know to trust it and that is what uses it.

2. The certificate has expired. That should not matter as long as any code signed by that certificate is dated before the expiry date. The only issue would be if you got a UEFI update patch from the manufacturer, which was dated after the xepiry date, AND the patch did not include an updated certificate. In other words, as long as teh certificate was valid when the code was created, it is good to go.

 

[Hero8414]

There are two issues here:-

1. The CA Root certificate in the UEFI is not listed in Windows Certificate store. That should not matter as it is being used for a different purpose, so Windows would not need to know to trust it. Your UEFI code does know to trust it and that is what uses it.

2. The certificate has expired. That should not matter as long as any code signed by that certificate is dated before the expiry date. The only issue would be if you got a UEFI update patch from the manufacturer, which was dated after the xepiry date, AND the patch did not include an updated certificate. In other words, as long as teh certificate was valid when the code was created, it is good to go.

Thanks for the input.

As long as UEFI still trusts the CA Root certificate, that's good...

The OEM has released quite a few BIOS updates since the CA Root Cert expired, typically to fix CVEs, but they never say much about the issue or the fix. So I guess UEFI hasn't been updated since the cert's expiration date which is 2+years out of date. If there was ever a mismatch between a UEFI update and the expiration date, would it throw an error message, or just refuse to boot?

Thanks again...

 

[AlanD]

I am not sure, but I suspect it would refuse to SecureBoot. You may well be able to get into the UEFI and disable Secure Boot, but then might find that Win11 will not run as it is not secure. More tolerant OS's might.

 

[PHolder]

might find that Win11 will not run

My experimenting with Win 11 in a VM was that it didn't say a peep if I disabled secure boot or disabled the TPM. It was aware, but it made no mention to me as the user. Granted that was at least a year ago, and the OS has kept evolving, so I can't say for sure what the modern code will be like.

 

[Hero8414]

Thanks for the added info.

I'm still running Win 10 and so don't know what it will happen if there's a mismatch between a UEFI update and the cert expiration date.

Guess I'll find out -the hard way- if that ever happens, though at this point the OEM is unlikely to release any further BIOS updates for this ~5-year-old PC model....

 

[Darcon]

UEFI does not check for expired certificates. The expiration date is required by the public key certificate itself. If there is no need to check the expiration, then the date is ignored.

It can be problematic to set very long expiration dates in certificates as the format of the date changes the further out you go. Then the validation process gets more complicated as the "usual" format can't be used for all dates so both formats need to be accepted. Then there are the date extraction methods, where if the date is in UTC (like it should be in my opinion to avoid conversions and daylight savings time) and the default options on extraction methods convert to local time, the date can become out of legal range for the target format (ASN.1 to XML for example) and cause additional errors.

It is much easier to just not validate the expiration for long lived certificates that are unlikely to ever be revoked.

 

[Hero8414]

Guess I can just ignore the cert expiration date...

If I hadn't run IsBootSecure, I'd never known about that expiration date. So a case of "TMI"!

 

[SeanBZA]

Followed the Linux instructions (thanks Steve for making them so clear, just a tip somebody please give the RH equivalent for those who do not use Debian) and my computer is free from that issue. i3 CoffeeLake, bios dated 2021, new to me Dell.