LFS SSL Error #332

New Issue

GiteaMirror · 2025-11-02T03:18:55-06:00

GiteaMirror commented

2025-11-02 03:18:55 -06:00

Originally created by @sciatro on GitHub (Feb 9, 2017).

Gitea version (or commit ref): c5887b0f28
Git version: 2.7.4 (git-lfs version 1.5.5)
Operating system: Ubuntu 16.04
Database (use [x]):
- PostgreSQL
- MySQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

I'm trying out the new LFS support (running master). It's a fantastic addition. Thank you for it. I've noted a potential bug vs corner case:

Using a letsencrypt cert with Gitea directly serving requests (so acting as the SSL endpoint) the browser accepts the certificate as expected; however, when I try to push an LFS file I get an x509: certificate signed by unknown authority error.

I have found two work arounds:

Force it by setting sslverify = false.
Require verification but use Nginx as the SSL endpoint and then reverse proxy to Gitea. It appears the relevant configuration difference is ability to use the fullchain.cer instead of just the cert. If I try to use the full chain as the CERT_FILE in gitea the connection fails altogether.

Thanks again for all the hard work.

Originally created by @sciatro on GitHub (Feb 9, 2017). - Gitea version (or commit ref): c5887b0f28d6915e843f9ca69c42e90577122f99 - Git version: 2.7.4 (git-lfs version 1.5.5) - Operating system: Ubuntu 16.04 - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ## Description I'm trying out the new LFS support (running master). It's a fantastic addition. Thank you for it. I've noted a potential bug vs corner case: Using a letsencrypt cert with Gitea directly serving requests (so acting as the SSL endpoint) the browser accepts the certificate as expected; however, when I try to push an LFS file I get an ``x509: certificate signed by unknown authority`` error. I have found two work arounds: * Force it by setting ``sslverify = false``. * Require verification but use Nginx as the SSL endpoint and then reverse proxy to Gitea. It appears the relevant configuration difference is ability to use the ``fullchain.cer`` instead of just the cert. If I try to use the full chain as the ``CERT_FILE`` in gitea the connection fails altogether. Thanks again for all the hard work.

GiteaMirror added the issue/confirmed type/bug labels 2025-11-02 03:18:55 -06:00

GiteaMirror closed this issue

2025-11-02 03:18:55 -06:00

GiteaMirror commented

2025-11-02 03:18:55 -06:00

@lucassmacedo commented on GitHub (Jan 16, 2019):

I have the same error. Any solution?

@lucassmacedo commented on GitHub (Jan 16, 2019): I have the same error. Any solution?

GiteaMirror commented

2025-11-02 03:18:55 -06:00

@lunny commented on GitHub (Jan 17, 2019):

@sciatro have given two solutions, maybe you can follow them. I think this issue is not related with Gitea and will close this. Please feel free to reopen it.

@lunny commented on GitHub (Jan 17, 2019): @sciatro have given two solutions, maybe you can follow them. I think this issue is not related with Gitea and will close this. Please feel free to reopen it.

GiteaMirror commented

2025-11-02 03:18:55 -06:00

@sciatro commented on GitHub (Jan 18, 2019):

I think this was more accurately categorized as a bug. Perhaps it is a bug that cannot or will not be fixed (fair enough) but a bug nevertheless. The work arounds I posted are just that - work arounds.

Alternatively, if use of a reverse proxy is the deployment expectation now (and use of that proxy to terminate ssl) then this may be better reframed as a documentation bug.

@sciatro commented on GitHub (Jan 18, 2019): I think this was more accurately categorized as a bug. Perhaps it is a bug that cannot or will not be fixed (fair enough) but a bug nevertheless. The work arounds I posted are just that - work arounds. Alternatively, if use of a reverse proxy is the deployment expectation now (and use of that proxy to terminate ssl) then this may be better reframed as a documentation bug.

GiteaMirror commented

2025-11-02 03:18:56 -06:00

@lafriks commented on GitHub (Jan 21, 2019):

@lunny I think built-in ssl should return correctly full chain

@lafriks commented on GitHub (Jan 21, 2019): @lunny I think built-in ssl should return correctly full chain

GiteaMirror commented

2025-11-02 03:18:56 -06:00

@stale[bot] commented on GitHub (Mar 22, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Mar 22, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 03:18:56 -06:00

@zeripath commented on GitHub (May 27, 2019):

OK so this is strange - looking at the code for autocert and acme:

9ca7fcddbb/cmd/web.go (L88)

should set TLSConfig with a certificate:

&tls.Certificate{
		PrivateKey:  s.key,
		Certificate: s.cert,
		Leaf:        s.leaf,
	}

Where Certificate is the full certificate and Leaf is just the local one.

So we should be sending the full certificate already?

@zeripath commented on GitHub (May 27, 2019): OK so this is strange - looking at the code for autocert and acme: https://github.com/go-gitea/gitea/blob/9ca7fcddbb4c9aba7a3f8e84f6c63b7504837bee/cmd/web.go#L88 should set TLSConfig with a certificate: ```go &tls.Certificate{ PrivateKey: s.key, Certificate: s.cert, Leaf: s.leaf, } ``` Where `Certificate` is the full certificate and `Leaf` is just the local one. So we should be sending the full certificate already?

GiteaMirror commented

2025-11-02 03:18:56 -06:00

@techknowlogick commented on GitHub (May 27, 2019):

s := &http.Server{
    TLSConfig: m.TLSConfig(),
}

is the relevant part of an example from official golang docs (where m is the certManager). I think we could switch to that.

@techknowlogick commented on GitHub (May 27, 2019): ``` s := &http.Server{ TLSConfig: m.TLSConfig(), } ``` is the relevant part of an example from official golang docs (where m is the certManager). I think we could switch to that.

GiteaMirror commented

2025-11-02 03:18:56 -06:00

@zeripath commented on GitHub (May 27, 2019):

I can't see why that would be helpful:

func (m *Manager) TLSConfig() *tls.Config {
	return &tls.Config{
		GetCertificate: m.GetCertificate,
		NextProtos: []string{
			"h2", "http/1.1", // enable HTTP/2
			acme.ALPNProto, // enable tls-alpn ACME challenges
		},
	}
}

@zeripath commented on GitHub (May 27, 2019): I can't see why that would be helpful: ```go func (m *Manager) TLSConfig() *tls.Config { return &tls.Config{ GetCertificate: m.GetCertificate, NextProtos: []string{ "h2", "http/1.1", // enable HTTP/2 acme.ALPNProto, // enable tls-alpn ACME challenges }, } } ```

GiteaMirror commented

2025-11-02 03:18:57 -06:00

@zeripath commented on GitHub (May 27, 2019):

If anyone has a letsencrypt running gitea could you check:

openssl s_client -showcerts -connect HOSTNAME:443

Just to ensure that it isn't returning a fullchain.

@zeripath commented on GitHub (May 27, 2019): If anyone has a letsencrypt running gitea could you check: ```bash openssl s_client -showcerts -connect HOSTNAME:443 ``` Just to ensure that it isn't returning a fullchain.

GiteaMirror commented

2025-11-02 03:18:58 -06:00

@techknowlogick commented on GitHub (May 31, 2019):

CLosing this issue as through testing we confirmed that the full chain is being sent. Please re-open if you continue to experience this issue.

@techknowlogick commented on GitHub (May 31, 2019): CLosing this issue as through testing we confirmed that the full chain is being sent. Please re-open if you continue to experience this issue.

GiteaMirror referenced this issue

2025-11-02 11:43:48 -06:00

[PR #332] [MERGED] Fixed project name on repo template mail #15314

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#332