Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Getting an SSL error when querying project#3212

Answeredbyquazar-omega
quazar-omega asked this question inQ&A
Discussion options

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

You must be logged in to vote

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 mycompose.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'    …

Replies: 2 comments 4 replies

Comment options

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 -vIhttps://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.

You must be logged in to vote
1 reply
@quazar-omega
Comment options

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

Comment options

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 mycompose.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 thegitlab.rb (throughGITLAB_OMNIBUS_CONFIG) found from this posthttps://serverfault.com/questions/1022717/using-gitlab-docker-behind-nginx-proxy-manager-docker

I put this in the variable, note the difference inexternal_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

You must be logged in to vote
3 replies
@nejch
Comment options

Glad you solved it!

Just for any future readers: TheUserWarning 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
Comment options

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
Comment options

@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.

Answer selected byquazar-omega
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
Q&A
Labels
None yet
3 participants
@quazar-omega@JohnVillalovos@nejch

[8]ページ先頭

©2009-2025 Movatter.jp