Getting exception errors in communicating to Slack webhook from on-prem hosted Appmon server.
I believe that we have the proper certificate files in place, but I cannot find a way to get better debug information as to which cert may be a problem. Of note, we have some self-signed certs to do some DLP scanning, and it may be one of those causing the problem.
2017-12-18 09:19:33 SEVERE [SlackChat@com.Slack.Chat.action] Exception thrown whilst getting output stream...
2017-12-18 09:19:33 SEVERE [SlackChat@com.Slack.Chat.action] javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Did you try to set the Log Level to Finer for the Slack Plugin? i.e.:
You need to go to Settings -> Dynatrace Servers -> Plugins and double click on the Slack Plugin line to open this window.
Let me know,
Patrick, did you ever got this resolved?
I have client who's running into the same javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException error with the Slack plugin. We suspect it has to do their proxy/firewall certificates, but I'm not sure how to resolve this, or where in AppMon to place their root certificate.
In my experience the plugins are usually happen when you place the cert in the <dt_home>/jdk/lib/security/cacerts keystore (or some path like that), especially when you can't manually specify the path in a plugin. This would be on the appmon server itself if we're talking about an incident action plugin (for monitors it would need to be on each collector you want to run the monitor from). One would need to restart the server for it to take effect I believe.
Changing the plugin to accept all certs including self signed would work but keep in mind you would then never be 100% certain that the destination you're sending the data to is who it says it is so consider your environment and what you'll be sending when determining if that is an acceptable risk. The validation is there for a reason of course.
@James K. thanks for the info on the jre/lib/security/cacerts file, that's the file I couldn't put my finger on. In my case, on the DT Server yes, since this is an action plugin.
I agree, simply accepting a cert is not the best way to handle this, hence I'd use/suggest that as an absolute last resort, after explaining the risks to the client. They'll need to weigh up the pros and cons and decide the way forward.
I've seen this caused by self-signed certs in the past. We could adjust the plugin to accept any SSL certs. Is this something that would be useful?
If not, please respond here and I'll put it on my backlog.