Pushed it to nethforge-testing 
Kudos to @danb35 @dnutan @mrmarkuz !
To install and evaluate :
yum install --enablerepo=nethforge-testing nethserver-gitea
local admin = gitea
password = gitea
Nethersever users must login in with the short username.
Happy to hear remarks, comments, quirks and bugs !
Late to the party. You made a great job guys. Kudos 
First, thanks for your effort and patience with my domain requests…
When you set the virtualhost and uninstall nethserver-gitea the /etc/httpd/conf.d/zz_gitea.conf isn’t deleted and still points to files that are not there anymore:
SSLCertificateFile "/etc/pki/gitea/certs/gitea.crt"
SSLCertificateKeyFile "/etc/pki/gitea/private/gitea.key"
what causes httpd to not (re)start:
Sep 06 14:28:14 testvm2.domain.local httpd[6543]: AH00526: Syntax error on line 32 of /etc/httpd/conf.d/zz_gitea.conf:
Sep 06 14:28:14 testvm2.domain.local httpd[6543]: SSLCertificateFile: file '/etc/pki/gitea/certs/gitea.crt' does not exist or is empty
Another question: Is it possible to set a custom gitea mail from address?
you mean here, right?
[mailer]
ENABLED = true
FROM = gitea@example.con
USE_SENDMAIL = true
SENDMAIL_PATH = /usr/sbin/sendmail
If we add a db-prop for it we can ! (in next release oke?)
Good point it happens more…
I can remove it by adding
rm -f /etc/httpd/conf.d/zz_gitea.conf
or
mv /etc/httpd/conf.d/zz_gitea.conf.rpmsave
in the spec at %postun
Actually i do not know the convention for this 
Is this oke to remove the configuration file?
%postun
if [ $1 == 0 ]; then
/usr/bin/rm -f /etc/httpd/conf.d/zz_gitea.conf > /dev/null 2>&1
/usr/bin/systemctl reload httpd
fi
Or is there an e-smith method to do this?
Good question… I rarely (never) found the need of cleaning up during package removal. The %postun script above shouldn’t harm!
Please note that if the .conf file is not a template/RPM config file, it is removed by RPM itself. When a nethserver package is removed, the “update” events of all remaining packages are fired, so httpd is fully restarted.
IIUC:
if a dummy /etc/httpd/conf.d/zz_gitea.conf (which gets overwritten at template expansion) is in the package it is removed by RPM.
/usr/bin/systemctl reload httpd is not needed: the update event after removal takes care of this.
Just to be sure at package removal (not update) may keep:
%postun
if [ $1 == 0 ]; then
/usr/bin/rm -f /etc/httpd/conf.d/zz_gitea.conf > /dev/null 2>&1
fi
EDIT:
Know one possible suspect:
Cleaning up /etc/httpd/conf.d seems to be a good idea in general because even if NS cert is used and httpd throws no error some unneeded virtualhost/reverseproxy stays there.
This leads to another question: Is there a special reason to use an own certificate for gitea? It seems to work If you just use the NS cert/key, I tried git push to HTTPS and it worked:
SSLCertificateFile "/etc/pki/tls/certs/localhost.crt"
SSLCertificateKeyFile "/etc/pki/tls/private/localhost.key"
It’s a result of my interpretation off :
A certificate consumer daemon should expand those templates to its own certificate paths, by installing the proper configuration under /etc/e-smith/templates.metadata.
http://docs.nethserver.org/projects/nethserver-devel/en/latest/certificate_management.html
And that interpretation be wrong…
Honestly, I don’t know if it means that you have to create an own cert for using same httpd (which may not be another daemon in this case). 
Good point ! the httpd is not run as gitia and should (?) use the localhost cert.
Gitea may require a certificate, although we actually do not seem use it (not sure about this…) as gitea listens on http://localhost:5321.
Yes, it seems giteas built in server can use an own cert but we use reverse proxy:
Hence the recommendation to keep the access to loaclhost
Need to rephrase this: it listens on ::5321 ; firewall “keeps” it on the localhost.
if port is opened it should respond to http://fqnd:5321.
Then the question is should we change the protocol to https, personally I dislike using https for the localhost…
What do you recommend?
I’d just keep the reverse proxy to localhost, so we stay flexible and can do cert settings in httpd via web UI.
Sorry, it wasn’t clear from my statement.
don’t be sorry i like this conversation 
And i was not so clear too:
I ment: what if someone opens the port to red/green ? And sends password etc unencrypted, should we take measures to this mall-configuration and use https://::5321 ? may be done conditional…
That must never be done, one has to use reverse proxy. I think it’s done in the same way with other apps (SOGo, guacamole, …).
SOGo example:
<Location /SOGo>
ProxyPass http://127.0.0.1:20000/SOGo retry=0
ProxyPassReverse http://127.0.0.1:20000/SOGo
SetEnv proxy-nokeepalive 1
</Location>
In other words: Reverse proxy from HTTPS to HTTPS may be too much.
meanwhile your comments (mailfrom and removal of conf) are processed ! thanx
An option to prevent this would be to enforce the db prop value with a force/ db entry. For me documenting it it’s more than enough (…service runs on localhost and iiss accessible through a reverse proxy. Changing service access is discouraged and can lead to security issues or unexpected behaviour).
https can have a little performance penalty.
Don’t know, could a vulnerable service sniff or ex-filtrate traffic from another one?
Thank you both!
Short recap:
)EDIT
Turns out we do not need a certificate for the daemon aslong the deamon uses http.
(resulting commit)