500 Internal error when migrating from another self-signed HTTPS Gitea server #8008

New Issue

GiteaMirror · 2025-11-02T07:48:18-06:00

GiteaMirror commented

2025-11-02 07:48:18 -06:00

Originally created by @hyjwei on GitHub (Oct 22, 2021).

Gitea Version

1.15.4

Git Version

2.33.1

Operating System

Linux amd64

How are you running Gitea?

Prebuild amd64 binary from https://dl.gitea.io/gitea/1.15.4/gitea-1.15.4-linux-amd64

Database

SQLite

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Description

I have setup Gitea ServerA with HTTP (localhost only, on port 3000) and use Nginx reverse proxy to provide both HTTP and HTTPS (on port 80 and 443) to other clients. The HTTPS certificate in Nginx is a self-signed one and I have set "http.sslVerify = false" in client git config to skip the certificate error and access the repo on ServerA. In ServerA app.ini, the ROOT_URL is https://serverA/.

And now I am trying to setup another Gitea ServerB to mirror/backup some repos from ServerA. ServerB is HTTP only (on port 3000) and I am add new migration repo mirrored from ServerA.

Scenario 1: ServerA HTTP/HTTPS both accessible; ServerB git user doesn't have http.sslVerify = false

a) Migrating from HTTPS fail, with error: Migrating from https://serverA/user/repo.git failed.
However, the migration repo in ServerB is created. It is empty and accessing it results in 500 Internal Server Error.

b) Migrating from HTTP fail, with error: Migrating from http://serverA/user/repo.git failed. No migration repo created in ServerB.

Scenario 2: ServerA HTTP/HTTPS both accessible; ServerB git user has http.sslVerify = false

a) Same as S1.a.
Migrating from HTTPS fail, with error: Migrating from https://serverA/user/repo.git failed.
However, the migration repo in ServerB is created. It is empty and accessing it results in 500 Internal Server Error.

b) Migrating from HTTP succeed, clone URL is actually https://serverA/user/repo.git

Scenario 3: ServerA HTTP forcefully redirected to HTTPS; regardless of ServerB git user's http.sslVerify setting

a) Same as S1.a.
Migrating from HTTPS fail, with error: Migrating from https://serverA/user/repo.git failed.
However, the migration repo in ServerB is created. It is empty and accessing it results in 500 Internal Server Error.

b) Similar to S1.a.
Migrating from HTTP fail, with error: Migrating from http://serverA/user/repo.git failed.
However, the migration repo in ServerB is created. It is empty and accessing it results in 500 Internal Server Error.

My guess is that Gitea and git has separated function to access HTTPS repo. Setting git config http.sslVerify only bypass the SSL check in git HTTPS function but there is no way to bypass Gitea's.

When migrating/mirror repo in HTTP, Gitea will access the serverA using HTTP (thus no SSL involved), and the find the serverA advertises ROOT_URL=https://. So it calls git clone using https:// and therefore git config http.sslVerify would make it work.
In other cases, Gitea must migrating/mirror from HTTPS, but encounters self-signed certificate, so it fails. The problem is that it still make an empty repo on ServerB and report 500 Internal Server Error when someone tries to access it.

My suggestion is to add a service configuration in app.ini to allow Gitea to ignore HTTPS certificate error, something like git config sslVerify=false does.

I searched for potential solution and got this Go example :

package main

import (
    "fmt"
    "net/http"
    "crypto/tls"
)

func main() {
    http.DefaultTransport.(*http.Transport).TLSClientConfig = &tls.Config{InsecureSkipVerify: true}
    _, err := http.Get("https://golang.org/")
    if err != nil {
        fmt.Println(err)
    }
}

I understand that this option is insecure and dangerous but it would be nice to have it configurable in app.ini. Thanks!

Screenshots

No response

Originally created by @hyjwei on GitHub (Oct 22, 2021). ### Gitea Version 1.15.4 ### Git Version 2.33.1 ### Operating System Linux amd64 ### How are you running Gitea? Prebuild amd64 binary from https://dl.gitea.io/gitea/1.15.4/gitea-1.15.4-linux-amd64 ### Database SQLite ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Description I have setup Gitea ServerA with HTTP (localhost only, on port 3000) and use Nginx reverse proxy to provide both HTTP and HTTPS (on port 80 and 443) to other clients. The HTTPS certificate in Nginx is a self-signed one and I have set "http.sslVerify = false" in client git config to skip the certificate error and access the repo on ServerA. In ServerA app.ini, the ROOT_URL is https://serverA/. And now I am trying to setup another Gitea ServerB to mirror/backup some repos from ServerA. ServerB is HTTP only (on port 3000) and I am add new migration repo mirrored from ServerA. ### Scenario 1: ServerA HTTP/HTTPS both accessible; ServerB git user doesn't have http.sslVerify = false a) Migrating from HTTPS fail, with error: `Migrating from https://serverA/user/repo.git failed.` However, the migration repo in ServerB is created. It is empty and accessing it results in **500 Internal Server Error**. b) Migrating from HTTP fail, with error: `Migrating from http://serverA/user/repo.git failed.` No migration repo created in ServerB. ### Scenario 2: ServerA HTTP/HTTPS both accessible; ServerB git user has http.sslVerify = false a) Same as S1.a. Migrating from HTTPS fail, with error: `Migrating from https://serverA/user/repo.git failed.` However, the migration repo in ServerB is created. It is empty and accessing it results in **500 Internal Server Error**. b) Migrating from HTTP succeed, clone URL is actually `https://serverA/user/repo.git` ### Scenario 3: ServerA HTTP forcefully redirected to HTTPS; regardless of ServerB git user's http.sslVerify setting a) Same as S1.a. Migrating from HTTPS fail, with error: `Migrating from https://serverA/user/repo.git failed.` However, the migration repo in ServerB is created. It is empty and accessing it results in **500 Internal Server Error**. b) Similar to S1.a. Migrating from HTTP fail, with error: `Migrating from http://serverA/user/repo.git failed.` However, the migration repo in ServerB is created. It is empty and accessing it results in **500 Internal Server Error**. ### My guess is that Gitea and git has separated function to access HTTPS repo. Setting git config http.sslVerify only bypass the SSL check in git HTTPS function but there is no way to bypass Gitea's. - When migrating/mirror repo in HTTP, Gitea will access the serverA using HTTP (thus no SSL involved), and the find the serverA advertises ROOT_URL=https://. So it calls `git clone` using https:// and therefore git config http.sslVerify would make it work. - In other cases, Gitea must migrating/mirror from HTTPS, but encounters self-signed certificate, so it fails. The problem is that it still make an empty repo on ServerB and report 500 Internal Server Error when someone tries to access it. ### My suggestion is to add a service configuration in app.ini to allow Gitea to ignore HTTPS certificate error, something like git config sslVerify=false does. I searched for potential solution and got [this Go example](https://stackoverflow.com/questions/12122159/how-to-do-a-https-request-with-bad-certificate) : ``` package main import ( "fmt" "net/http" "crypto/tls" ) func main() { http.DefaultTransport.(*http.Transport).TLSClientConfig = &tls.Config{InsecureSkipVerify: true} _, err := http.Get("https://golang.org/") if err != nil { fmt.Println(err) } } ``` I understand that this option is insecure and dangerous but it would be nice to have it configurable in app.ini. Thanks! ### Screenshots _No response_

GiteaMirror added the issue/not-a-bug label 2025-11-02 07:48:18 -06:00

GiteaMirror closed this issue

2025-11-02 07:48:21 -06:00

GiteaMirror commented

2025-11-02 07:48:29 -06:00

@wxiaoguang commented on GitHub (Oct 22, 2021):

You can add your self-signed CA certificate to you system root CA, then the self-signed CA certificate can be trusted.

ps: I do not think this is a kind/bug, lol

@wxiaoguang commented on GitHub (Oct 22, 2021): You can add your self-signed CA certificate to you system root CA, then the self-signed CA certificate can be trusted. ps: I do not think this is a `kind/bug`, lol

GiteaMirror commented

2025-11-02 07:48:31 -06:00

@lunny commented on GitHub (Oct 22, 2021):

OK. I just found github doesn't follow setting.Migrations.SkipTLSVerify and for Gitea itself ( this issue), you should set

[migrations]
SKIP_TLS_VERIFY=true

@lunny commented on GitHub (Oct 22, 2021): OK. I just found github doesn't follow `setting.Migrations.SkipTLSVerify` and for Gitea itself ( this issue), you should set ```ini [migrations] SKIP_TLS_VERIFY=true ```

GiteaMirror commented

2025-11-02 07:48:33 -06:00

@lunny commented on GitHub (Oct 22, 2021):

Just found, SkipTLSVerify will be introduced in v1.16, so it's a feature which has been implemented in v1.16. I think we can close this now.

@lunny commented on GitHub (Oct 22, 2021): Just found, SkipTLSVerify will be introduced in v1.16, so it's a feature which has been implemented in v1.16. I think we can close this now.

GiteaMirror commented

2025-11-02 07:48:36 -06:00

@hyjwei commented on GitHub (Oct 22, 2021):

Thanks @lunny . I was wondering why SKIP_TLS_VERIFY = true doesn't work when I try it.

One more thing. I believe that at least 500 Internal Server Error should be avoided. So if Gitea gets certificate error, it should either give up, or as I suggested, to ignore the error (with SKIP_TLS_VERIFY) and go ahead to migrate the repo. It shouldn't leave a half-migrated empty git repo in such case.

@hyjwei commented on GitHub (Oct 22, 2021): Thanks @lunny . I was wondering why SKIP_TLS_VERIFY = true doesn't work when I try it. One more thing. I believe that at least 500 Internal Server Error should be avoided. So if Gitea gets certificate error, it should either give up, or as I suggested, to ignore the error (with SKIP_TLS_VERIFY) and go ahead to migrate the repo. It shouldn't leave a half-migrated empty git repo in such case.

GiteaMirror commented

2025-11-02 07:48:40 -06:00

@lunny commented on GitHub (Oct 22, 2021):

Yeah, it should return an error message but not just a 500.

@lunny commented on GitHub (Oct 22, 2021): Yeah, it should return an error message but not just a 500.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#8008