How to setup Gitlab EE with HTTPS on a DirectAdmin Server? - gitlab

I already have setup an Omnibus Gitlab server on my Centos7 VPS (DirectAdmin) using this post:
how to install gitlab on a directadmin server
It worked great with HTTP requests.
For security reasons I want to setup HTTPS on GitLab subdomain gitlab.domain.com.
I want to use LetsEncrypt free SSL certificates. The problem is LetsEncrypt can't authenticate my domain using Certbot:
certbot certonly --webroot --webroot-path=/var/www/letsencrypt -d gitlab.domain.com
It fails with output:
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: gitlab.domain.com
Type: unauthorized
Detail: Invalid response from
http://gitlab.domain.com/.well-known/acme-challenge/8Xj5vc-KMfhHYgH7PhXCFEetcxzQBDk-puiA2tRfoB4:
"<!DOCTYPE html>\n<html class=\"devise-layout-html\">\n<head
prefix=\"og: http://ogp.me/ns#\">\n<meta charset=\"utf-8\">\n<meta
content=\"IE"
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.
I googled for it and it seems LetsEncrypt have to reach a folder path:
http://gitlab.domain.com/.well-known/acme-challenge/xxxxxxxxxx
So I created the path and gave 777 permission and for test purposes put a test.html in it.
Now I have access to file using HTTP but I can’t get to it using HTTPS.
curl -I -k https://gitlab.domain.com/.well-known/acme-challenge/test.html
Output:
HTTP/1.1 301 Moved Permanently
Date: Wed, 06 Feb 2019 10:05:40 GMT
Server: Apache/2
Location: http://gitlab.domain.com/.well-known/acme-challenge/test.html
Content-Type: text/html; charset=iso-8859-1
I already have DirectAdmin on server and I can't figure out how to customize HTTPD.conf file of my subdomain so that everything works fine.
Custom HTTPD.conf section of direct admin:
ServerName gitlab.domain.com
ServerSignature Off
ProxyPreserveHost On
# Ensure that encoded slashes are not decoded but left in their encoded state.
# http://doc.gitlab.com/ce/api/projects.html#get-single-project
AllowEncodedSlashes NoDecode
<Location />
Order deny,allow
Allow from all
#Allow forwarding to gitlab-workhorse
ProxyPassReverse http://127.0.0.1:8181
ProxyPassReverse http://gitlab.domain.com/
</Location>
# Apache equivalent of nginx try files
# http://serverfault.com/questions/290784/what-is-apaches-equivalent-of-nginxs-try-files
# http://stackoverflow.com/questions/10954516/apache2-proxypass-for-rails-app-gitlab
RewriteEngine on
# Forward all requests to gitlab-workhorse except existing files like error documents
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_URI} ^/uploads/.* [NC,OR]
RewriteCond %{REQUEST_URI} !^.*/\.well-known/acme-challenge/.*$ [NC]
RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA,NE]
Alias /.well-known/acme-challenge/ /var/www/letsencrypt/
<Directory "/var/www/letsencrypt/">
Order allow,deny
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Allow from all
</Directory>
# needed for downloading attachments
DocumentRoot /opt/gitlab/embedded/service/gitlab-rails/public
It worth to mention that testing my domain using https://letsdebug.net/ with HTTP-01 and DNS-01 methods return that everything is OK.
I think if I could handle HTTPS requests to guarantee access of LetsEncrypt API to http://gitlab.domain.com/.well-known/acme-challenge/ URL over HTTP and HTTPS it will be ok.

As far as nobody respond to my question I worked on it and finally I found the answer.
Actually the problem was originated from two parts:
1.When you want to point to a path which contains special characters like '.', '\' or space in a string with a "..." you have to use it in '\.' format. I insist that it is applicable just in case you have a string surrounded by the double quotation marks not every parameters you have in your config file.
<Directory "/var/www/default/\.well-known/acme-challenge/">
So the correct form of Alias/Directory part is as below:
Alias /.well-known/acme-challenge/ /var/www/default/.well-known/acme-challenge/
<Directory "/var/www/default/\.well-known/acme-challenge/">
Options None
AllowOverride None
ForceType text/plain
RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)"
</Directory>
You may get a "HTTP/1.1 302 Found" not a "HTTP/1.1 200 OK" when you call the URL of the test file by 'curl'. It returns 302 cause you somehow redirects request to somewhere else than you really see in the address bar. But it is OK for LetsEncrypt domain authorization.
curl -I http://example.com/.well-known/acme-challenge/test.html
2.When you call for certbot or letsencrypt command, in the webroot parameter it must point to the root of your ACME challenge directory (/var/www/default/) not the end destination of the certs (/var/www/default/.well-known/acme-challenge/) cause the acmetool itself makes directory path in every webroot you provided to it. So the correct form of certbot or letsencrypt command for above Alias/Directory should be like below:
letsencrypt certonly --webroot -w /var/www/default/ -d example.com -d www.example.com --renew-by-default
or
certbot certonly --webroot --webroot-path=/var/www/default/ -d example.com
I'm very new to the Apache configuration but as far as I searched for the problem it is a very popular problem to those who want to use LetsEncrypt over an Apache server.
So forgive me if it an elementary question to most of you guys.
Enjoy!

Related

Why is my httpd.conf setup routing to https?

I have a number of domains, each one pointing to my server IP..
I've pinged each domain to check the DNS, That's fine, all domains are pointing to the correct server.
All my domains route through the httpd.conf correctly via HTTP, except one domain where for some reason the Http <Virtual: *:80> entry is forwarding to https: (https://preprod.testsite.org.uk) - For security, this isn't the real URL.
Why would this entry fail when the others are fine?
Is there some way of debugging or tracing through the request from the DNS through to the server, through to the httpd.conf?
<VirtualHost *:80>
DocumentRoot "/var/www/html/testsite/production"
ServerName preprod.testsite.org.uk
<Directory /var/www/html/testsite/production>
DirectoryIndex index.php
order allow,deny
allow from all
AllowOverride all
</Directory>
</VirtualHost>
DNS has nothing to do with HTTP to HTTPs redirection.
Test it using curl (-v option) and check if the server is sending a Location to the client telling him to connect over HTTPs.
If curl says there's no redirection to https, might be the application itself telling the client to connect over https OR, maybe, some entry in browser HSTS cache.

What should letsencrypt certbot-auto's "webroot-path" be for a non-PHP / non-static-files website?

In the case you have a website using Apache only (maybe with PHP) that is in:
/home/www/mywebsite/
/home/www/mywebsite/index.php
/home/www/mywebsite/style.css
then, it's easy to set certbot's --webroot-path:
./certbot-auto certonly --webroot --webroot-path /home/www/mywebsite/
--domain example.com --domain www.example.com --email a#example.com
Question: when using a website run by NodeJS
or Python Flask or Bottle, linked to Apache either with WSGI (mod_wsgi) or simple proxying (I know the latter is not recommended in the case Python)
RewriteEngine On
RewriteRule /(.*) http://localhost:5000/$1 [P,L]
what should --webroot-path be?
More specifically, if we have:
/home/www/mywebsite/ (Pyton example)
/home/www/mywebsite/myapp.py
/home/www/mywebsite/myapp.sqlite
/home/www/mywebsite/static/style.css
...
or
/home/www/mywebsite/ (NodeJS example)
/home/www/mywebsite/myapp.js
/home/www/mywebsite/myapp.sqlite
/home/www/mywebsite/static/style.css
...
then it doesn't make sense to choose --webroot-path as /home/www/mywebsite/, right?
Indeed, I don't want any other program/script like letsencrypt certbot to fiddle with my .py files.
Anyway, what does --webroot-path in certbot do? Will files there be analyzed, parsed?
Very interesting question that yet has a trivial answer. The official documentation states:
The webroot plugin works by creating a temporary file for each of your
requested domains in ${webroot-path}/.well-known/acme-challenge. Then
the Let’s Encrypt validation server makes HTTP requests to validate
that the DNS for each requested domain resolves to the server running
certbot.
So it doesn't really matter for Certbot where your actual webroot really resides as long it's served under domain you're trying to obtain certificates for, and it's not really interested in what is your project/framework structure is.
In other words, certbot does not require access to your project's directory with source files.
For example, Apache configuration for any application on your server can have shared so-called webroot, and Certbot only requires /.well-known/acme-challenge/ available as static directory where it can store challenge file on the server side that will be available for Certbot validation server:
Alias /.well-known/acme-challenge/ "/var/www/html/.well-known/acme-challenge/"
<Directory "/var/www/html/">
AllowOverride None
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
Require method GET POST OPTIONS
</Directory>
Same way it works for NGINX when setting for a particular server block configuration:
server {
location /.well-known/acme-challenge/ {
alias /var/www/html/.well-known/acme-challenge/;
}
}
Both examples would work if certificate is then requested with:
certbot-auto certonly --webroot --webroot-path /var/www/html -d domain.com
This is complementary information to DamagedOrganic's answer (full credit to him).
For certbot / Letsencrypt to validate a certificate, it has to be able to access a challenge/response URL like http://example.com/.well-known/acme-challenge/B39sdfoyoesdf21-qksl2638761867648514.
For this reason, it will create a temporary file (deleted at the end, that's why you won't find it anymore after a successful certbot) named .well-known/acme-challenge/B39sdfoyoesdf21-qksl2638761867648514 for example in the path given by --webroot-path. (Then Letsencrypt's servers will access the URL mentioned before in order to verify that everything is ok.).
Solution: Choose --webroot-path as the directory where static files are served. Example: if you have this structure:
/home/www/mywebsite/
/home/www/mywebsite/myapp.py
/home/www/mywebsite/myapp.sqlite
/home/www/mywebsite/static/style.css # /static/ serves static files...
/home/www/mywebsite/static/favicon.ico
...
then use
./certbot-auto certonly --webroot --webroot-path /home/www/mywebsite/static/
--domain example.com --domain www.example.com --email a#example.com
PS: this is a solution with Bottle (I think it would be similar with Flask):
#route('/.well-known/acme-challenge/<filename>')
def wellknown(filename): # Letsencrypt certbot-auto
return static_file(filename, root='./static/.well-known/acme-challenge')

Amazon Linux EC2 installing SSL (no connection)

I spent last 2 days trying to find the solution to my issue.
HTTP works fine http://jackrus.net, but HTTPS won't work.
1.I created an instance on Amazon Linux EC2.
2.Redirected my domain jackrus.net to my public IP
3. Opened listeners 443, 22, 80. (security groups)
4. Followed the instructions from aws documentation from here
5. Checked all permissions
6. apachectl -t - says syntax is fine.
7. Restarted the server. no problem here too.
Here is my ssl.conf
....
....
....
SSLCertificateFile /etc/pki/tls/certs/certificate.crt
SSLCertificateKeyFile /etc/pki/tls/private/private1.key
SSLCACertificateFile /etc/pki/tls/certs/intermediate.crt
...
...
...
The response i get here:
This site can’t be reached
jackrus.net refused to connect.
Try:
Checking the connection
Checking the proxy and the firewall
ERR_CONNECTION_REFUSED
You might need to add your virtual host to your http/config.d file
You can check what vhosts you have running like this:
apachectl -t -D DUMP_VHOSTS
Look up where your config could be
find /etc/httpd -name *.conf
then edit you config with vim or nano or whatever you prefer
vi /etc/httpd/conf/httpd.conf
Add your virtual host ( type i first to insert if in vim)
#Virtual Host added
<VirtualHost *:80>
DocumentRoot "/var/www/html"
ServerName "example.com"
ServerAlias "example"
RewriteEngine on
RewriteCond %{SERVER_NAME} =example
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
to save and exit:
:wq
then try restarting the server.
I also recommend the letsencrypt certbot-auto for a quick solution as it has a debug feature to tell you exactly what the error is. If you are using Letsencrypt then you sould look up the ACMEv1 to v2 upgrade or end of life cycle for ACMEv1

Nagios web interface access without slash at localhost

How can I access the Nagios web interface without using the slash on a local host?
For example, when typing the IP address i need to access nagios. In other words, I don't want to use the slash, as follows: 192.168.123.122/nagios
I think what you're looking for is a base URL redirect match within Apache.
With that, going to http://192.168.123.122 will redirect you to http://192.168.123.122/nagios
In the file:
/etc/apache/apache2.conf
Add the following lines
<Directory />
Options FollowSymLinks
AllowOverride None
RedirectMatch ^/$ /nagios
</Directory>
Restart Apache and you should be good to go.

SSL issue and redirects from https to http

I have a site www.example.com for which i purchased SSL cert and installed.
And it was working fine, I also have a subdomain with app.example.com which was not on SSL.
Both www.example.com and app.example.com are on same IP address.
At later we decided to put SSL only on app.frostbox.com and then i configured SSL with app.frostbox.com and it worked fine,
Now the issue is that Google is indexing my site as https://www.example.com/ and when users hits the web , Invalid security warning is issued and when user allow security issue they are shown my app.example.com contents.
Note: I have my SSL configuration files in /etc/httpd/conf.d/ssl.conf
The contents of the ssl.conf are below.
http://pastebin.com/GCWhpQJq
NOTE: I tried solutions in .httaccess but none of those worked. Like redirecting 301 redirects etc
Purchase a SAN-multi domain certificate. Issue the certificate to www.abc.com and add the additional SAN www.app.abc.com in and it will work.
Hopefully you are within the 30 day cancellation policy.
you need to edit your httpd.conf file or the file where your virtual host is specified and add these lines to redirect http to https:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Resources