SSL Certification expiration checks out of the box - Details?

[larry_roberts]

During Perform 2020, I believe it was stated that certificate expiration checks were in the works in terms of out of the box for Dynatrace if I heard it correctly. I believe it was just briefly mentioned without much detail.

We are actively moving more and more to GCP and would like to have such checks.

I know there is currently a plugin out there on GitHub by Julius Loman (thank you Julius!) to do such checks, however I have not yet tried it. Curious if because this is a plugin, if it consumes custom metrics? I am also not sure if this plugin will work in a GCP environment.

Before I do try the plugin approach, I was wondering if I am recalling that above information correctly?

If so, is there a timeline or more in depth details that will be coming soon around this functionality?

Thanks!

[Julius_Loman · Accepted solution]

Just my "two cents" about my plugin - it does not consume any metrics, so it's free also from Dynatrace license consumption. It only pushes events and metadata to processes.

At the moment it only verifies certificates on TCP ports on the host where OneAgent is running. I'll extend it to cover also client-side keystores for certificates (jks at this time, probably also pfx/p12 in the future).

I'm not aware of any plans of Dynatrace having the check functionality built-in.

[larry_roberts]

Thanks Julius! Appreciate the work on a plugin around this as well. I am 99% sure I heard something at Perform on stage specific to certificates expiring. Maybe I was hearing things which is very possible! lol.

[Julius_Loman]

Could be. Maybe @Jakub M. may bring some answers.

[andrew_franklor]

Julius - I love your approach of OneAgent plugin monitoring. I have webservers with 20+ IPs all apache instances listening to 443. GitHub readme lists the limitation: "Opened TCP port bindings are retrieved from OneAgent and only local TCP ports are checked. Listening IP address is provided by OneAgent. Currently OneAgent supplies 127.0.0.1 as the listening IP address regardless of the actual TCP port binding."

Does this mean that the plugin knows what process owns a port, and will show the right cert on the process group, but may show 127.0.0.1 as the IP? Or do you mean that for boxes with multiple IPs and processes binding to 1 IP, the plugin can not tell process has the port?

[Julius_Loman]

Actually.. it only shows 127.0.0.1 if the listening address is 0.0.0.0 (all interfaces). But if your service is listening on a particular IP, it will show the IP and the port.

So basically it looks like this:

This listening port information is provided by OneAgent.

[andrew_franklor]

Thanks for quick response, that looks great! We will give this a try, thanks for sharing!

[kedesai]

Hi Julius,

Is there a way to check for the keystores expiry dates? Can we filter which certs we want to monitor? 

Thanks,

Ketan

[Julius_Loman]

Hi @kedesai ,
I've been thinking about adding the possibility to monitor keystores, but I gave up. Unfortunately, it's not that easy to do it using Dynatrace OneAgent extension, because

• extensions run as unprivileged users, so there will be issues with accessing the keystore file which is typically owned by some application user
• many keystore types (JKS/CMS), require a JVM or a specific JVM (IBM JVM) to open them.
• you would need to configure the paths to the keystores anyway

I've decided not to implement this functionality.

[kedesai]

Hi Julius,

Thanks for your quick reply. How are you able to monitor the cert on google.com. Per the process, we have to put the zip in two locations. one is in the:
2.) Upload the zip file to your Dynatrace tenant in Settings > Monitoring > Monitored technologies > Custom plugins and choose Upload plugin.

The other one goes to the location in the plugin_deployment directory on the host.

3.) Unzip the zip file on OneAgents into /opt/dynatrace/oneagent/plugin_deployment directory on hosts with OneAgents or to appropriate plug_deployment directory if you have installed the agent into the non-default directory.

I have a specific case where I need to get an SSL cert expiry from a website but I am not able to get it. For example adt.com. I don't have access to VM :).

Thanks again,

Ketan

[larry_roberts]

Going to be giving this one a try along with the one provided by @Leon Van Z. as well today and through tomorrow. Excited to see what both can do. Both of your contributions are VERY MUCH APPRECIATED!

[alexandre_marl2]

It would be nice to have it out of the box !

Others competitor have it.

[larry_roberts]

I completely agree.

[leon_vanzyl · Accepted solution]

We have created an AG Plugin that checks Certs: https://github.com/mediro-ict/activegate_python_ssl_plugin

NOTE: the latest version uses metrics and therefore consumes DDUs.

[larry_roberts]

Good stuff @Leon Van Z. ! I will check that out. It might be exactly what we are looking for and save me some work at the same time 😉

Thank you!

[leon_vanzyl]

shot Larry!, let me know how We can improve it

[larry_roberts]

Going to be at long last trying this out today. I will let you know the results.

[leon_vanzyl]

cool, let me know

[m_wigman]

Nice plugin! I tested it on my dev tenant in Dynatrace Saas, which worked great. But at our customer's site we use an on-prem Dynatrace. Installation worked out fine, but when we try to open the SSL/TLS Certificates tile on the Dynatrace Technologies page, I get a 404 page (not found). The sub-call that actually returns the 404 is like https://<clustername>/e/<environment-id>/rest/processes/summary/new/processType/SSL%2FTLS%20Certificates?<variables>. Do you have any idea of what could be wrong? The 404 page showed environment version 1.236.119.20220321-160129, the activegate is version 1.235.186.

Any thoughts of what could cause this problem?

Thanks, Marcel

[irakli_natsvlis]

Hello everyone,

Do I understand correctly that plugins developed by @Julius L. @Leon Van Z. require deployment on both AGs and the host where OneAgent is installed and they can't be deployed on ActiveGates only?

Thanks

--

[MaciejNeumann · Accepted solution]

SSL certification expiration date verification is now available with HTTP monitors: