Checking the certificate trust chain for an HTTPS endpoint

This post has been republished via RSS; it originally appeared at: IIS Support Blog articles.

Sometimes our client apps, including browsers, are unable or unwilling to connect to an HTTPS site. A common cause: the certificate presented by the server endpoint fails the validation; the client does not trust the certificate presented by the server. This article is a continuation of http://linqto.me/https.

       

 

 

A bit of context

 

On 2020 August 19th, the Azure SignalR Service rotated (renewed) the authenticating certificate used by its endpoints. The entire trust chain has changed.
In some situations, the ASRS clients or the hubs could no longer connect to the service, with an error like:

ERROR Failed to connect to 'https://resourceName.service.signalr.net', will retry after the back off period.
Error detail: Unable to connect to the remote server. The remote certificate is invalid according to the validation procedure. Id: <GUID-here>

Of course, the first thought is to check the certificate that the service is presenting.

During the TLS handshake, when the secure channel is established for HTTPS, before any HTTP traffic can take place, the server is presenting its certificate. The server has to authenticate itself. And the client is checking the certificate:

  1. Is the certificate still valid? Isn’t it expired?
  2. Is the certificate issued for the domain that the server claims to be? Does the Subject name in the certificate match the site name (host-name) of the endpoint URL?
  3. Does the client trust the certificate chain? Does it trust the issuing authority or the entity endorsing the certificate authority?
  4. Was the certificate revoked by its issuing authority?
  5. Do the cryptographic details match, key and algorithms?

Below, we treat a bit on the third question: trusting the certificate chain. We check certificate identifiers against the Windows certificate store.

       

 

 

Certificate chain

 

So what’s the certificate’s trust chain? Well, the certificate of a server is issued by an authority that checks somehow the authenticity of that server or service. We call it the Certificate Authority or Issuing Authority. That authority should be trusted. Or we should trust, at least, the authority that is endorsing the Issuing Authority, which we call Root Authority. Sometimes, this chain of certification may be even longer.

For a public HTTPS endpoint, we could use an online service to check its certificate. For my Azure SignalR Service instance, using the Ionos SSL Checker, I get the following chain:

 

A certificate trust chain, from the Root Authority down to authenticated serviceA certificate trust chain, from the Root Authority down to authenticated service

 

 

We can easily see the entire chain; each entity is identified with its own certificate. Reading from bottom up:

  1. The certificate of the service, used to authenticate to its clients
  2. The Issuing Authority, the one that signed and generated the service certificate
  3. The Root Authority, the one that is endorsing the Issuing Authority to release certificates

There are other SSL certificate test services too online, such as the one from SSLlabs.com. And we can also use a browser or even a network trace (such as with Wireshark) to see a certificate chain.

       

 

 

Identify the certificate

 

Certificates can be identified with several of their properties. But, to check them in the Windows certificate store easily, we could use:

  • Either the Serial number of the certificate,
  • Or its Thumbprint, which is the SHA-1 Fingerprint Hash computed from the certificate

The Serial number of the certificate is displayed by most of the SSL checking services. Illustrating with the output of the Ionos SSL Checker:

 

Viorel-Alexandru_1-1598543572196.png

 

Most of the browsers allow to see the certificate of an HTTPS site, along with the trust chain. Identifiers can be picked from there too. For instance, using Firefox:

 

Viorel-Alexandru_2-1598543572202.png

 

Viorel-Alexandru_3-1598543572205.png

 

Viorel-Alexandru_4-1598543572211.png

 

Viorel-Alexandru_5-1598543572216.png

 

Note: With certificates of Root Authority, the Issuer of the certificate is the authority itself; this is how we tell that this is a Root Authority certificate.

 

The certificate Thumprint is a computed Hash, SHA-1The certificate Thumprint is a computed Hash, SHA-1

 

 

Microsoft browsers, like Edge Chromium, are also displaying certificates in a window that is familiar from the Windows certificate store.
The trust chain can be navigated; we can see each certificate, for each entity in the chain, to check if they are OK:

 

Viorel-Alexandru_7-1598543572226.png

 

Certificate fields as shown by Windows UICertificate fields as shown by Windows UI

 

 

If we can’t use a browser or an online service – maybe because of an internal environment that prevents getting the presented certificate chain this way – we can use a network trace, such as one taken with Wireshark:
Let’s remember that, in TLS negotiation, after Client Hello and Server Hello, the server would present its certificate to authenticate itself to the client.
So, in a network trace, we see the certificates, each with its Serial Number and Issuer information:

 

A network trace with Wireshark reveals the server certificateA network trace with Wireshark reveals the server certificate

 

       

 

 

Checking certificate store

 

Now that we know the certificate chain, with the identifiers of the certificates, we should check if our client accessing the service trusts the chain.

Microsoft applications and frameworks would use the Microsoft cryptographic API (CAPI), and that includes Microsoft browsers. Other browsers or technologies may use other APIs or crypto libraries for validating certificates. But Windows relies on its certificate store. So, we need to check if an issuing authority or its endorsing authority is trusted: does its certificate appear in the certificate store, in the needed location?

 

Using certificates console

 

Using the UI, we open Manage Computer Certificate or Manage User Certificate, depending if the client is a service, like an IIS-hosted Web application, or a desktop application running under a user’s security context.

Opening the certificates console, we check the Trusted/Third-Party Root Certification Authorities or the Intermediate Certification Authorities.

 

The hash is used as certificate identifier; same certificate may appear in multiple storesThe hash is used as certificate identifier; same certificate may appear in multiple stores

 

 

If we can’t find a valid entity’s certificate there, then perhaps we should install it. Luckily, this is done simply opening and importing the CER file of an authority. In some cases, a PFX container file has inside certificates and keys; it is common that entire certificate chains are included in the PFX container – importing the PFX may install all the contained certificates, including those of issuing or endorsing authorities.

 

Using PowerShell

 

The Windows certificate repository is using the certificate computed SHA-1 Fingerprint/Hash, or Thumbprint, as certificate identifier. This can be seen when we look into the Registry location where Windows is persisting the certificates:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates

But the certificates can also be searched by their Serial Number. Look:

After opening a PowerShell console, go to the certificate repository root:

cd cert:\\

 

Recursively search for the certificate…

 
… either by its Serial Number:

Get-ChildItem -Recurse | Where-Object {$_.SerialNumber -eq "033af1e6a711a9a0bb2864b11d09fae5"}

 
... or by its computed Hash, or Thumbprint, used as Path (or item name) in the Windows certificate store:

Get-ChildItem -Path "df3c24f9bfd666761b268073fe06d1cc8d4f82a4" -Recurse

 

For example, I get:

   PSParentPath: Microsoft.PowerShell.Security\Certificate::CurrentUser\Root
Thumbprint                                Subject
DF3C24F9BFD666761B268073FE06D1CC8D4F82A4  CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
 
   PSParentPath: Microsoft.PowerShell.Security\Certificate::CurrentUser\AuthRoot
Thumbprint                                Subject
DF3C24F9BFD666761B268073FE06D1CC8D4F82A4  CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
 
   PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\Root
Thumbprint                                Subject
DF3C24F9BFD666761B268073FE06D1CC8D4F82A4  CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
 
   PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\AuthRoot
Thumbprint                                Subject
DF3C24F9BFD666761B268073FE06D1CC8D4F82A4  CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US

 

We could select a certain Store & Folder:

cd .\\LocalMachine\Root\

 

Get all the properties of a certificate from there, if you need to check other properties too:

Get-ChildItem -Path "df3c24f9bfd666761b268073fe06d1cc8d4f82a4" | Format-List -Property *

 

 

 

Aside: Just in case you are wondering what I use to capture screenshots for illustrating my articles, check out this little ShareX application in Windows Store.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.