• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Gitea und LetsEncrypt SSL (cert file & key file)

DarkTrinity

Member
Hallo liebe Community ;),

ich würde gerne mein Gitea über SSL sichern. Die Domain, über die es erreichbar ist, hat bereits ein SSL Zertifikat von Lets Encrypt, was auch funktioniert.
Da Gitea jedoch eine eigene Konfigurationsdatei app.ini hat, läuft es derzeit noch unverschlüsselt ^^

In dieser Konfigurationsdatei habe ich folgende Parameter für SSL:
[server]
[...]
#CERT_FILE = cert.pem
#KEY_FILE = key.pem

Die zugehörige Domain ist von LetsEncrypt wie folgt bestückt worden:
cert.pem
chain.pem
fullchain.pem
privkey.pem

Wenn ich die cert.pem als Cert_File und die privkey.pem als Key_File verwende, bekomme ich aber einen SSL Fehler auf diesem Port.

Kann vielleicht jemand so nett sein und mir sagen, wie ich die Dateien von LetsEncrypt hier richtig zuordnen kann ?

Lieben Dank vorab :)
 
CERT_FILE muss auf fullchain.pem verlinken.
KEY_FILE muss auf privkey.pem verlinken.
Nach wie vor der gleiche Fehler:
Fehlercode: SSL_ERROR_RX_RECORD_TOO_LONG

Verzeichnis im Dateisystem und Softlinks sehen so aus:
ls -l
-rw-r----- 1 git git 1934 Jan 10 18:22 app.ini
lrwxrwxrwx 1 root root 59 Jan 10 18:21 cert.pem -> /etc/letsencrypt/live/DOMAIN.tld/fullchain.pem
lrwxrwxrwx 1 root root 57 Jan 10 18:21 key.pem -> /etc/letsencrypt/live/DOMAIN.tld/privkey.pem
Inhalt der APP.INI
[server]
SSH_DOMAIN = domain.tld
DOMAIN = domain.tld
HTTP_PORT = 3300
ROOT_URL = https://domain.tld:3300/
DISABLE_SSH = true
SSH_PORT = XX
LFS_START_SERVER = true
LFS_CONTENT_PATH = /var/lib/gitea/data/lfs
LFS_JWT_SECRET = XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
OFFLINE_MODE = false
CERT_FILE = /etc/gitea/cert.pem
KEY_FILE = /etc/gitea/key.pem
Danach natürlich den Dienst restartet
systemctl restart gitea
Was mache ich falsch ? :(
 
Ich habe es über eine Subdomain eingebunden und gleich mit eigenem Lets Encrypt Zertifikat anlegen lassen. Als Panel benutze ich Keyhelp. Die Subdomain in einen seperaten Ordner angelegt und dann den vhost editiert.
Code:
ProxyPreserveHost On
ProxyRequests off
ProxyPass /.well-known/acme-challenge !
ProxyPass / http://localhost:3000/
ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/
ErrorLog /home/users/tolleruser/logs/git_error.log
CustomLog /home/users/tolleruser/logs/git_access.log combined
<IfModule mod_proxy.c>
        ProxyPass /.well-known/acme-challenge !
</IfModule>

Alias /.well-known/acme-challenge /home/keyhelp/www/.well-known/acme-challenge
Und damit lässt sich das direkt über die Subdomain aufrufen.
 
Ich habe es über eine Subdomain eingebunden und gleich mit eigenem Lets Encrypt Zertifikat anlegen lassen. Als Panel benutze ich Keyhelp. Die Subdomain in einen seperaten Ordner angelegt und dann den vhost editiert.

Und damit lässt sich das direkt über die Subdomain aufrufen.
Das möchte ich so nicht.

Aber habe mit dem gleichen Vorgehen auch das ISP Config Panel mit einem SSL Zertifikat versehen. Dieses Panel läuft ebenfalls über einen eigenen Port (8080) und da funktioniert es ja auch :confused:

Notfalls kann ich gitea auch unverschlüsselt lassen, wäre aber "unschön" ....

Ich denke das liegt irgendwie an der Art wie man die Cert- Files zuordnet.
 
2s google und die Doku meinen, da fehlt die Protocol-Direktive...
https://docs.gitea.io/en-us/https-setup/
Das gibt es doch nicht ... Aufruf: https://domain.tld:3300
:eek:

Die Website ist nicht erreichbar​

domain.tld hat die Verbindung abgelehnt.

Versuchen Sie Folgendes:​

  • Verbindung prüfen
  • Checking the proxy and the firewall
ERR_CONNECTION_REFUSED

Hinzugefügt hatte ich zuerst:
PROTOCOL = https

Als das nicht ging wg genannter Fehlermeldung, habe ich folgende Parameter ergänzt, obwohl die eigentlich ja nur für die automatische Erneuerung der CERTs gedacht sind (das wird aber ja über die Domain bzw ISPC gehandhabt)
ENABLE_LETSENCRYPT=true
LETSENCRYPT_ACCEPTTOS=true
LETSENCRYPT_DIRECTORY=https

Gleiche Fehlermeldung natürlich.

In der Firewall ist der Port 3300 jedoch geöffnet, sonst würde es ja über http auch nicht gehen.

Der gitea Dienst wurde nach jeder Änderung restarted....

:(
 
Hast du mal mit netstat oder lsof geschaut, ob Gitea auf den entsprechenden Ports aktuell lauscht?
 
Back
Top