Drupal 10.x Outbound HTTP SSL Verification Requires Trusted CA Bundle

Direct Recommendation

Add a UI-driven option, but restrict it to per-service configuration rather than a global toggle. Each outbound service integration (remote aggregator, OAuth provider, custom HTTP client) should declare its own verification policy, and the administration interface should only allow relaxation for explicitly registered endpoints.

Why Per-Service Scoping Is Required

Drupal 10.x uses Guzzle with verify => true by default for all outbound HTTPS requests. The existing override $settings['http_client_config']['verify'] in settings.php applies globally, which is why a UI toggle must not replicate that behavior. A global disable would affect payment gateways, OAuth providers, and any other Guzzle-based call, exposing credentials and transaction data to man-in-the-middle attacks.

Confirmed fact: The HTTP client factory in \Drupal\Core\Http\ClientFactory reads $settings['http_client_config'] and merges it into every client instance. There is no built-in mechanism to vary verification per endpoint.

Proposed Scope Limitation

1. Service registration: Modules that make outbound requests should declare a service identifier (e.g., my_module.oauth_provider, aggregator.feed_1) via a http_client_options alter hook or a new HttpClientConfigInterface.
2. Configuration storage: Store verification policy in configuration entities keyed by service ID (http_client_config.my_module.oauth_provider.verify). This keeps the setting out of settings.php and under configuration management.
3. Client instantiation: When ClientFactory::fromOptions() builds a client for a specific service, it merges the service-specific config after the global settings.php values, allowing a targeted verify => false or a custom CA bundle path without affecting other clients.

Required Safeguards and Warnings

• Permission gate: Require the administer site configuration permission (or a new dedicated permission configure http client ssl) to change verification settings.
• Prominent warning banner: Display a non-dismissible alert on the configuration form: "Disabling SSL verification for this service exposes all data sent to <endpoint> to interception. Only use for internal services with self-signed certificates where a proper CA bundle cannot be deployed."
• Host allow-list validation: When an administrator enters verify => false, require an explicit hostname or CIDR pattern (e.g., internal-api.example.com, 10.0.0.0/8). Reject bare false without a scope.
• Audit logging: Write a watchdog entry (severity warning) every time verification is disabled for a service, including the user ID, service ID, timestamp, and allowed host pattern.
• Expiration/re-prompt: Add an optional verification_expires timestamp (default 90 days). When expired, the UI shows a re-confirmation prompt and logs a notice.

Implementation Outline

// In a module's http_client_options.alter.yml or a new EventSubscriber
function mymodule_http_client_options_alter(array &$options, string $service_id): void {
  $config = \Drupal::config('http_client_config.' . $service_id);
  if ($config->get('verify') === false) {
    $allowed_hosts = $config->get('allowed_hosts');
    $options['verify'] = function ($host) use ($allowed_hosts) {
      return !_mymodule_host_matches($host, $allowed_hosts);
    };
    // Log the override
    \Drupal::logger('http_client_ssl')->warning('SSL verification disabled for @service (hosts: @hosts)', [
      '@service' => $service_id,
      '@hosts' => implode(', ', $allowed_hosts),
    ]);
  }
  elseif ($ca_bundle = $config->get('ca_bundle')) {
    $options['verify'] = $ca_bundle;
  }
}

One Missing Diagnostic Detail

Does your site already use a custom ClientFactory decorator or a contributed module (e.g., http_client_manager) that intercepts client creation? If yes, the per-service merge point may already exist and the UI can hook into it directly. If not, a core patch or a small contrib module introducing HttpClientConfigInterface is the cleanest path.