SSL Expiry Sensor

Thanks Felix, the sensor works like a charm!

Hi,

We tried the SSLCertExpiration.exe from PRTGToolsFamily but we still have the same issue.

The webserver uses TLS 1.2 with 128 bits encryption using AES_128_CGM och ECDHE_RSA.

Errorlog:

[Probe]
2015-02-04 13:58:10
Microsoft Windows Server 2012 R2 Standard 6.2.9200.0 en-US
[Sensor]
SSLCertExpiration 15.1.1
Run by PRTG probe.
[Parameters]
-u=https://**.**.** -t=60 -tls -debug=C:\ProgramData\Paessler\PRTG Network Monitor\Logs (Sensors)\Result of Sensor 13745.txt 
[Trace]
[Error]
The underlying connection was closed: An unexpected error occurred on a send.
Exitcode custom_error

Best Regards, Robin

Hi,

Could you please forward the name of the site you are trying to monitor via email to [email protected] so that we are able to test the sensor for your certificate.

Best regards

Hi,

Has the new version of the sensor been released in version 15.1.13.1382?

Regards Emma

Hi Emma,

The sensor is currently tested by our QA-Team, please use the sensor linked above until the testing is finished.

Best regards

Felix Saure [Paessler Support], I sent the URL to the site to [email protected] last friday.

Best Regard, Robin

The download link above now gives a 404 error. Is this fixed sensor part of a recent release?

I just updated the link and it should work again.

Best regards

Is it possible to to have different states depending on the amount of days? For example less then 30 days is warning less then 10 days is critical.

Hi Minipat,

You can click on the Days to Expiration and enable the limits at the bottom of the page. Here you can define thresholds to set the sensor in warning or error state.

Best regards, Felix

Thank you so much Felix!

FYI - We've had SSL 2 & 3 disabled for a while, as well as a number of other optimizations to harden SSL. RC4 runed off, etc (We get an A rating from SSL Labs).

When we disabled TLS1.0 of some of our servers, we started to get this "An unexpected error occurred on a send" message. Turned TLS1.0 back on, problem went away.

This sensor does not work if TLS 1.0 is turned off on the server being monitored. Can you guys please fix this bug? TLS 1.0 is now required to be turned off in many certification reports.

"TLS v1.0 violates PCI DSS and is considered an automatic failing condition."

Hi Today,

The sensor supports TLS 1.2, any chance that you are still using the old sensor? Please try to add a new "Certificate Expiry Sensors", does it work? If not, what error message is displayed?

Best regards, Felix

Confirmed that this sensor does not work when TLS 1.0 is disabled. The message "The underlying connection was closed.." is returned when run from the command prompt when testing against a server I just disabled TLS 1.0 on (TLS 1.1 and 1.2 are still enabled which is confirmed by chrome developer tools from my browser when connecting via HTTPS and further confirmed by https://www.ssllabs.com/ssltest/). It was working perfectly fine prior to the change and continues to work on other servers where TLS1.0 is still enabled.

I further tested by doing a netsh trace. A network capture shows the application making two attempts to complete a SSL handshake using TLS1.0 and then giving up instead of negotiating for TLS 1.1 or 1.2.

Support, you say that the sensor supports TLS 1.2 but I think you're mistaken. I would be happy to cooperate with someone from your side to get this resolved as we monitor many SSLs and the alternate SSL sensor in PRTG is not suitable (we do not create a separate site for every single SSL we monitor because we use this sensor to quickly identify which server the SSL resides on).

If anyone else has a custom python/vbscript/exe that plugs into PRTG sensor library, I'm confident others in the community would be eternally grateful, especially as migrating away from early TLS implementations becomes a higher priority (i.e. PCI Data Security Standard 3.1)

Thanks

Dear Abolduc,

The old SSL Expiry sensor is deprecated and will not be updated anymore. The new PRTG sensor supports TLS 1.2 natively. You're right that it requires one device for every SSL check, this is by design and cannot be changed, sorry.

Best regards, Felix