If running the diagnostics for the Brightmetrics Agents results in an error about SSL connectivity, there is usually one of two problems it could be.
The first is if the server is running Windows Server 2003 and does not have the latest windows updates enabling support for SHA2 SSL certificates. If your server is running Windows Server 2003, you can test its SHA2 support by visiting https://webapp.brightmetrics.com/ using IE on the server. Since IE uses the same windows HTTPS support as the Brightmetrics agent, it is a representative test (Chrome or Firefox would not be as they have their own internal HTTPS support). If you are able to see the login page, the system has SHA2 support. If you get a communications error like "Internet Explorer cannot display the webpage", it probably lacks SHA2 support. If you can not install all current windows security updates for some reason, you can install just Microsoft security update 2868626.
The second problem may be that a proxy or content filter is in use that is intercepting the HTTPS connection and re-encrypting it with its own certificate authority (CA). Often an Active Directory Group Policy will push the content filter's CA into each user's profile as a trusted root CA, but a corresponding computer policy to push the content filter's CA into each computer's trusted root CA has not been established, and therefore any services running in the server are not able to establish trust.
This problem can also be identified using IE on the server. Again visit https://webapp.brightmetrics.com/ using IE, and observe the security information next to the address bar. First, you should see the green address bar indicating an Extended Verification (EV) SSL certificate is in use. If you see only the lock icon, that is the first clue that the SSL certificate is being replaced. To verify, click on the security icon and select "View certificates":
In the certificate dialog box, click "Certification Path" and ensure that the certificate chains up to the "Go Daddy Class 2 Certification Authority" as shown below:
If it does not, if it chains up instead to a root CA that looks like it may be from your content filter, that is probably the problem being described.
The proper solution is really for the IT staff to ensure that the content filter's CA is a trusted root CA on all computers in the organization, just as it is for all users in the organization. However, if a quicker solution is necessary, the certificate can be exported from here and imported into the computer's trusted root CA list.
To do that, click "View Certificate" with the root CA highlighted, as shown above. In that dialog box, click the "Details" tab and click "Copy to file". Follow the wizard dialog to export the certificate, in DER format, to a file on your desktop.
Next, from the Start menu click Run and enter "mmc":
In the mmc application, choose File then Add/Remove Snap-in:
From the available span-ins list, choose Certificates and click Add:
When it asks which account to manage certificates for, choose "Computer account", and then "Local Computer":
Click "Okay" to close the dialog.
Now back in the mmc application, under Certificates, right-click "Trusted Root Certification Authorities", choose "All Tasks", and then "Import...":
Follow the wizard dialog to select and import the file exported to the desktop previously. Make sure the "Certificate store" that the certificate is being imported into is the "Trusted Root Certification Authorities" store:
That is all. Now the Brightmetrics agent, and any other services running locally on the server, should be able to trust SSL certificates created by your content filter.
Didn’t find what you’re looking for, or have questions about what you read? Email us at support@brightmetrics.com.
Comments
Please sign in to leave a comment.