Forum

I just added a new host to our monitor server and am getting some connection errors I don't understand. The host is reverse-proxied behind Hiawatha; Hiawatha is using a Let's Encrypt cert for that host. Hiawatha is configured to require TLS, and I set up the webserver in Monitor's CMS to use TLS/443. The error is from the monitor/database/fetch_webserver_logs cron job:

PHP Warning:  stream_socket_enable_crypto(): Peer certificate CN=`redacted host name' did not match expected CN=`redacted IP address' in /var/www/monitor/libraries/http.php on line 274

It looks like http.php is expecting an IP address, but gets a hostname and fails? There's nothing in /var/log/hiawatha/*.log or /var/www/monitor/logfiles/*.log that matches this host, and I'm not sure what else I might be able to do to track down the issue. Let me know if you need something else, please and thanks!

If you make the Monitor connect to that webserver without TLS, does it work then?

It does. I'm planning to have multiple virtual hosts at this IP. Does Monitor discover all the virtual hosts on a server when you set up a webserver? Is there a workaround that'll let Monitor connect with TLS?

Yes, information about all virtual hosts will be collected by the Monitor.

I haven't had this issue before. So, I don't know what goes wrong at your machine. What you can try is make a self-signed certificate for the hostname (CN) 'monitor'. That's what the fetch_webserver_logs script uses for the HTTP Host header in the request.

Oh, it's not the monitor certificate that's causing the error; it's the monitored host. The monitor server is using a Let's Encrypt cert as well, and it's been working just fine.

Indeed. It's the certificate at the webserver that is being monitored and where the Monitor connects to, which is causing this issue.

Right now the Monitor host does have a certificate that shows "Common Name (CN) monitor.<domain>.<tld>". Are you suggesting I create an additional, self-signed certificate with just the short hostname? Can you explain how that will affect the CN the monitored host sends back to the Monitor server (which also shows the FQDN as CN, and which seems to be the source of the error)? I want to make sure I understand how this would solve the problem. Thanks!

The error message from your first post says something about 'redacted host name not matching redacted IP address'. Does monitor.<domain>.<tld> resolve to the IP address the fetch_webserver_logs script connects to? (the one you specified via the Monitor web interface)

Yes, all hosts involved resolve DNS correctly.

I think I may need to clarify, Hugo: In the OP, the hostname and IP I'm referring to are the monitored host (set in the Monitor CMS as a webserver), not the Monitor server. When Monitor tries to fetch those logs, Monitor's cron daemon emails the referenced error to me.

Yes, I understand your situation. But for some reason, the fetch script connects to a webserver of which the hostname in its certificate does not resolve to the IP address it connects to. I have no idea why that is.