Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

Workaround for failing 6.5 URL Monitor due to Unsupported SSL SHA1 Encryption

Dynatrace Advisor
Dynatrace Advisor

My client migrated from 6.2 -> 6.5, but the URL Monitors hitting "https" sites (VIPs) are no longer working. I have tried to turn on and off the "disable ssl cert validation" option, but this does not fix the problem. The sites use SHA-1 encryption which is getting phased out by Google and Microsoft next year.

Is there any way to force the collector to accept SHA-1 encrypted connections over https?

The error reads:

"Connection failed: DynaTraceHttpClientException: Exception was thrown while executing a HTTP request
Caused by: SSLException: Unsupported record version SSLv2Hello
SSL handshake failed, this may be caused by an incorrect certificate. Check 'Disable certificate validation' parameter to override this."

It seems to be similar to the reported case: SUPDT-20709, which describes how the 6.3 collector using the Java 8 JRE no longer supports older encryption algorithms. SHA-1 is getting phased out next year, and I think that this is the reason for which the 6.5 collectors (also using JRE 😎 are unable to hit the SSL sites.

Like the support team suggests, How would a proxy server be used as a workaround?

Any insight or workaround for this issue is welcomed, as it may prevent my client from migrating to 6.5 until they can upgrade all the SSL certs to SHA-2 encryption.




Dynatrace Leader
Dynatrace Leader

What about setting up a 6.3 Collector just for the purposes of running your URL Monitor? Not a long term solution, but might give you a workaround the the interim.

Hey Joseph,

That is a great idea. I will try it out to make sure it works. Also, I am going to try importing their certificate into the collector keystore to see if that works too.

Thank You,


Hi Joseph,

Executing the URL monitor with a 6.2 collector on a completely separate VM, which is connected to a 6.5 server, will not work. The URL monitor plugin execution fails. I believe it fails because it is trying to invoke the 6.5 version of the URL plugin, and causes a null pointer exception.

Is there a way to prevent the collector from installing the 6.5version of the URL plugin from the DT Server?



Ah, bummer. I assume you're using the URL Monitoring Plugin that comes with the product. Here's two ideas worth exploring:

1) Extract the URL Monitoring plugin from the 6.5 system, modify the name a bit so it's a new plugin, then import it back into 6.5. I'm not convinced this will work but it's worth a try.

2) Use the community version of the URL Monitor and using the same logic as above, have a different plugin just for the 6.2 Collector.

3) Following idea #1, edit the plugin and make necessary changes so it will accept the connection situation you're dealing with. This again would mean the plugin would have to be renamed so as not to collide with the out-of-the-box URL Monitoring plugin.

Let us know your progress.

joe hoffman

Dynatrace Advisor
Dynatrace Advisor

Hey Joe,

Here is the solution that seems to work for Windows Collectors:

  • Install separate 6.2 Collector instance on a separate "DT HOME" path from the 6.5 collector.
  • Allow the 6.2 collector to use the provided JRE 7
  • Change the agent listen port on the 6.2 collector to avoid port contention.
  • Export the 6.5 URL monitor from the Plugins tab in Server Settings.
  • Install the URL Monitor from 6.2, in the client. The 6.5 client will ask if you do want to downgrade the 6.5 URL monitor to the 6.2 monitor plugin. Choose yes, and the client installs it. (This will force all URL monitors to use an older version of the plugin).
    • Even after renaming the jar of the 6.2 URL Monitor plugin, the DT server still recognized it's ID and asked to replace the 6.5 URL monitor.
  • Schedule the URL monitor to execute on the 6.2 collector.

I will need to get feedback from my client about using the 6.2 version of the URL plugin for all monitors, but this workaround seems sufficient.