Troubleshooting: SSL Certificate

This article will provide an introduction to the troubleshooting of SSL certificates. These tips are universal and can be used to troubleshoot many different AirWatch components that require SSL connections. These guidelines should be used whenever you see an SSL or TLS related error message in application logs and need to investigate and ensure that a certificate is valid and properly configured.

SSL Error Messages

SSL/TLS errors can potentially occur for any connection between two components that is encrypted using a standard SSL certificate. Below are some common error messages that may show in the logs of any AirWatch component due to SSL connection errors. Correctly identifying these errors can streamline the troubleshooting process.

* Could not establish trust relationship for the SSL/TLS secure channel 
* The remote certificate is invalid according to the validation procedure
* At least one security token in the message could not be validated
* The SSL certificate is signed by an unknown certificate authority

Basic Certificate Troubleshooting

Two main components are engaged when establishing an SSL connection: the client and the server. The client initiates the connection and is required to trust the SSL certificate configured on the server. In this section, troubleshooting will take place on the client computer, while trying to access the server computer.

If you see an SSL error in the logs for an AirWatch component, one of the best tools for initially troubleshooting the error is simply using the browser on the server that hosts the component. Using the browser, you can connect directly to the appropriate endpoint and confirm if any SSL/TLS errors are thrown. You may see a warning show in the browser window itself, but can also confirm a certificate error by identifying the red warning messages in the address bar, as shown in the images below for Internet Explorer and Google Chrome. Generally, Internet Explorer is recommended for SSL troubleshooting as the trust settings tie into the operating system of the server itself:

 image001.png

image002.png

 If the connection shows certificate errors similar to those seen here, you will want to take a look at the SSL certificate itself to determine the issue. You can do this by selecting the Certificate error shown in the address bar. Here you will be presented with a pop-up that briefly describes the issue, as well as an option to view the actual certificate.

 image003.png

After choosing View certificates, a new window containing the certificate information will appear. This window has three tabs: GeneralDetails, and Certification Path. The General tab contains basic information about the certificate, such as who the certificate was issued to, who it was issued by, as well as the validity dates of the certificate. If a certificate contains a private key, a message indicating this will also appear on this tab.

 image004.png

The Details tab contains, as the name suggests, more specific details about the certificate. In particular this section contains the certificate subject, any CRL distribution points, the subject alternative name contained in the certificate, as well as the certificate thumbprint itself. Some information from the General tab is also repeated here. Though this information is often useful for more advanced certificate troubleshooting, common issues can generally be resolved without focusing on this tab.

The Certificate Path tab shows any intermediate and root certificates that are needed for the full trust-chain of the certificate. Generally at the top of the chain will be a root certificate that the operating system intrinsically trusts, such as root certificate by Go Daddy or Entrust. Any certificates that are not trusted by the OS by default can still be installed on the server into a trusted store in order to ensure trust. If a certificate authority is trusted by the server, then any certificates issued by that authority will be trusted as well. Thus, when investigating certificate trust issues, it is important to validate that the entire certificate chain is trusted.

 image005.png  image006.png

In the event that an SSL certificate is not trusted, there are three common issues that can quickly be identified:

1) The validity period of the certificate has expired. The validity date of the certificate can be quickly verified on the General tab of the certificate. If the certificate is expired, then it will no longer be trusted, and a new certificate must be provided. If the certificate was issued from a third party source such as Go Daddy, then a new certificate will have to be generated. If the certificate was generated from an internal certificate authority, then in addition to generating a new certificate, any updated intermediate or root certificates may need to be installed as well. Note that these additional certificates will only need to be installed if the previous versions have been updated as well.

2) The full certification path is not trusted. This issue can be validated from the third tab of the certificate window. If any intermediate or root certificates are missing, they must be installed in the intermediate or root certificate store on the client server. In addition, you can select any certificates in the chain and choose to view them in more detail to confirm that there are no other issues present with any certificates on the chain. For non-standard or internal certificate authorities, the root certificate must be installed in the Trusted Root Certification Authorities store, and any intermediate certificates should be installed in the Intermediate Certification Authorities store.

3) The “Issued to” field does not match the host name used to access the server. SSL certificates are only valid if a client is connecting to the server using the specified hostname to which the certificate was issued. This is not the case for the error messages shown in the preceding images. In this example, the server is accessed using awmdm.com, but the certificate was actually issued to *.air-watch.com. In this case, for the certificate to be trusted, the certificate must be accessed using a hostname ending with “air-watch.com”. If the target server is unavailable via this specified hostname, then the network and DNS configuration must be further investigated. In some cases, generally when only internal servers are involved in the connection, a hosts file entry can be used to change the DNS name used to connect to the server.

Creating a Hosts File Entry

The hosts file is used to map hostnames to IP addresses, and can be used to override the default DNS mappings. The file can be found on the path C:\Windows\System32\drivers\etc\hosts, and when opened will look like the image below. In this example, an entry was added in the hosts file to map the hostname example.air-watch.com to the IP address 205.139.50.164. The effects of this change can be confirmed by testing a ping command before and after editing the hosts file.

 image007.png

To ping the server, open a command prompt and use the command ping -n 1 {hostname}. In this example the specific command is

ping -n 1 example.air-watch.com

If the hostname does not properly map anywhere, you will see the message:

Ping request could not find host example.air-watch.com.  Please check the name and try again.

Otherwise, you will see the ping result return with the IP address found for this hostname. If this hostname does not map to the correct IP address, a hosts file entry can be used to remap it. After editing and saving the hosts file, perform the same ping command again. You should now see the results show the updated IP address that is now being mapped. Now, whenever an application (including the browser itself) navigates to that hostname, it will attempt to connect to the specified server.

One final note is that some certificates are issues to a wildcard hostname, such as *.air-watch.com. In this case, the hosts file can be updated with any prefix as long as the formatting matches the certificate. However, only a single prefix can replace the wildcard character. For example, example.air-watch.com is a valid hostname for the certificate, but second.example.air-watch.com is not a valid hostname.

Installing Certificates

Microsoft Management Console (MMC) is recommended to be used in cases where a root or intermediate certificate (or even a client certificate in some cases) must be manually installed. To open this program, type mmc.exe from the run menu. When MMC is first opened, you will likely be presented with three empty panes, as shown below.image008.png

 MMC can utilize several different snap-ins to achieve various purposes. In this case, you'll need to add the Certificates snap-in to manage the various certificates installed on the server. To do this, navigate to File -> Add/Remove Snap-ins. You'll be presented with the window below. Choose the Certificates snap-in and then select Add.

 image009.png

You'll now be asked for which account should certificates be managed. In most cases, Computer account should be selected. This will ensure that the configuration will be valid for the entire computer rather than for specific users or services.

 image010.png

After selecting Next, ensure that Local computer is specified, and finally select Finish. At this point, you can choose OK to add the Certificates snap-in. At this point, the main MMC windows should look similar to the image below.

 image011.png

In the left hand pane you can view the various certificate stores that are available on the computer. In particular, Trusted Root Certification Authorities is where root certificates should be installed, and Intermediate Certification Authorities is where intermediate certificates should be installed. The Personal store can be used for other certificates that need to be manually installed. By expanding any particular store and selecting the Certificates folder, you can view the installed certificates under that store.

In order to install a certificate, right-click the Certificates folder, choose All Tasks and then Import. Next, browse to the certificate file on the server, and select it. In cases where the private key is included in the certificate file, the certificate password will also need to be confirmed prior to installing the certificate. Once the certificate is installed, you should be able to view it in the center pane in the MMC window.

Have more questions? Submit a request

0 Comments

Article is closed for comments.