Gitea: LFS SSL Error

[sciatro]

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

[lucassmacedo]

I have the same error. Any solution?

[lunny]

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

[sciatro]

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.

[lafriks]

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

[stale[bot]]

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.

[zeripath]

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:

&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?

[techknowlogick]

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.

[zeripath]

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]

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.

[techknowlogick]

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.