check_http odd behavior

[lcroce]

I can't open a web browser because I don't install a GUI on my linux servers unless I absolutely need to run an X server environment. That said, the curl behavior should be enough of an analogue to using a web browser. As to what this particular example is, yes, it does land on an authentication URL, specifically an HTTP basic auth.

As I mentioned before though, unless there's some kind of bug in the CentOS 7 version of Curl or Openssl, I don't see why the two servers would behave differently, especially when I migrated the old server's IP to the new server so IP based exclusions for authentication aren't an issue here and neither the check command in Nagios nor curl were provided with basic auth credentials in their commands and they behave differently on the old server vs the new server.

[scottwilkerson]

what is the output if you run curl http://10.0.10.1:4433 -v?

See below.

Code: Select all

curl https://10.0.10.1:4433 --insecure -vvv
* About to connect() to 10.0.10.1 port 4433 (#0)
*   Trying 10.0.10.1...
* Connected to 10.0.10.1 (10.0.10.1) port 4433 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
* Server certificate:
*       subject: CN=<content removed>
*       start date: Mar 04 00:00:00 2016 GMT
*       expire date: Jun 03 23:59:59 2019 GMT
*       common name: <content removed>
*       issuer: CN=RapidSSL SHA256 CA - G2,O=GeoTrust Inc.,C=US
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 10.0.10.1:4433
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Type: text/html; charset=utf-8
< Proxy-Connection: Keep-Alive
< Connection: Keep-Alive
< Content-Length: 727
<

<content removed>

* Connection #0 to host 10.0.10.1 left intact

Seeing this:

Code: Select all

< HTTP/1.1 400 Bad Request

Tells me that it is a problem with the server you are connecting to or curl on this machine

A 400 Bad Request Error indicates that the server (remote computer) is unable (or refuses) to process the request sent by the client (web browser), due to an issue that is perceived by the server to be a client problem. ... If an expected custom HTTP header is missing or invalid, a 400 Bad Request Error is a likely result

I would run the same command on the new server and see where they differ. Maybe the new server needs a certificate installed

[lcroce]

That output from earlier was from the new server. The old server returns a 302 redirect. Also, the cert is public so shouldn't require a CA install.

EDIT: So it occurred to me today to use another CentOS 7 server to test curl to rule out a curl or openssl version issue, which I did. Running curl on a different server, same curl and openssl version, works as expected.

[dwhitfield]

So it occurred to me today to use another CentOS 7 server to test curl to rule out a curl or openssl version issue, which I did. Running curl on a different server, same curl and openssl version, works as expected.

For clarity, you're saying two CentOS 7 servers with the same version of openssl and curl behave differently, correct? Did you test check_http on the second server? If so, what result?

[lcroce]

Same plugin version and returns a 302 Found on the other server. At this point, I've given up on using check_http to check SSL certificates and have migrated my checks to check_ssl_certificate from the Nagios Exchange as it works.

[dwhitfield]

It sounds like this issue has been resolved. Is it okay if we lock this thread? Thanks for choosing the Nagios forums!

[lcroce]

It sounds like this issue has been resolved. Is it okay if we lock this thread? Thanks for choosing the Nagios forums!

Yeah, go ahead. Thanks for the help.