Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW

How to find certificates by thumbprint or name with powershell

No ratings
cancel
Showing results for 
Search instead for 
Did you mean: 
Sonja_Bauernfeind
Digital Support
Digital Support

How to find certificates by thumbprint or name with powershell

Last Update:

Jan 13, 2021 2:00:08 PM

Updated By:

Andre_Sostizzo

Created date:

Jan 13, 2021 2:00:08 PM

Finding a certificate by thumbprint or name is sometimes needed such as when tracking down what certificate is being used by the Qlik Sense Proxy service. It is possible to find the certificate via Powershell. See example below as well for finding via the MMC.

Environment:

  • Qlik Sense Enterprise on Windows, all versions

 

Resolution:

You can run the following command in Powershell to find a certificate by a specific thumbprint. Make sure to remove the spaces between the digits:

Get-ChildItem -path 'Cert:\*CertificateThumbprintWithoutAnySpaces' -Recurse

Example, piping into Format-List to display in a more-friendly manner:

PS Cert:\CurrentUser\My> Get-ChildItem -path 'Cert:\*838A1C18C19FREDACTED47CC21071A0F220617466' -Recurse | Format-List


Subject      : CN=QlikClient
Issuer       : CN=QlikServer1.domain.local-CA
Thumbprint   : 838A1C18C19FREDACTED47CC21071A0F220617466
FriendlyName : QlikClient
NotBefore    : 2017-10-01 22:14:44
NotAfter     : 2027-10-08 22:14:44
Extensions   : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid}

 

The certificate can also be found using MMC by searching using the harsh algorithm used (e.g. SHA1). Right-click Certificates (Local Computer) in MMC > Find Certificates, and pick the hash algorithm under Look in Field, with the thumbprint in the Contains box. The gif below covers both methods mentioned.

 

FindCertbyThumbprintPSMMC.gif

 


Similarly, you can search by the name/subject of a certificate:

Get-ChildItem -path Cert:\* -Recurse | where {$_.Subject –like '*SomeSearchQuery*'}

Example:

PS Cert:\CurrentUser\My> Get-ChildItem -path Cert:\* -Recurse | where {$_.Subject –like '*qlik*'}


    Directory: Microsoft.PowerShell.Security\Certificate::CurrentUser\Root


Thumbprint                                Subject
----------                                -------
75B2E11D236C1E90A43F1C1D68FFF01CB2089522  CN=QlikServer1.domain.local-CA


    Directory: Microsoft.PowerShell.Security\Certificate::CurrentUser\My


Thumbprint                                Subject
----------                                -------
838A1C18C19FF0D921847CC21071A0F220617466  CN=QlikClient


    Directory: Microsoft.PowerShell.Security\Certificate::LocalMachine\Root


Thumbprint                                Subject
----------                                -------
75B2E11D236REDACTEDC1D68FFF01CB2089522  CN=QlikServer1.domain.local-CA


    Directory: Microsoft.PowerShell.Security\Certificate::LocalMachine\Remote Desktop


Thumbprint                                Subject
----------                                -------
C9DF4AE5CREDACTEDB5EA58100F448A9761D79C5  CN=QlikServer1.domain.local


    Directory: Microsoft.PowerShell.Security\Certificate::LocalMachine\My


Thumbprint                                Subject
----------                                -------
F54824A7648D6REDACTED2A4FFED295B29F6251  CN=QlikServer1.domain.local

 

Labels (2)
Comments
diagonjope
Partner - Creator II
Partner - Creator II

Greetings @Sonja_Bauernfeind,

We have a situation where the QSEfW services are occasionally not able to communicate amongst themselves after a reboot triggered by an operating system patch update. 

It seems that the Qlik services can't find the certificates during the startup phase, because everything works again when we manually remove what appear to be proper and valid Qlik certificates (according to MMC) from the certificate store and go through the bootstrap procedure to regenerate the certificates.   

We think that perhaps this happens because the QSE services are looking for a friendly name or thumbprint of the certificates that they need to use that differs from the ones in the certificate store, perhaps because the OS patch process somehow changes either the name or some attribute of the existing certificates and this causes a failure in the search process for the certificates.

Does QSEfW store in config files the names or thumbprints of the certificates that it looks for or are these names embedded in the code? 

How can one determine the certificate name being searched by the services at run time, in order to match that vs. the certificates that are actually available in the certificate store?

Are the names or thumbprints of the certificates being used by the QSE services logged somewhere during the startup phase?

In summary, how can we determine why do we have to regenerate the certificates every time a Windows patch is applied?

Please advise.

Cheers,

++José

Sonja_Bauernfeind
Digital Support
Digital Support

Hello @diagonjope 

If we'd been talking about the Proxy Certificate only (which could be a 3rd party cert), then I'd have recommended checking the relevant logs to see what thumbprint it is looking for.

These two articles document examples on what those log entries look like:

How to change the certificate used by the Qlik Sense Proxy to a custom third party certificate 
ERR_CERT_COMMON_NAME_INVALID when using 3rd party certificate 

As for why Windows patches would invalidate your certs, I can think of a number of reasons:

  • Are the permissions on the certificate stores being changed at system restart/patch application?
  • Are the permissions to the private key being changed at system restart/patch application? How to manage the Certificate Private Key 

I see you have already posted about this in our forums. Should this not help, I'd recommend logging a ticket with support.

All the best,
Sonja 

 

diagonjope
Partner - Creator II
Partner - Creator II

Hi @Sonja_Bauernfeind !

Thanks for your reply.

Actually, I am referring to the certificates used internally amongst the services and generated by the <FQN>-CA authority.

We already opened a support case, but, quite frankly, I am not seeing much progress on that end.

We'll check the two options that you mention regarding permissions for the certificates to see if that could be the reason.

Cheers,

++José

Sonja_Bauernfeind
Digital Support
Digital Support

Hello again @diagonjope 

I've had a chat with one of our SMEs and he suggested checking the following:

As you restart the Windows server (after patching it, I assume a restart would happen?), does a policy get applied which invalidates any certificates not created by a trusted root authority? 

All the best,
Sonja 

 

diagonjope
Partner - Creator II
Partner - Creator II

Thank you @Sonja_Bauernfeind for digging further into the potential causes of this issue.

We will check your suggestion.

Cheers,

++José

Contributors
Version history
Last update:
‎2021-01-13 02:00 PM
Updated by: