Get-Childitem Cert:\LocalMachine\CA giving weird results suddenly

PowerShell Help
1

My work is using alot of security certificates using EAP authentication through Cisco ISE. And when a new client (PC) is installed through our work i usually do a quick function testing. And some of the testing includes checking valid certificates and Wi-Fi work access. Everything has been running fine for years, untill today where suddenly “some” PC models/makes display odd behavior.

Customers coming back with their new PC to me saying that their wireless access is not working.
I take the computer back and check their Certificate folder manually by going into Windows MMC tool, adding the module/plug-in called Certificate and loading their certs locally. This displays the certificate i am always querying remotely using WinRM and Invoke-Command + Get-ChildItem. But the thing is, when i do the check remotely all Portable Laptops gives me zero results on a specific certificate called: VG Root CA V2. But when checking other models like HP or Dell tower computers and small clients i get the certificate. The models are nothing new, same as we always used.

$Certifikat = Invoke-Command -computername $computerName -ScriptBlock {Get-ChildItem Cert:\LocalMachine\CA | Where-Object Subject -Match "VG Root CA V2"}

result could be

Computer1 | Model: HP EliteBook : zero results…
Computer2 | Model: HP Tower : VG Root CA V2
Computer3 | Model: HP ProBook : zero results…

But when doing a local query each computer has the certificate inside the folder. And i checked
Expiration Date, Valid, Issued by, Issued to and everything looks the same. Even thumbprint. I tried asking ChatGPT and the results given were that either;

“Certificate Revocation List (CRL): Check that the CRL for the VGC Root certificate has not been updated or expired. If it has, this could cause some models to fail to find the certificate.”

What do you think? Local query finds the certificate on all models. But remote query stopped showing on all portable devices. Where just a week ago all was just displaying fine and showing up. And no users were having Wi-Fi access issues. The certificate from Cisco is stating that

  1. if the certificate is valid
  2. Issued by is Cisco Root etc …
  3. then connection will be authenticated.

Still not answering why a remote query using Invoke-Command not displaying the certificate at all on those models as in my example with Computer1-3. :confused:

2

paddingtonbear,
Welcome to the forum. :wave:t3:

Something must have changed in the meentime … obviously. What was it?

What happens when you omit the Where-Object filter and list all certificates? Does the list contain the desired certificates as well?

3

Hello and thank you for the welcome Olaf :blue_heart:!

Since ive been running my “checks” everyday in a big array using CIM cmdlets and Cimsession. I have historical data with ~140 client(s) mixed in models and supplier (Dell, HP etc). And just recently changed. So i immediately linked the happening to portable devices not being able sometimes to access wireless AP:s. I did not know that there were a difference in the checks though inside Powershell, but maybe chatGPT was into something after all…?

Local Certificate Store - learn.microsoft.com/en-us/answers/

During the evening i also checked several sources regarding this. And Cisco themselves just asked me to check ISE AP logs, which is kinda hard for me since this is outside my “work” tasks as an SCCM admin and more towards Server Admins, and those people in my work are hard to come by most likely hired for consulting purpose (outsourced) directly from Cisco when needed? i guess our Organization relies alot on Azure Cloud Services AD, maybe alittle too much these days. Cause if anyone were watching the ‘logs’ in Cisco ISE they would have noticed alot of failed login/auth attempts to wireless AP:s lately. :grimacing:

I will check today at work if doing several different ways without ´´´Where-Object´´´ if result comes up differently. And if doing the checks towards Personal Cert:\ instead of LocalMachine CA does something. Maybe the Network hierarchy changed something after all, since the odd behavior seem to affected ALL portable device(s), as of this week.