Gitea: Integrate Let's Encrypt with Gitea

Created on 9 Mar 2017  路  18Comments  路  Source: go-gitea/gitea

It would be useful and encourage more people to use SSL if there is built in support for let's Encrypt.

kinenhancement

Most helpful comment

@egtann I've created a pull for this. It's a couple more than 5 LOC, but if reviewed successfully then perhaps it could be in 1.6 release 馃

All 18 comments

I think most people are using Gitea anyway behind a revers proxy. But with golang.org/x/crypto/acme/autocert it's pretty easy to implement it.

This was just updated and looks interesting for let's encrypt integration:
https://go-review.googlesource.com/c/39207/

Even without the latest change it have been damn easy to integrate

It is extremely easy when using something like nginx as a proxy in front of gitea

# MANAGED BY PUPPET
server {
  listen *:80;
  server_name           server.tld;

  add_header              'Strict-Transport-Security' 'max-age=63072000; includeSubdomains; preload';
  add_header              'X-Content-Type-Options' 'nosniff';
  return 301 https://$host$request_uri;
  access_log            /var/log/nginx/server.tld.access.log combined;
  error_log             /var/log/nginx/server.tld.error.log;
}
# MANAGED BY PUPPET
server {
  listen       *:443 ssl http2;
  server_name  server.tld;

  ssl on;

  ssl_certificate           /etc/letsencrypt/live/server.tld/fullchain.pem;
  ssl_certificate_key       /etc/letsencrypt/live/server.tld/privkey.pem;
  ssl_dhparam               /etc/ssl/certs/dhparam.pem;
  ssl_session_cache         shared:SSL:10m;
  ssl_session_timeout       5m;
  ssl_protocols             TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers               ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS;
  ssl_prefer_server_ciphers on;

  index  index.html index.htm index.php;

  access_log            /var/log/nginx/ssl-server.tld.access.log combined;
  error_log             /var/log/nginx/ssl-server.tld.error.log;
  add_header              'Strict-Transport-Security' 'max-age=63072000; includeSubdomains; preload';
  add_header              'X-Content-Type-Options' 'nosniff';

  location /.well-known {
    root      /var/www;
    index     index.html index.htm index.php;
  }

  location /git/ {
    proxy_pass            http://localhost:3000/;
    proxy_read_timeout    90;
    proxy_connect_timeout 90;
    proxy_set_header      Host $host;
    proxy_set_header      X-Real-IP $remote_addr;
    proxy_set_header      X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header      Proxy "";
  }
}

There are still enough people that don't use a reverse proxy in front of the application. The autocert lib makes it damn easy to integrate. We are using traefik in front of our services

@plessbd how is that easier than a single flag in gitea config saying "use letsencrypt"?

Beside the let's encrypt integration itself we should also add an automated redirect to https like mentioned at https://github.com/drone/drone/pull/1921#issuecomment-292056587

@tboerger I try the solution from https://github.com/drone/drone/pull/1921#issuecomment-292056587 it can't work for me.

see the source: https://github.com/go-training/training/blob/master/example10-simple-http-server/server/server07.go

package main

import (
    "log"
    "net/http"

    "github.com/gin-gonic/gin"
    "golang.org/x/crypto/acme/autocert"
    "golang.org/x/sync/errgroup"
)

func main() {
    r := gin.Default()

    // Ping handler
    r.GET("/ping", func(c *gin.Context) {
        c.String(200, "pong")
    })

    var g errgroup.Group

    g.Go(func() error {
        return http.ListenAndServe(":http", http.RedirectHandler("https://example.com", 303))
    })
    g.Go(func() error {
        return http.Serve(autocert.NewListener("example.com"), r)
    })

    if err := g.Wait(); err != nil {
        log.Fatal(err)
    }
}

@ptman Guess it depends on setup.

Personally I think a lets encrypt library is just adding dependencies to something that doesn't need it.

Isolation of responsibilities and all.

All lets encrypt does is give you a certificate, all gitea should do in my opinion is let you specify an ssl cert and use it.

We did have cert build-tag a while ago, might consider adding it again but with lets encrypt support :)

@bkcsoft great idea and we could use a new command name, for example le?

No need for a new command IMO. There should be a background worker to check the cert every X interval and update is necessary

+1 for this being built in; I'd rather not have to set up nginx if the only service my cheap VPS is running is gitea. Would much rather gitea be the only service running.

@bkcsoft no background worker required, the autocert lib handles everything automatically. This is also used within drone and some of my projects.

Yeah, the hardest part of setting up Lets Encrypt with a single service like this is setting up the way for LE to verify the domain is yours.

The mentioned autocert lib handles that, it just doesn't support the DNS retrieval.

Any update on this? As @tboerger is pointing out, this should be a ~5 LOC change to read a new config option and use the autocert library if requested: https://godoc.org/golang.org/x/crypto/acme/autocert, giving everybody HTTPS out-of-the-box without needing to set up/maintain a proxy.

@egtann I've created a pull for this. It's a couple more than 5 LOC, but if reviewed successfully then perhaps it could be in 1.6 release 馃

Was this page helpful?
0 / 5 - 0 ratings