Settings and activity
17 results found
-
7 votes
Billy Cole
shared this idea
·
An error occurred while saving the comment -
11 votes
Billy Cole
supported this idea
·
-
4 votes
Billy Cole
supported this idea
·
-
5 votes
Billy Cole
supported this idea
·
-
4 votes
Billy Cole
supported this idea
·
-
9 votes
Billy Cole
supported this idea
·
-
15 votes
Billy Cole
supported this idea
·
-
24 votes
Billy Cole
supported this idea
·
-
7 votes
Billy Cole
supported this idea
·
-
11 votes
Billy Cole
supported this idea
·
-
8 votes
Billy Cole
supported this idea
·
-
3 votes
Billy Cole
shared this idea
·
-
13 votes
Billy Cole
supported this idea
·
-
15 votes
Billy Cole
supported this idea
·
-
21 votes
Billy Cole
supported this idea
·
-
6 votes
An error occurred while saving the comment
Billy Cole
commented
Since auto-discovery or even post creation of a port sensor, could attempt to use openssl to get the SSL certificate of the port, be able to create a SSL Certificate sensor for the auto-discovery open port or for post created port sensors.
Billy Cole
supported this idea
·
-
6 votes
Billy Cole
supported this idea
·
The nature of using openssl to extract the expiry date is fairly straight forward, the problem becomes when the certificate is within a protocol handshake, like SNMP, SQL Server 1433, or within a java keystore, or MS keystore.
Instead of going after the certificate directly, provide a way to store the certificate on the PRTG core servers, then have a sensor monitor it from there.
If you want to be very helpful, provide a utility that can be scheduled to go extract the certificate from a web port, or key store, or from a server directory and copy it to the core servers' certificate store.
This would open up a vast array of certificate monitoring options and would be more performant than querying for the certificate.
On the sensor, also provide documentation on adding threshold triggers for 60,30, and 7 days left till expiry.