Getting an SSL error when querying project #3212

quazar-omega · 2025-06-08T17:01:07Z

quazar-omega
Jun 8, 2025

Hi!
I've been playing around with the library against a self hosted GitLab instance and it has worked without issue every time until recently, where, without changing the code, I started getting this error for all interactions with a project.

requests.exceptions.SSLError: HTTPSConnectionPool(host='gitlab.example.com', port=80): Max retries exceeded with url: /api/v4/projects/5/labels?id=5&include_ancestor_groups=true&page=2&per_page=20&with_counts=false (Caused by SSLError(SSLError(1, '[SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1028)')))

I can't figure out if it's something I've done somehow, but I don't think I touched anything.
For context, I'm sitting behind a VPN and the target instance is served through HTTPS with an NGINX reverse proxy in the middle

Answered by quazar-omega

Jun 11, 2025

I found out the root cause by printing the server responses from within the urllib library:

UserWarning: The base URL in the server response differs from the user-provided base URL (https://gitlab.example.com:443 -> https://gitlab.example.com:80)

So it was a configuration issue, I had this in my compose.yaml:

services:
  gitlab:
    image: gitlab/gitlab-ee:18.0.1-ee.0
    container_name: gitlab
    restart: always
    hostname: '$HOSTNAME'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        # Add any other gitlab.rb configuration here, each on its own line
        # I'm including only relevant configs here
        external_url 'http://$HOSTNAME'
    ports:
      - '$SSH_PORT:22'
    …

View full answer

JohnVillalovos · 2025-06-08T19:25:59Z

JohnVillalovos
Jun 8, 2025
Maintainer

I pasted this into Google Gemini

The requests.exceptions.SSLError: HTTPSConnectionPool(host='gitlab.example.com', port=80): Max retries exceeded with url: ... (Caused by SSLError(SSLError(1, '[SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1028)'))) error indicates a problem with the SSL/TLS handshake between your Python program and the GitLab server.
Here's a breakdown of what's likely happening and how to troubleshoot it:
Understanding the Error

SSLError: WRONG_VERSION_NUMBER: This is the core of the problem. It means that during the SSL/TLS handshake, the client (your Python program) and the server (gitlab.example.com) are unable to agree on a compatible SSL/TLS protocol version.
HTTPSConnectionPool(host='gitlab.example.com', port=80): This part is crucial. You're trying to connect to gitlab.example.com on port 80. Port 80 is typically used for HTTP (unencrypted) traffic, not HTTPS (encrypted) traffic. SSL/TLS operates on a different port, usually 443.
Most Likely Cause
You are attempting to make an HTTPS request to an HTTP port (port 80). The server on port 80 is not expecting an SSL handshake, so it responds with something that the SSL client interprets as a "wrong version number" because it's not a valid SSL/TLS handshake.
Solutions
Correct the Port to 443 (Most Common Fix):
If gitlab.example.com is indeed an HTTPS server (which is standard for GitLab), you should be connecting to port 443. Change your URL to use https:// and ensure you're not explicitly setting the port to 80.
import requests

Correct URL for HTTPS

url = "https://gitlab.example.com/api/v4/projects/5/labels?id=5&include_ancestor_groups=true&page=2&per_page=20&with_counts=false"

try:
    response = requests.get(url)
    response.raise_for_status()  # Raise an HTTPError for bad responses (4xx or 5xx)
    print("Success!")
    print(response.json())
except requests.exceptions.RequestException as e:
    print(f"An error occurred: {e}")

Verify the Server's SSL/TLS Configuration:
If you are sure you want to connect to gitlab.example.com and it's supposed to be an HTTPS endpoint, there might be an issue with the server's SSL/TLS configuration itself.
- Self-signed certificates: If gitlab.example.com uses a self-signed certificate, your requests client won't trust it by default. You can tell requests to ignore SSL verification (use with caution, as it makes your connection vulnerable to Man-in-the-Middle attacks):
  requests.get(url, verify=False)
  
  Or, a better approach is to provide the path to your custom CA bundle:
  requests.get(url, verify='/path/to/your/custom_ca_bundle.pem')
- Outdated TLS protocols: The server might be configured to only support older, insecure TLS versions (like TLS 1.0 or 1.1) which modern Python and OpenSSL versions might deprecate or not enable by default. While less common for GitLab, it's a possibility.
- Intermediate Proxies/Firewalls: Sometimes, a network proxy or firewall can intercept SSL/TLS traffic and cause these issues. This is especially true in corporate environments. The proxy might be presenting its own certificate or interfering with the SSL handshake.
Check for Network Intermediaries:
As mentioned, firewalls, proxies, or even antivirus software can sometimes intercept and re-encrypt HTTPS traffic. If you're in such an environment, consult your IT department or try disabling any such software temporarily (if safe to do so) to see if it resolves the issue.
Use curl to Test:
You can use curl from your terminal to get more verbose information about the SSL handshake with the GitLab server.
curl -vI https://gitlab.example.com/

This will show you the SSL/TLS version, cipher suites, and certificate details. If you get a "wrong version number" with curl as well, it strongly indicates a server-side configuration issue or a network intermediary.
In summary, the most likely solution is to ensure your URL uses https:// and therefore connects to port 443.

1 reply

quazar-omega Jun 8, 2025
Author

Oh sorry, I noticed I disclosed the URL there, my oversight, could you edit your comment and delete the original from the revisions, please?

Thanks for the suggestions BTW, I'll try to go through that and see what I can get

quazar-omega · 2025-06-11T07:52:58Z

quazar-omega
Jun 11, 2025
Author

I found out the root cause by printing the server responses from within the urllib library:

UserWarning: The base URL in the server response differs from the user-provided base URL (https://gitlab.example.com:443 -> https://gitlab.example.com:80)

So it was a configuration issue, I had this in my compose.yaml:

services:
  gitlab:
    image: gitlab/gitlab-ee:18.0.1-ee.0
    container_name: gitlab
    restart: always
    hostname: '$HOSTNAME'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        # Add any other gitlab.rb configuration here, each on its own line
        # I'm including only relevant configs here
        external_url 'http://$HOSTNAME'
    ports:
      - '$SSH_PORT:22'
    volumes:
      - '$GITLAB_HOME/config:/etc/gitlab'
      - '$GITLAB_HOME/logs:/var/log/gitlab'
      - '$GITLAB_HOME/data:/var/opt/gitlab'
    shm_size: '256m'

networks:
  default:
    external: true
    name: $NETWORK_NAME

I had the external URL as HTTP, consequently GitLab assumed port 80 and that's what it would respond with when asking for paginated endpoints (gitlab.example.com:80/api<...>) since it specifies the port there, of course that couldn't work when there's Nginx Proxy Manager in the middle configured for HTTPS, so I was missing a couple lines of configuration in the gitlab.rb (through GITLAB_OMNIBUS_CONFIG) found from this post https://serverfault.com/questions/1022717/using-gitlab-docker-behind-nginx-proxy-manager-docker

I put this in the variable, note the difference in external_url in particular with the added "s" to "http":

GITLAB_OMNIBUS_CONFIG: |
        # Add any other gitlab.rb configuration here, each on its own line
        # I'm including only relevant configs here
        external_url 'https://$HOSTNAME'
        nginx['listen_port'] = 80
        nginx['listen_https'] = false

And now it's all working correctly, GitLab responds with HTTPS endpoints.

Note: the reason why it worked until it didn't is that my requests initially didn't need pagination until I had added enough labels to the project, so it only used the URL I would provide, which also led me to believe there weren't problems with my input (which is true, the issue lies in the server response) when I tried to perform a manual connection as suggested by @JohnVillalovos to troubleshoot

3 replies

nejch Jun 11, 2025
Maintainer

Glad you solved it!

Just for any future readers: The UserWarning URL warnings come from python-gitlab when it detects the server's advertised URL differs from that of the URL configured on the client and usually points to some misconfiguration (either on the client, proxy, or GitLab level) as was shown above here.

quazar-omega Jun 11, 2025
Author

Oh, I see, I thought it came from the server, how can I get these warnings always? When I enabled the python-gitlab debug mode this didn't come up on its own, I had to print it explicitly

nejch Jun 12, 2025
Maintainer

@quazar-omega the UserWarning is always raised by python-gitlab when it detects this, but maybe it wasn't surfaced by your app - not sure about the context or what your code looks like. But if you executed that code directly in a script/snippet, you'd see the UserWarning logged to stderr directly.

Getting an SSL error when querying project #3212

Uh oh!

Uh oh!

quazar-omega Jun 8, 2025

Replies: 2 comments · 4 replies

Uh oh!

Uh oh!

JohnVillalovos Jun 8, 2025 Maintainer

Correct URL for HTTPS

Uh oh!

quazar-omega Jun 8, 2025 Author

Uh oh!

Uh oh!

quazar-omega Jun 11, 2025 Author

Uh oh!

nejch Jun 11, 2025 Maintainer

Uh oh!

quazar-omega Jun 11, 2025 Author

Uh oh!

nejch Jun 12, 2025 Maintainer

quazar-omega
Jun 8, 2025

Replies: 2 comments 4 replies

JohnVillalovos
Jun 8, 2025
Maintainer

quazar-omega Jun 8, 2025
Author

quazar-omega
Jun 11, 2025
Author

nejch Jun 11, 2025
Maintainer

quazar-omega Jun 11, 2025
Author

nejch Jun 12, 2025
Maintainer