gitea using a normal user and https - ssl

I am trying to setup gitea to use https with a certificate I got from letsencrypt running the service as a normal user.
I already got it working with http on port 80 with a normal user git and redirecting port 80 to port 3000 using iptables.
Also I already got it working with https on port 3000 redirecting to port 3080.
But I can't figure out how to configure it (maybe along with iptables) so that requests to port 80 redirect to the appropiate port (3000? 3080?).
I redirect the port 80 to port 3000 using this iptables command as root:
# iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3000
And this is the relevant part of my configuration for HTTP
RUN_USER = git
LOCAL_ROOT_URL = http://localhost:3000/
DOMAIN = example
HTTP_PORT = 80
ROOT_URL = http://example.com
This is my configuration for HTTP on port 3000 redirecting to port 3080
RUN_USER = git
PROTOCOL = https
LOCAL_ROOT_URL = https://localhost:3000/
DOMAIN = example.com
HTTP_PORT = 3000
REDIRECT_OTHER_PORT = true
PORT_TO_REDIRECT = 3080
ROOT_URL = https://example.com
CERT_FILE = /etc/letsencrypt/live/example.com/fullchain.pem
KEY_FILE = /etc/letsencrypt/live/example.com/privkey.pem
With this configuration I can visit https://example.com:3000 and it works fine but if I visit https://example.com:3080 I get an Secure Connection Failed with Error code: SSL_ERROR_RX_RECORD_TOO_LONG.
I tried to redirect the port 80 to port 3080 using iptables but it didn't work.
Can you help me set it up so I can run the service as normal user in port 80 so that people can visit it at https://example.com ? (maybe using iptables as root beforehand to redirect some ports) Thanks in advance

In case someone else need it here is the final configuration file is this, it redirects http requests to https.
I used # setcap cap_net_bind_service=+ep /path/to/binary/gitea as ptman suggested.
RUN_USER = git
[server]
PROTOCOL = https
DOMAIN = example.com
HTTP_PORT = 443
REDIRECT_OTHER_PORT = true
CERT_FILE = /etc/letsencrypt/live/example.com/fullchain.pem
KEY_FILE = /etc/letsencrypt/live/example.com/privkey.pem
SSH_DOMAIN = example.com
DISABLE_SSH = false
SSH_PORT = 22
OFFLINE_MODE = false

The port for HTTPS is 443. Most people would solve this by using a reverse proxy, not iptables.
Gitea can handle letsencrypt itself. Here's how:
[server]
PROTOCOL=https
DOMAIN=git.example.com
ENABLE_LETSENCRYPT=true
LETSENCRYPT_ACCEPTTOS=true
LETSENCRYPT_DIRECTORY=https
LETSENCRYPT_EMAIL=email#example.com
Taken from: https://docs.gitea.io/en-us/https-setup/

The letsencrypt api is included in gitea. To setup gitea with docker-compose and let's encrypt just edit your [server] configuration like this:
....
[server]
APP_DATA_PATH = /data/gitea
DOMAIN = example.com
SSH_DOMAIN = example.com
HTTP_PORT = 443
ROOT_URL = http://example.com
PROTOCOL=https
ENABLE_LETSENCRYPT=true
LETSENCRYPT_ACCEPTTOS=true
LETSENCRYPT_DIRECTORY=https
LETSENCRYPT_EMAIL=info#foo.com
.....
and your docker-compose.yaml port configuration will look like this:
server:
image: gitea/gitea:1.13.2
container_name: gitea
ports:
- "443:443"
- "222:22"
....

Related

Let's Encrypt Unable to find a virtual host listening on port 80

■Background
trying to get SSL through Let's Encrypt
■Issue
As run the code below,
sudo certbot --apache -d hogehoge.com
I got the port 80 error
Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80.
and unable to resolve this error
■What I have tried
have set up the port 80
vim /etc/httpd/conf/httpd.conf
add the description in the file.
NameVirtualHost *:80
<VirtualHost *:80>
ServerAdmin root#hogehoge
DocumentRoot /var/www/html
ServerName hogehoge
</VirtualHost>
but I still got the same error.
would you kindly tell me the cause and how to make it work?
Default command "sudo certbot renew" error on localhost
(1)Uninstall certbot
(2)Reinstall certbot
(3)Sudo certbot certonly
(4)Select option 1, spin up temporary web server
(5)Ensure port 80 is accessible from outside, port forwarding in router
(6) Ensure all services using port 80 are stopped
Try
RewriteCond %{REQUEST_URI} !.well-known/acme-challenge
Enabling HTTPS on a Single Instance Beanstalk application: Unable to find a virtual host listening on port 80

configuring reverse proxy https with multiple certificates with Apache

I have the following setup:
one public IP
2 different domain names pointing to the same IP above: domain1.com and domain2.com
2 different ssl certificates: one for domain1.com and one for domain2.com
2 physical machines on the same LAN (192.168.1.10 and 192.168.1.20) running Apache2 and debian 8.5
I tested both servers indipendently forwarding the 443 port traffic to either of the machines. They work nicely.
Now, I am forwarding all port 443 requests arriving to the public IP to the first server at 192.168.1.10 and I would like this server to act as a https server for https://domain1.com and redirect the requests for https://domain2.com to address 192.168.1.20
I have tried to configure a reverse proxy in the first machine. It does redirect the requests for domain2 to the machine at 192.168.1.20 BUT it serves the certificate for domain1.
How can I configure reverse proxy as to present the right certificate for each one of my servers?
thank you in advance.
julia
Easiest "solution" (well, workaround) would be to use a single certificate that contains both hostnames. If you cannot do that, then you need to configure Apache SNI, like so: SSL with Virtual Hosts Using SNI
As some suggested I tried to use the Apache2 reverse proxy.
This somehow works but you have to install all the certificates on the machine running Apache2. Thus the trafic on the lan is no longer https which does not satisfy my requirement.
The solution is to use haproxy. This package can be set up as a pass through for https. There are many examples of such applications on the internet. It does exactly what I am asking for: I can host many https servers on a lan behind a nat router with one single public IP. The trafic is sent by haproxy as https to the indicated server on the LAN. If anyone is interested, I will be glad to share my config file solving precisely the problem I set out in my question.
To Robert M:
here is my configuration to be added at the end of the default haproxy.cfg file:
frontend ft_https
mode tcp
option tcplog
bind *:443
tcp-request inspect-delay 5s
tcp-request content accept if { req.ssl_hello_type 1 }
acl domain1_com req.ssl_sni -m end domain1.com # all url ending with domain1.com
acl domain2_com req.ssl_sni -i www.domain2.com # exactly www.domain2.com
use_backend b_domain1_com if domain1_com
use_backend b_domain2_com if domain2_com
default_backend b_default
backend b_default
mode tcp
option tcplog
server srv_default 127.0.0.1:1443
backend b_domain1_com
mode tcp
option tcplog
server srv_domain1 192.168.1.10:1443
backend b_domain2_com
mode tcp
option tcplog
server srv_domain2 192.168.1.20:443
I had to change the https port for apache on the first server to 1443 because both haproxy and apache cannot bind to the same 443 port as they reside on the same machine, but it is transparent to the user.

GET request with HTTP to port 80 results in connection reset or no response from server

I have a strange issue that the SSL connection for port 443 on my server is working fine, but when I look for the HTTP variant of my server it gives me the 'Site can't be reached connection was reset' error.
I have the following rules in my iptables:
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
The apache access_log does show an incomming request when requesting the site via HTTP, and the error_log does not show any errors
In my httpd.conf file I have:
Listen 80
My intention was to let all traffic go via HTTPS, so I have
<VirtualHost *:80>
ServerName www.example.com
Redirect / https://www.example.com
</VirtualHost>
However, it does not matter if I place this last block here or comment it - the server is not reachable via HTTP. I am on CentOS 6.7.
Edit:
When I do curl http://example.com, it returns cURL (52) Empty reply from server
However, when I check the apache http access_log for that cURL request, it returns
xxx.xxx.xxx.xx - - [02/Jun/2016:22:46:06 +0200] "GET / HTTP/1.1" 302 314 "-"
Which indicates that I should have received a HTTP response status 302 Found code as intended. However, I received nothing.
Any help or suggestions are welcome
Solved it. Apparantly there was another firewall on a higher level than the one on my server that was causing the problems.

What is correct way of forwarding Standard HTTP and HTTPS ports to another

I have a SSL server started on port 8080.
I want to redirect all browser requests to this port
from 80 (http://...) and from 443 (https://...)
Should I do
1) 80 forward to 8080; 443 forward to 8080 or
2) 80 forward to 443; 443 forward to 8080
Is there any difference in these approaches and what is correct?
Thanks!

SSL installed on Apache2 but HTTPS not working

I recently installed an SSL certificate on my Amazon EC2 Ubuntu 12.04(32bit) server running Apache 2.
When I attempt to access my site via https, it does not load. When I perform an nmap scan, i see that port 443 is not open.
I tried to open port 443 in my ip tables to no avail. iptables -L yeilds
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:https
Here's how I installed ssl
I modified /etc/init.d/apache2.conf to include ssl.conf and modified ssl.conf to include the requisite
paths of my certificate files, ie
SSLCertificateFile /path/file
SSLCertificateKeyFile /path/file
SSLCertificateChainFile /path/file
I configured my security group to allow inbound requests from port 443 (TCP source:0.0.0.0/0)
When I perform the following test with php
if (!extension_loaded('openssl'))
{
echo "not loaded";
}
else
{
echo "loaded" ;
}
I get "loaded".
Any ideas?
In httpd-ssl.conf, do you have
Listen 443
If not, try adding that, and restarting apache.
First check if mod_ssl is enabled. If not, enable it by running a2enmod ssl. Then check if Apache is listening on port 443 for https. Then check if the firewall is not blocking port 443.
If anyone else finds this and is using Amazon Lightsail (like me), you have to use their web UI to explicitly open port 443.
I spent hours pouring over my server config files before I discovered that :/
In httpd.conf the following is disabled by default:
# Secure (SSL/TLS) connections
# Include conf/extra/httpd-ssl.conf
Simply remove the # from the Include and restart Apache.
If you can connect locally (e.g. with telnet localhost 443 as mti suggests), check if the firewall is configured properly.
In my case, ufw was blocking everything, so I had to ufw allow 443 which fixed the underlying problem to the same symptom.
I just ran into a situation where there was a process listening on port 443, the firewall was completely open, SELinux was disabled, and I still couldn't telnet to port 443. Not even from the localhost. I kept getting:
telnet 127.0.0.1 443
telnet: connect to address 127.0.0.1: Connection refused`
It turns out the iptables NAT table had some rules redirect traffic coming in on port 443 to a different port (8443). Nothing was listening on port 8443.
# iptables --table nat --list
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
REDIRECT tcp -- anywhere anywhere tcp dpt:https redir ports 8443
Removing the relevant NAT entries fixed the problem for me.
For me it's the stupid Chrome cache. Ctrl + Shift + Del to clear the cache, restart Chrome, and SSL is correctly working now.
If the SSL keys are not set (or were inexplicably commented out by gremlins), Apache 2.2 SSL will silently fail. There will be no error in the log, and it will not be listening to 443. The http:80 sites will work.
First, Check processes on port "80" and "443" sudo netstat -peanut | grep ':80' and *sudo netstat -peanut | grep ':443'* .If 443 is has no process then this would help:
Editing the Apache configuration file to serve the cert works well.
Use the command sudo certbot --apache
You are good
Sometimes an iptables -F works. I had the port 443 open for inbound in Amazon, but still the site was not opening in my browser.
Logged on to the site, gave an iptables -F and immediately the site was accessible.