V
Viorel-Alexandru
Guest
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 About HTTPS, SChannel, TLS, CAPI, SSL Certificates and their keys - Microsoft Tech Community - 815200.
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:
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 service
We can easily see the entire chain; each entity is identified with its own certificate. Reading from bottom up:
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:
The Serial number of the certificate is displayed by most of the SSL checking services. Illustrating with the output of the Ionos SSL Checker:
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:
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-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:
Certificate 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 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 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.
Continue reading...
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:
- Is the certificate still valid? Isn’t it expired?
- 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?
- Does the client trust the certificate chain? Does it trust the issuing authority or the entity endorsing the certificate authority?
- Was the certificate revoked by its issuing authority?
- 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 serviceWe can easily see the entire chain; each entity is identified with its own certificate. Reading from bottom up:
- The certificate of the service, used to authenticate to its clients
- The Issuing Authority, the one that signed and generated the service certificate
- 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:
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:
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-1Microsoft 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:
Certificate fields as shown by Windows UIIf 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 certificateChecking 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 storesIf 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.
Continue reading...