Problems with returning CRIT for https://api.ssllabs.com/api/v2/analyze api call

[tuxracer1337]

Hello,

we're struggling with the following code:

if [ "${CURL_RETURN_CODE}" -ne 0 ]; then
  debuglog "curl returned ${CURL_RETURN_CODE}: ${CURL_BIN} ${CURL_PROXY} ${CURL_PROXY_ARGUMENT} ${INETPROTO} --silent \"https://api.ssllabs.com/api/v2/analyze?host=${HOST_NAME}${IGNORE_SSL_LABS_CACHE}\""
  critical "Error checking SSL Labs: curl returned ${CURL_RETURN_CODE}, see 'man curl' for details"
fi

As the check is being marked as CRITICAL, the alerted department suspects an issue with the certificate. However, there is no issue with the certificate. The SSLLABS API is taking too long to respond.

It would be much more logical for us to receive an UNKNOWEN error for code issues that are not related to the monitored service.

Is it possible to reconsider this section of the code and potentially produce a less confusing response?

Best regards,
Andreas

[matteocorti]

Dear Andreas, I see the point. On the other hand one could argue that if a given rank is required, not having the result could be interpreted as critical.

According to the plugin development guidelines:

Invalid command line arguments were supplied to the plugin or low-level failures internal to the plugin (such as unable to fork, or open a tcp socket) that prevent it from performing the specified operation. Higher-level errors (such as name resolution errors, socket timeouts, etc) are outside of the control of plugins and should generally NOT be reported as UNKNOWN states.

I would rather add a command line option to ignore SSL Labs problems...

[matteocorti]

I added --ignore-ssl-labs-errors so that you can have the desired behaviour and the plugin will stay compliant with the guidelines.