Nagios HTTPS monitoring: practical checks with check_http and check_curl

By Greg Nowak. Updated 9 October 2026.

A green Nagios dashboard should give you confidence that customers can reach your service. An open port 443 proves much less: the server could still present the wrong certificate, redirect visitors somewhere unexpected or serve an error page.

For a business owner, operations lead or agency team, start with one question: which customer problem should this check catch? That answer determines the endpoint, expected response and person who receives the alert. The commands below are templates for turning those decisions into useful HTTPS monitoring.

Choose checks that lead to a clear action

Separate checks when their failures need different responses. An approaching certificate expiry belongs in a renewal workflow; an unavailable customer portal may need immediate attention.

A working login page does not establish that login works. Add browser or transaction monitoring for important journeys involving JavaScript, authentication or several steps.

Check your installed plugin before changing definitions

The Monitoring Plugins check_http manual marks that project's plugin as deprecated and recommends migrating to check_curl. Check which implementation and package you actually run; this statement should not be applied indiscriminately to every similarly named plugin.

/usr/local/nagios/libexec/check_curl --version
/usr/local/nagios/libexec/check_curl --help

Adjust the path to your installation. The online manuals currently describe a development build, so local help matters. Confirm supported options before copying examples into Nagios command definitions.

Start with content and verified HTTPS

For a page that should respond directly, use:

/usr/local/nagios/libexec/check_curl -H example.com -u / --ssl -D --onredirect=critical --string 'Example Domain' -w 5 -c 10 -t 15

This requests HTTPS, enables certificate and hostname verification with -D, rejects redirects and looks for the expected content. The -w, -c and -t values are warning, critical and timeout thresholds in seconds. The check_curl manual documents these options.

Replace the hostname, marker and thresholds. Choose a marker specific enough to distinguish the intended page from a generic error response. Base timing thresholds on normal service behaviour and business expectations; these timings describe the monitoring request, not a browser's complete page load.

Give application health a stable contract

Homepages change with campaigns and redesigns. A maintained health endpoint gives developers and operations a more predictable agreement:

/usr/local/nagios/libexec/check_curl -H example.com -u /health --ssl -D --onredirect=critical --string 'application-health:ok' -w 3 -c 8 -t 12

The marker is illustrative; your application must return it. Agree which dependencies the endpoint checks. A static response can remain green during a database failure, while testing every optional supplier can turn a minor integration problem into an outage alert.

Include dependencies essential to the monitored service, keep public diagnostic details minimal and make endpoint changes part of the deployment review. Fixed text is usually easiest to maintain; -r and -R provide regular-expression matching when necessary.

Monitor certificate expiry separately from page availability

Give renewal warnings their own service definition and owner:

/usr/local/nagios/libexec/check_curl -H example.com -C 21,7 -D

This requests a warning below 21 days remaining and a critical result below seven. Adjust those windows to your renewal process. Use this alongside the verified public-page check: expiry and successful customer access answer different questions.

check_curl does not enable certificate trust and hostname verification by default; explicitly retain -D. With -C, the plugin normally stops before evaluating the page. Use --continue-after-certificate only when deliberately combining expiry and HTTP checks, and test the combined behaviour locally.

For a private certificate authority, configure trusted CA material rather than disabling verification. The plugin offers --ca-cert. The curl TLS verification guide explains trust stores, but standalone curl and check_curl have different options and defaults.

Make redirects and origin checks deliberate

If an entry URL should redirect, use --onredirect=curl to follow it with libcurl and check the final content. Following a redirect successfully does not establish that its destination is the approved hostname. Add a dedicated destination assertion when that matters.

For a DNS cutover or CDN investigation, contact a particular origin while keeping the production hostname:

/usr/local/nagios/libexec/check_curl -H example.com -I 203.0.113.10 -u /login --ssl -D --onredirect=critical --string 'Sign in' -w 5 -c 10 -t 15

Replace the documentation address with your origin address. Keep the public check too: this diagnostic view bypasses normal DNS selection and may bypass the CDN. Confirm proxy settings and firewall access before blaming the application.

Migrate check_http by testing failures, too

Inventory existing definitions, then run replacements as the Nagios service account on the actual monitoring host. Compare status, output, timing, redirects and proxy behaviour before switching notifications.

In a controlled environment, try a missing marker, an unexpected redirect and an untrusted certificate. Confirm that each produces the intended alert, then check recovery. Move definitions in batches and retain the previous configuration for rollback.

For a quick log review, this command remains useful:

grep -Ei 'critical|invalid|warning' logfile.log

Review notification timing as well. Nagios soft and hard states distinguish initial failures from confirmed problems. Check max_check_attempts and retry intervals: retries reduce transient alerts but delay notification.

Make the handover as useful as the check

Record the business purpose, responder and first investigation step for each service. Agency handovers should explicitly assign certificate renewal, out-of-hours cover and responsibility after hosting changes.

If inherited checks are difficult to trust, Greg can help review the definitions, plan the migration and clarify ownership. Talk to Greg about your monitoring setup.

Related on GrN.dk

• Browser Automation for Operations and Agency Teams: What Should You Automate?
• Cloudflare BYOIP customers need a rollback plan, not just trust
• A stray Set-Cookie can waste your CDN: audit the cache at the edge

Need help with this kind of work?

Talk to Greg about your monitoring setup Get in touch with Greg.

Sources

• Monitoring Plugins: check_http manual
• Monitoring Plugins: check_curl manual
• curl: TLS Certificate Verification
• Nagios Core: State Types