Repository navigation
mod_md: Log the specific reason an ACME request failed, not just "(specific information not available)". - #1031
Open
arturobernalg wants to merge 1 commit into
Conversation
…ecific information not available)". md_curl_perform() logged the actual curl_easy_strerror() for a failed request -- e.g. "Problem with the SSL CA cert (path? access rights?)" for a bad or missing MDCACertificateFile -- only at MD_LOG_DEBUG. Every higher-level caller only has the apr_status_t this maps to, which for any curl error without its own case in curl_status() is the generic APR_EGENERAL, rendered as "(specific information not available)" in the AH10056 error an administrator actually sees. The one specific, actionable detail of what went wrong was only visible with md:trace4. Raise this to MD_LOG_ERR specifically for curl error codes that indicate a problem with the TLS trust configuration itself (bad CA bundle, certificate, cipher, engine) rather than a transient network condition, since these will not be fixed by mod_md's usual retry. Other failures (DNS, connection refused, timeout, ...) keep logging at debug, as those are already expected to retry and their apr_status_t mapping (APR_ECONNREFUSED, APR_TIMEUP, ...) is already descriptive. Reproduced against a real server: pointed MDCACertificateFile at a nonexistent file and MDCertificateAuthority at a local HTTPS listener. Before the fix, "LogLevel md:warn" showed only the generic AH10056 "(specific information not available)" line. After, it also shows "request failed(77): Problem with the SSL CA cert (path? access rights?)" at md:error. PR 70300 (cherry picked from commit 45e499d3cc19d539a73958c3e408aa9e5f5a3aca)
arturobernalg
force-pushed
the
fix/bz70300-md-curl-ca-cert-error-level
branch
from
November 14, 2026 14:22
75df448 to
7b8633d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
md_curl_perform() logged the actual curl_easy_strerror() for a failed request -- e.g. "Problem with the SSL CA cert (path? access rights?)" for a bad or missing MDCACertificateFile -- only at MD_LOG_DEBUG. Every higher-level caller only has the apr_status_t this maps to, which for any curl error without its own case in curl_status() is the generic APR_EGENERAL, rendered as "(specific information not available)" in the AH10056 error an administrator actually sees. The one specific, actionable detail of what went wrong was only visible with md:trace4.
Raise this to MD_LOG_ERR specifically for curl error codes that indicate a problem with the TLS trust configuration itself (bad CA bundle, certificate, cipher, engine) rather than a transient network condition, since these will not be fixed by mod_md's usual retry. Other failures (DNS, connection refused, timeout, ...) keep logging at debug, as those are already expected to retry and their apr_status_t mapping (APR_ECONNREFUSED, APR_TIMEUP, ...) is already descriptive.
Reproduced against a real server: pointed MDCACertificateFile at a nonexistent file and MDCertificateAuthority at a local HTTPS listener. Before the fix, "LogLevel md:warn" showed only the generic AH10056 "(specific information not available)" line. After, it also shows "request failed(77): Problem with the SSL CA cert (path? access rights?)" at md:error. RED/GREEN verified with a new pytest (no real ACME server needed, since a bad CA file fails before any ACME-specific request).
PR 70300
[x] This PR does not report or address a security vulnerability (see SECURITY.md and https://www.apache.org/security/#reporting-a-vulnerability).
[x] Code follows the httpd style guide.
[x] New log messages (level debug or higher) use an empty APLOGNO() tag (not applicable -- mod_md's own md_log_perror() does not use the APLOGNO tagging convention).
[x] If the change is user-visible, a changes-entries/*.txt file is included.
[x] Test cases based on pyhttpd are included where appropriate (test/modules/md/test_320_ca_cert_log_level.py, RED/GREEN verified; does not require a real ACME test server).