Updated TPM Boot certificates

[Mike Leone]

OK, I'm gonna ask a couple stupid questions here.

I still have a bunch of Win 2012 R2 servers (not my choice, I've been trying for years t get them upgraded. Hey, I just work here ....).  I will double check, but I'm practically certain all the VM BIOSes are in LEGACY mode, not UEFI, and the TPM boot certs only apply to UEFI BIOS, right?

That BIOS LEGACY concern applies to any later OS, too, right? I still have Windows 2016, 2019, and 2022 VMs all over the place. Pretty sure the vast majority of them are not using UEFI BIOS, so they'd never need (or get) the updated certificates, either. Is that right?

Sorry for the dense questions.

--

Mike. Leone, <mailto:tur...@mike-leone.com>

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: <http://www.flickr.com/photos/mikeleonephotos>

[Wright, John M]

Yes, it’s only under UEFI.

 

--

John Wright

IT Support Specialist

1800 Old Bluegrass Avenue, Louisville, KY 40215

502.708.9953

Please submit IT requests to Hazelwoo...@bluegrass.org

24 Hour Helpline 1.800.928.8000

  

CONFIDENTIALITY NOTICE: This message contains confidential information and is intended only for the individual(s) addressed in the message. If you are not the named addressee, you should not disseminate, distribute, or copy this e-mail. If you are not the intended recipient, you are notified that disclosing, distributing, or copying this e-mail is strictly prohibited.

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Mike Leone
Sent: Friday, May 15, 2026 11:37 AM
To: NTSysAdmin <ntsys...@googlegroups.com>
Subject: [ntsysadmin] Updated TPM Boot certificates

 

EXTERNAL EMAIL - This email was sent by a person from outside your organization. Exercise caution when clicking links, opening attachments or taking further action, before validating its authenticity.

Secured by Check Point

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2BhqjNxEDk5EFC7Bqv6obxHEf7JdHKDffYYcSzg-zgK8jw%40mail.gmail.com.

[Mike Leone]

OK! That's something ... I assume that the same applies to physical boxes, right? They will get their updated TPM certs from MS, too? I don't need to go digging on the hardware manufacturer site for them?

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/SN7PR12MB6714A53CFA02DFA114F74ADF91042%40SN7PR12MB6714.namprd12.prod.outlook.com.

[Wright, John M]

Yes, as long as they’re getting updates, the certs will be updated.

 

If you check around, you might find that some at least have already been updated.  My work laptop for example has a cert with this subject property.

 

Subject           : CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2BjTr5eEXY8pY3-wDpyvTNfsFn%2BEi_0%3DCSN88-BQYjCFmg%40mail.gmail.com.

[Charles F Sullivan]

Mike is giving me the courage to ask what also might be a stupid question.

If I simply enter the BIOS of a computer and disable secure boot, then that solves the problem, should it arise. Isn't that correct?

If I'm right, then anyone with physical access can disable it unless the BIOS is password protected.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/SN7PR12MB67148DD1E97C143487C6471D91042%40SN7PR12MB6714.namprd12.prod.outlook.com.

--

Charlie Sullivan

Principal Windows Systems Administrator

[Charles F Sullivan]

That could be taken as me suggesting Mike's question was stupid. It wasn't stupid at all, despite his framing it that way!

[Mike Leone]

On Mon, May 18, 2026, 5:46 PM 'Charles F Sullivan' via ntsysadmin <ntsys...@googlegroups.com> wrote:

That could be taken as me suggesting Mike's question was stupid. It wasn't stupid at all, despite his framing it that way!

Not all, I understood what you were saying. LOL

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CAEuHzzmaak0%3DG%2Bgq911MNo%3DF%3Dt0nseximuOMfRFxSNRfmfw-3w%40mail.gmail.com.

[Chris Brewer]

I wouldn't say disabling Secure Boot "solves" the problem, but it does allow you to cover your ears, close your eyes, and go "la la la la la" while the Secure Boot expiration date passes by uneventfully. Of course, you open yourself up to many other potential vulnerabilities that Secure Boot protects against.

Regarding your second statement, yes - anyone with physical access and no BIOS password can disable Secure Boot. And boot to another OS. And even install that other OS. Or reinstall Windows. Or whatever they want, really.

It's not a stupid question, but it's good to think through the available options for approaching this expiration date. As John mentioned, many devices may already see the certificate updates when they reboot for monthly patches, for example. Other devices may not apply the updates for some reason; the trick is figuring out what each machine looks like centrally.

Thanks,

Chris

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CAEuHzz%3D_LvPyUidRXFE1sGVDg1_d5zuSa%3DiYOCb%2BXrRx-3LAJg%40mail.gmail.com.

[Philip Elder]

So, on the low hanging fruit side of things, has anyone seen an exploit that SecureBoot would protect against?

 

Philip Elder MCTS

Senior Technical Architect

Microsoft High Availability MVP

MPECS Inc.

E-mail: Phili...@MPECSInc.Ca

Phone: +1 (780) 458-2028

Web: www.MPECSInc.Com

Blog: Blog.MPECSInc.Com  

Twitter: Twitter.com/MPECSInc

 

Please note: Although we may sometimes respond to email, text and phone calls instantly at all hours of the day, our regular business hours are 8:00 AM - 5:00 PM, Monday thru Friday.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CANYDaP9hOaHy3nd_mAb%2BBs-iYzS1wnQRs6bjfboFZ2EJRvoveQ%40mail.gmail.com.

[Charles F Sullivan]

Thanks for the confirmation.

The problem I was referring to is if a machine won't boot. That would very much be a problem that needs immediate attention.

I am retiring at the end of next week and I'll be leaving hundreds of server VMware VMs behind. I'm scrambling to test, document and hopefully find a good solution to leave behind. I am apparently the only one in my small group who was even aware of this. I didn't feel that compelled to act because Broadcom seemed to say for so long that there was nothing to worry about. Then that changed somewhat. (That's not to say that I didn't plan on acting on this, it just seems a bit dire now.)

We only have about 15 physical servers and I don't think most have secure boot enabled, but I'll confirm. Speaking of that, we have at least 100 server VMs that are not UEFI based, so they are vulnerable by nature.

Thanks mostly to this group, I have lots of links and such to help me out with this. (I've been saving the related conversations for months.)

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/e4de44785f0f4c839684d903167e7814%40MPECSInc.Ca.

[Michael B. Smith]

FinSpy, ESpecter, MoonBounce – pop to mind.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CAEuHzz%3Dgb0E%3Dcc04SR4qMBHOkeoCecjjZasV%2B4WZqb8-Li2xAA%40mail.gmail.com.

[Mike Leone]

So I spent some time thinking about this. And currently I am this stage of thought:

There are a number of checks, some of which problem don't apply. Follow me on this:

1. UEFI BIOS. Updated certificates mean nothing for legacy BIOS, so no UEFI, no problem.

2. TPM must be present. I have a number of VMs (Win 2022) and even hardware, that have no TPM. These VMs were created a while ago, and the TPM option not checked. They're Win 2022, where TPM is not required (unless you need like BitLocker or something). So again, updated certificates mean nothing if you have no TPM. 

3,  It's possible for TPM to be present but not enabled (I suppose - none of my hosts match this).

4. It's possible for TPM to be presented and not be activated? (again, none of my hosts match this)

So then the script logic comes down to something like this:

  $script:BIOS = Invoke-Command -ComputerName $MemberServer -ScriptBlock { $env:firmware_type }
IF ($BIOS -eq "UEFI") {
    $script:HasTPM = Invoke-Command -ComputerName $MemberServer -ScriptBlock { Get-TPM }
    IF ($HasTPM) {
         $TPM_Present = $HasTPM.TpmPresent
          $TPM_Enabled = $HasTPM.TpmEnabled
          $TPM_Ready = $HasTPM.TpmReady
          $TPM_Activated = $HasTPM.TpmActivated
      }
      IF ($TPM_Present) {
          IF ( $TPM_Enabled) {
              IF ( $TPM_Activated ) {
                     $script:Check_for_TPM_certificates = Invoke-Command -ComputerName $MemberServer -ScriptBlock { Confirm-SecureBootUEFI }-ErrorAction SilentlyContinue

                      IF ( $Check_For_Updated_TPM_Certificates) {

                              Has updated Certs

                       ELSE

                              Needs updated certs

(yes, I've left off the ELSEs and the closing braces. It's pseudo code, more or less, for clarity)

That's right, isn't it? Must be UEFI BIOS *AND* TPM must be present (and enabled and activated) else no need to worry about updated certificates. And UEFI and TPM prescense *required* only apply to Win 11 and Win 2025. They're optional on earlier (Win 2022) servers, and only need to be updated if they even exist for such earlier OSes.

Did I miss something here?

[Michael B. Smith]

So, I’ve stayed out of this because – pedantry. 😊

 

Secure Boot and TPM are not the same thing.

 

Secure Boot requires TPM.

 

You can have TPM without Secure Boot.

 

You can have UEFI without Secure Boot.

 

You cannot have Secure Boot without TPM.

 

You cannot have Secure Boot without UEFI.

 

You can have TPM without it being enabled (tpm.msc is the console for handling the TPM and obviously you can do it from PowerShell and .NET).

 

If your firmware is UEFI, then you have a TPM and you might have secure boot enabled.

 

To confirm secure boot is enabled, you use Confirm-SecureBootUEFI.

 

To confirm that the certificates are updated:

 

[System.Text.Encoding]::Ascii.GetString( ( Get-SecureBootUEFI db ).bytes ) -match 'Windows UEFI CA 2023'

 

So, on a target computer:

 

               if( $env:Firmware_Type -eq ‘UEFI’ )

               {

                              if( Confirm-SecureBootUEFI )

                              {

                              if( [System.Text.Encoding]::Ascii.GetString( ( Get-SecureBootUEFI db ).bytes ) -match 'Windows UEFI CA 2023' )

                              {

                                             ## has updated certs

                              }

                              else

                              {

                                             ## needs updated certs

                              }

                              }

                              else

                              {

                                             ## secure boot not enabled

                              }

               }

               else

               {

                              ## BIOS, not UEFI

               }

 

You can obviously add in the remoting as you please.

--

You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2Bg6wJRn0YzC-w1Q9jPsLeNgrZRwATqNr2pCwfk%3DNShZVQ%40mail.gmail.com.

[Mike Leone]

On Wed, May 20, 2026 at 4:09 PM Michael B. Smith <mic...@smithcons.com> wrote:

So, I’ve stayed out of this because – pedantry. 😊

 

Secure Boot and TPM are not the same thing.

 

Secure Boot requires TPM.

 

You can have TPM without Secure Boot.

 

You can have UEFI without Secure Boot.

 

You cannot have Secure Boot without TPM.

 

You cannot have Secure Boot without UEFI.

 

You can have TPM without it being enabled (tpm.msc is the console for handling the TPM and obviously you can do it from PowerShell and .NET).

 

If your firmware is UEFI, then you have a TPM and you might have secure boot enabled.

 

To confirm secure boot is enabled, you use Confirm-SecureBootUEFI.

 

To confirm that the certificates are updated:

 

[System.Text.Encoding]::Ascii.GetString( ( Get-SecureBootUEFI db ).bytes ) -match 'Windows UEFI CA 2023'

OH. I thought the  Confirm-SecureBootUEFI checked for updated certificates. But it doesn't ...

    The Confirm-SecureBootUEFI cmdlet confirms that Secure Boot is enabled by checking the Secure Boot status on a
    UEFI computer.

Now I feel even more stupid then usual. LOL

So, on a target computer:

 

               if( $env:Firmware_Type -eq ‘UEFI’ )

               {

                              if( Confirm-SecureBootUEFI )

                              {

                              if( [System.Text.Encoding]::Ascii.GetString( ( Get-SecureBootUEFI db ).bytes ) -match 'Windows UEFI CA 2023' )

                              {

                                             ## has updated certs

                              }

                              else

                              {

                                             ## needs updated certs

                              }

                              }

                              else

                              {

                                             ## secure boot not enabled

                              }

               }

               else

               {

                              ## BIOS, not UEFI

               }

 

You can obviously add in the remoting as you please.

I'll be re-writing that section of my script tomorrow.  

$script:Updated_Certs = Invoke-Command -ComputerName $MemberServer -ScriptBlock { ([System.Text.Encoding]::Ascii.GetString( ( Get-SecureBootUEFI db ).bytes ) -match 'Windows UEFI CA 2023' )}

And that should evaluate to TRUE or FALSE, right? 

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/8264dedda4d24065acf912639cd1afde%40smithcons.com.

[Michael B. Smith]

>> I'll be re-writing that section of my script tomorrow.  

>> $script:Updated_Certs = Invoke-Command -ComputerName $MemberServer -ScriptBlock { ([System.Text.Encoding]::Ascii.GetString( ( Get-SecureBootUEFI db ).bytes ) -match 'Windows UEFI CA 2023' )}

>> 

>> And that should evaluate to TRUE or FALSE, right? 

 

Yes. And in case it isn’t obvious, it must be executed from an elevated session.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2BisaBJh6FuQXNKFh40Op-w7typoMq%3Dt3POZRr1Kw55u9g%40mail.gmail.com.

[Mike Leone]

So after yet more thinking, I'm down to this:

Updated TPM certificates only apply to Win 2025 servers (earlier OSes did not require TPM, so - for MY SITUATION - anything earlier than Win 2025 wouldn't have a TPM. And even if it does, the OS isn't looking at it , anyway. So I don't need to worry about it.) I am not checking workstations with this script (yet).

Right?

If so, then I'm down to this:

If I can connect to a server, I check its OS. If it's Win 2025, I check that it has Secure Boot enabled. If so, I check the TPM certs therein.

ForEach ($MemberServer in $AllMemberServers) {
  IF (Test-Connection -ComputerName $MemberServer -Count 2 -Quiet) {
    $Connected = $TRUE
    $OS_being_checked = $NULL
    $script:OS_being_checked = Invoke-Command -ComputerName $MemberServer -ScriptBlock { Get-ComputerInfo | Select-Object -ExpandProperty OSName }
    $OS_Requires_TPM_Certs = ($OS_being_checked -match $Server_OS_that_requires_TPM)
    IF ( $OS_Requires_TPM_Certs ) {

      $script:BIOS = Invoke-Command -ComputerName $MemberServer -ScriptBlock { $env:firmware_type }

      $script:HasTPM = Invoke-Command -ComputerName $MemberServer -ScriptBlock { Get-TPM }

      $Has_Secure_Boot = $NULL
      $Has_Updated_Certs = $NULL
      $script:Has_Secure_Boot = Invoke-Command -ComputerName $MemberServer -ScriptBlock { Confirm-SecureBootUEFI }-ErrorAction SilentlyContinue
      IF ( $Has_Secure_Boot) {
         $script:Has_Updated_Certs = Invoke-Command -ComputerName $MemberServer -ScriptBlock {([System.Text.Encoding]::Ascii.GetString( ( Get-SecureBootUEFI db ).bytes ) -match 'Windows UEFI CA 2023' )}
         IF ($Has_Updated_Certs ) {
            $SuccessCnt ++
         } ELSE {
            $NonSuccessCnt ++
         }
     }

(I'm old, I like resetting variables in loops before I try and set them, just to avoid any leftover issues)

There's actually a bit more to the script, in terms of writing output and compiling it into an email. But that should work, to check 

Anybody see any glaring errors here? (thanks to Michael Smith for setting me straight on the difference between SecureBootEUFI and actually checking for an updated cert within that)

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/064f2c4db1bc481b80f9a9a675da2539%40smithcons.com.

[Michael B. Smith]

Conceptually, this looks ok. I didn’t test it.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2BgGWNzo8fv9QY-GuLtqgC5qz84CYD0wpY%2BFH0pbGcbODA%40mail.gmail.com.