Problem: Resolving OX-Connector SOAP Connection Failures in Kubernetes OX8 Deployments

Knowledge Base Community
, , , ,
1

Problem

A customer deployed an Open-Xchange 8 environment on Kubernetes using Kubespray and attempted to integrate it with the Univention OX Connector running on a UCS 5.2 system.

The Open-Xchange deployment used an Envoy gateway on the Kubernetes control plane node for TLS termination and traffic forwarding into the cluster. User authentication against the Open-Xchange App Suite was working successfully, and the /webservices/ endpoint was reachable from browsers and from the host system.

However, the OX Connector running inside its container environment was unable to provision users through the SOAP interface. User synchronization attempts failed with repeated connection errors.

The OX Connector logged the following error during provisioning attempts:

requests.exceptions.ConnectionError:
('Connection aborted.',
 RemoteDisconnected('Remote end closed connection without response'))

Additional listener log excerpts showed:

http.client.RemoteDisconnected:
Remote end closed connection without response

The issue occurred although:

  • DNS resolution inside the container was working correctly
  • The TLS certificate chain was trusted
  • HTTPS requests to the WSDL endpoint succeeded
  • The Open-Xchange App Suite login itself was functioning normally

Environment

The environment used:

  • UCS 5.2 with the OX Connector app installed
  • Open-Xchange 8 deployed on Kubernetes
  • Envoy proxy with external TLS termination enabled
  • HTTPS-only access enforced by the reverse proxy

The Open-Xchange deployment was configured with:

  • Envoy enabled on the Kubernetes control plane node
  • External TLS termination enabled
  • Open-Xchange App Suite exposed through HTTPS
  • SOAP services routed through /webservices

Relevant deployment changes included:

install_envoy: true
external_tls_termination: true

The Open-Xchange administration packages were also enabled:

additional_packages:
  "open-xchange-admin": "enabled"
  "open-xchange-admin-soap": "enabled"

The OX Connector on UCS 5.2 was configured with the following settings:

root@:~# univention-app configure ox-connector --list

OX_SOAP_SERVER: 'https://example.intranet'
OX_IMAP_SERVER: 'imap://mail.example.intranet:143'
OX_SMTP_SERVER: 'smtp://mail.example.intranet:587'
DEFAULT_CONTEXT: 10
OX_LANGUAGE: 'de_DE'
LOCAL_TIMEZONE: 'Europe/Berlin'
OX_MASTER_ADMIN: 'oxadminmaster'
OX_MASTER_PASSWORD: ''
Falling back to initial value for OX_IMAP_LOGIN
OX_IMAP_LOGIN: None
Falling back to initial value for OX_FUNCTIONAL_ACCOUNT_LOGIN_TEMPLATE
OX_FUNCTIONAL_ACCOUNT_LOGIN_TEMPLATE: None
Falling back to initial value for OX_USER_IDENTIFIER
OX_USER_IDENTIFIER: None
Falling back to initial value for OX_GROUP_IDENTIFIER
OX_GROUP_IDENTIFIER: None
OX_ENABLE_DEPUTY_PERMISSIONS: False
OX_CONNECTOR_LOG_LEVEL: 'DEBUG'

The configuration showed that the SOAP endpoint itself was already configured correctly with HTTPS and without a trailing slash.

Root Cause

The root cause was an incorrect SOAP endpoint publication inside the Open-Xchange SOAP configuration.

Although the Open-Xchange environment itself was accessed through HTTPS, the SOAP service advertised its endpoint using HTTP because the baseAddress setting in the Open-Xchange SOAP configuration was unset.

As a result:

  1. The OX Connector successfully downloaded the WSDL via HTTPS
  2. The SOAP client parsed the <soap:address> value from the WSDL
  3. The connector attempted follow-up communication over HTTP
  4. Envoy rejected the HTTP connection
  5. The connector reported RemoteDisconnected

The issue was therefore not caused by:

  • DNS resolution
  • TLS trust configuration
  • Kubernetes networking
  • Envoy malfunction
  • UCS OX Connector configuration

Instead, the issue originated from the Open-Xchange SOAP endpoint publication configuration.

The default behavior of Open-Xchange appeared to generate HTTP endpoints automatically when no explicit baseAddress was configured.

Solution

Through further investigation, the correct Open-Xchange configuration file responsible for the SOAP endpoint publication was identified:

/opt/open-xchange/etc/soap-cxf.properties

The file contains the following configuration option:

# Specify the base address for published end points;
# e.g. "http://www.myserver.com/webservices"

# Default is empty; meaning to use running machine's address
com.openexchange.soap.cxf.baseAddress=

Because the value was empty, Open-Xchange automatically generated SOAP endpoint URLs using HTTP.

The solution was to explicitly configure the HTTPS endpoint:

com.openexchange.soap.cxf.baseAddress=https://example.intranet/webservices

After updating the configuration and restarting the relevant Open-Xchange services, the generated WSDL output changed from:

<soap:address
  location="http://computer.intranet/webservices/OXContextService">

to:

<soap:address
  location="https://example.intranet/webservices/OXContextService">

The OX Connector was then able to communicate successfully with the SOAP interface through the Envoy TLS termination setup.

Investigation

Initial Verification

The customer verified that:

  • HTTPS access to the Open-Xchange App Suite worked
  • Provisioned users could log in successfully
  • The /webservices/ endpoint was reachable
  • The OX Connector container could resolve the Open-Xchange FQDN
  • The CA certificates inside the container were valid

Testing from inside the connector container showed that the WSDL endpoint was reachable:

curl https://example.intranet/webservices/OXContextService?wsdl

The response returned a valid WSDL document.

Connector Debugging

To better understand the failing request path, additional debugging output was inserted into the Python requests adapter used by the connector:

print(f"cl debug trying to path {url} on {conn}")

The connector then logged:

cl debug trying to path /webservices/OXContextService?wsdl
on HTTPSConnectionPool(host='example.intranet', port=443)

This confirmed that the connector initially connected correctly via HTTPS.

Discovery of Incorrect SOAP Endpoint

Inspection of the returned WSDL document revealed the critical detail:

<wsdl:service name="OXContextService">
  <wsdl:port binding="tns:OXContextServiceSoapBinding"
              name="OXContextServiceHttpsEndpoint">
    <soap:address
      location="http://example.intranet/webservices/OXContextService">
    </soap:address>
  </wsdl:port>
</wsdl:service>

Although the WSDL itself was fetched via HTTPS, the published SOAP endpoint inside the WSDL still referenced an HTTP URL.

This caused the SOAP client implementation used by the OX Connector to subsequently attempt communication over plain HTTP instead of HTTPS.

Verification of HTTP Failure

Further testing confirmed this behavior.

Executing the following command inside the OX Connector container:

curl -v http://example.intranet/webservices/OXContextService

resulted in a RemoteDisconnected error.

This verified that the Envoy proxy only accepted HTTPS connections and intentionally rejected plain HTTP traffic.

The behavior of the reverse proxy was correct and intentionally enforced for security reasons. The requirement was to keep the proxy HTTPS-only and avoid enabling insecure HTTP access merely to satisfy the SOAP client.

At this point, the investigation focused on Open-Xchange itself rather than the proxy configuration.

Result

After correcting the SOAP base address configuration:

  • The OX Connector successfully connected to the SOAP endpoint
  • User provisioning worked correctly
  • HTTPS-only enforcement on Envoy could remain unchanged
  • No insecure HTTP exposure was required
  • The Kubernetes ingress and TLS termination design could remain unchanged

This provided a clean and secure solution compatible with Kubernetes deployments using external TLS termination and reverse proxies.