Skip to main content
Question

SecOps Remote agent started but not running properly with error "Import Error: Can't connect to HTTPS URL because the SSL module is not available"

  • March 26, 2026
  • 2 replies
  • 55 views

cathychancf

I am installing a remote agent in RHEL server (offline) following this guide https://docs.cloud.google.com/chronicle/docs/soar/working-with-remote-agents/create-agent-with-installer-for-rhel. The installer script finished and show agent started. 

However, when I get into /opt/xxx/Logs/supervisord.log, it shows "Import Error: Can't connect to HTTPS URL because the SSL module is not available" with “publisher_api_wrapper.PublisherAPIError: send_keep_alive_package try to connect publisher 3 times and failed”.

 

We use “/usr/local/bin/python3.11 -c "import ssl; print(ssl.OPENSSL_VERSION)"” to verify the installation of OpenSSL package and returned “OpenSSL 3.0.7 1 Nov 2022”. 

 

Any help would be highly appreciated.

Thank you.

 

 

2 replies

SoarAndy
Staff
Forum|alt.badge.img+12
  • Staff
  • March 27, 2026

Historically I found Docker/podman agents to be the most easy to deploy, other linux installs to be good but it required accurate prep (according to the docs), and I’m sorry but RHEL / offline RHEL the hardest, it’s due to package management and versioning. 

I could only point you to the official docs and ask you to go through thoroughly
https://docs.cloud.google.com/chronicle/docs/soar/working-with-remote-agents/create-agent-with-installer-for-rhel

Is a podman/docker version possible in your setup?


hzmndt
Staff
Forum|alt.badge.img+11
  • Staff
  • March 28, 2026

The error messages `Import Error: Can't connect to HTTPS URL because the SSL module is not available` and `publisher_api_wrapper.PublisherAPIError: send_keep_alive_package try to connect publisher 3 times and failed` strongly indicate that the Python 3.11 installation used by the agent cannot find or load the necessary SSL support, despite OpenSSL 3.0.7 being present on the system.

This usually happens if Python wasn't compiled correctly to link against the custom OpenSSL installation. Here's a breakdown of potential issues and how to troubleshoot:

1.  **Python Compilation & Linking:**
    *   The guide includes `./configure --prefix=/usr/local --enable-unicode=ucs4 --with-openssl=/usr/local/ssl`. This *should* link Python to your custom OpenSSL. However, environment variables or prior build artifacts can sometimes interfere.
    *   **Action:** Before running `make` and `make altinstall` for Python, ensure the environment is clean and points to the correct OpenSSL build. The guide does set `LDFLAGS` and `LD_LIBRARY_PATH` *after* building OpenSSL, but it's crucial these are in effect for the *Python build process itself*.

2.  **Environment Variables During Python Build:**
    *   The `LD_LIBRARY_PATH` and `LDFLAGS` environment variables are critical for the configure script and the build process to find the custom OpenSSL libraries and headers.
    *   **Action:** Try re-running the Python compilation steps, but ensure the environment variables are set *before* `./configure`:

    ```bash
    cd /usr/src/Python-3.11.8

    # Ensure the env vars are set in THIS session
    export LDFLAGS="-L/usr/local/ssl/lib64"
    export LD_LIBRARY_PATH="/usr/local/ssl/lib64"
    export PKG_CONFIG_PATH="/usr/local/ssl/lib64/pkgconfig" # Add this one too

    # Clean up any previous attempts
    make clean

    # Re-configure
    ./configure --prefix=/usr/local --enable-unicode=ucs4 --with-openssl=/usr/local/ssl --enable-loadable-sqlite-extensions

    # Rebuild and reinstall
    make
    make altinstall
    ```

3.  **Verify Python's SSL Support:**
    *   After reinstalling Python, re-verify if the `ssl` module is now available *within that specific Python environment*:

    ```bash
    /usr/local/bin/python3.11 -c "import ssl; print(ssl.OPENSSL_VERSION)"
    # Should still show OpenSSL 3.0.7

    /usr/local/bin/python3.11 -m ssl
    # If successful, this command should exit without error.
    # An error like "No module named _ssl" indicates the problem persists.
    ```

4.  **Check for `_ssl.so`:**
    *   See if the actual compiled module exists:

    ```bash
    find /usr/local/lib/python3.11 -name "_ssl*.so"
    ```
    *   This should find a file like `/usr/local/lib/python3.11/lib-dynload/_ssl.cpython-311-x86_64-linux-gnu.so`. If it's missing, the build didn't create it.

5.  **Dependencies for `_ssl.so`:**
    *   If the file exists, check its dependencies:

    ```bash
    ldd /usr/local/lib/python3.11/lib-dynload/_ssl.cpython-311-x86_64-linux-gnu.so | grep ssl
    ```
    *   This output *must* show it linking to libraries within `/usr/local/ssl/lib64/` (e.g., `libssl.so.3 => /usr/local/ssl/lib64/libssl.so.3`). If it points to system libraries (e.g., in `/usr/lib64`), the build process picked up the wrong OpenSSL.

6.  **`urllib3` Version:**
    *   Versions of the Python package `urllib3` greater than or equal to 2.0 can sometimes trigger this error if there are subtle issues with the SSL module linking. Since this is an offline installation, you control the package versions.
    *   **Action:** Check the installed `urllib3` version and consider pinning it to an older version if the above steps don't resolve the issue:

    ```bash
    /usr/local/bin/python3.11 -m pip show urllib3
    # If >= 2.0, try downgrading (requires transferring the wheel file for offline install)
    # Example: /usr/local/bin/python3.11 -m pip install urllib3==1.26.18
    ```

**Recommendation:**

Start by meticulously re-running the Python compilation steps (Step 2 above), ensuring the environment variables are set *before* calling `./configure`.

Then, verify using the commands in Step 3, 4, and 5.