Using LetsEncrypt and Google webmaster tools with gitlab ce - ssl

I have used certbot to obtain SSL certificates. At that time ubuntu's default apache server was listening on port 80. Assume my server is accessible via example.com.
Now, I am running a GitLab CE 9.4.4 server using the SSL certificate I have obtained earlier with letsencrypt. In /etc/gitlab/gitlab.rb I same something like this
nginx['ssl_certificate'] = "/etc/letsencrypt/live/example.com/fullchain.pem"
nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/example.com/privkey.pem"
(and similar lines with registry_nginx for the docker registry.)
However, certbot renew fails, when it tries to renew my certificates, since /var/www/.well-known is not accessible via http://example.com/.well-known.
A similar problem arises, when one tries to use Google webmaster tools. The default verification process requires you to upload a file named googleXXXXXXX.html into the server's root directory.
How can GitLab be configures to server static files in .well-known and files starting with google?
(Unfortunately, a Google search containing gitlab and static files, produces results about GitLab pages.)

Via GitLab Webroot
The webroot of GitLab CE on Ubuntu is /opt/gitlab/embedded/service/gitlab-rails/public by default. You can copy the googleXXXX.html into this directory and point LetsEncrypt's webroot to this directory:
...
[renewalparams]
authenticator = webroot
installer = None
account = SOMEHASH
[[webroot_map]]
example.com = /opt/gitlab/embedded/service/gitlab-rails/public
Via GitLab Config
Configure LetsEncrypt
Open the letencrupt renewal configuration, e.g. /etc/letsencrypt/renewal/example.com.conf, and adjust the options, such that the web root points to /var/www/letsencrypt:
...
[renewalparams]
authenticator = webroot
installer = None
account = SOMEHASH
[[webroot_map]]
example.com = /var/www/letsencrypt
Create the directories /var/www/letsencrypt and /var/www/letsencrypt/.well-known. The latter directory will host the verification challenge files.
Configure Webmaster tools
Create the directory /var/www/google and download the googleXXXX.html it into the newly created directory.
Configure GitLab (for LetsEncrypt and Webmaster tools)
Open /etc/gitlab/gitlab.rb and add the following two lines.
nginx['custom_gitlab_server_config'] = "location ^~ /.well-known { root /var/www/letsencrypt; }\n"
nginx['custom_gitlab_server_config'] << "location ^~ /google { root /var/www/google; }\n"
Reconfigure your gitlab server by running
gitlab-ctl reconfigure
All requests, which start with /.will-known will now be forwarded to the /var/www/letsencrypt directory. Similarly, all requests starting with /google are forwarded to the directory /var/www/google. (Please note, that this approach makes users or group starting with google inaccessible. In this case you can change the gitlab config to include the full name of your googleXXXX.html)

Related

Why Lightsail bitnami after LetsEncrypy change index.html location

My Node.Js Bitnami Lightsail instance had its frontend code at /opt/apache/htdocs and http://example.com was working perfectly pointing to that directory (my backend located under opt/projects).
After executing Certbot LetsEncrypt my domain is now pointing to a different folder /var/www/html
Please advise on:
In certbot instruction page I choose Apache for "My HTTP website is running", there wasn't a Bitnami option, was that the right call?
Is this the right configuration and just move my code to html folder?
Does my backend code has to move too? if so where?
Any other well-known issues that I might face?
Cheers.
Bitnami Engineer here,
We do not have any guide to configure certbot and Bitnami, but we have a guide that helps you configure the Let's Encrypt SSL certificate using lego. We have a tool that configures everything so you do not need to worry about editing the Apache's conf files or setting the renew process.
sudo /opt/bitnami/bncert-tool
You can learn more about it here.
In case you want to manually create a SSL certificate, you can also run the lego tool directly
sudo /opt/bitnami/letsencrypt/lego --tls --email="EMAIL-ADDRESS" --domains="DOMAIN" --domains="www.DOMAIN" --path="/opt/bitnami/letsencrypt" run
You will later need to configure the Apache's conf files to use that new certificate file. You can learn more about it here
Note: If you used certbot and it modified the Apache's configuration, you will need to undo those changes to use the proper folder. You will need to review the /opt/bitnami/apache2/conf/httpd.conf, /opt/bitnami/apache2/conf/bitnami/bitnami.conf and /opt/bitnami/apache2/conf/vhosts/* files

Nginx certificate authentication of a specific location

Using Apache I created an HTTPS site that contains a folder called secure [which I want to access with user and password] and another folder called verysecure [which I want to access with certificate authentication].
When I access the site using https://www.example.com I get the default index.html file located in the root, as would be expected. When I access https://www.example.com/secure/ I provide the user and password and get the index.html file located in that folder. When I access https://www.example.com/verysecure/ the certificate popup window allows me to choose the certificate that I want to use and upon doing so I get the index.html file located in that folder.
How can I configure Nginx so that the certificate chooser pop up window comes only when I access https://www.example.com/verysecure/ and not when I access https://www.example.com/ or https://www.example.com/secure/ ?
According to this thread from official nginx development forum, you can't (although this thread is almost 10 years old, SSL/TLS re-handshake still doesn't supported by nginx). The only workaround suggested by Igor Sysoev is to use an optional client certificate verification
ssl_verify_client optional;
and then checking the $ssl_client_verify variable value:
location /verysecure/
if ($ssl_client_verify != SUCCESS) {
# deny client
return 403;
# or process the request on some internal location, see
# http://nginx.org/en/docs/http/ngx_http_core_module.html#internal
# rewrite ^ /internal last;
}
...
}
However using this workaround the certificate chooser window will popup (only for clients who had the correct certificate installed) on the initial TLS handshaking, not only on visiting the /verysecure/ URI.

How to configure nginx with SSL?

I am trying to configure ssl for the nginx load balancer , I see three different kinds of configuration files and I am not sure where the certificate and key file should be configured
These are
nginx/sites-available/default
nginx/sites-enabled/myDomain
nginx/nginx.conf
What are these configuration files? where should ssl be ideally configured?
It sounds like you don't know a lot about Nginx. I would start with the docs.
http://nginx.org/en/docs/
nginx/nginx.conf
This is the main Nginx config file and should not contain site-specific configurations (like SSL)
nginx/sites-available/default
This is where you configure your site (and your SSL settings). The default config is simply named "default".
nginx/sites-enabled/myDomain
This is the location that Nginx looks in for sites to serve to users. Typically, you create a symlink from here to the sites-available directory, like below.
sudo ln -s /etc/nginx/sites-available/yourconfig /etc/nginx/sites-enabled/
This allows you to easily activate/deactivate sites by just adding/removing a symlink.

How to disable Owncloud https redirect?

I installed Owncloud on Ubuntu 12.04 with an apache server. I use ssl for authentication but when sharing links and data it is cumbersome for the user to accept the self signed certificate. Is there a way to disable the automatic redirect to https? I did not see any related commands in the .htaccess file.
Thanks
SSL is enforced by the OwnCloud installation routine in your Web server as a rewrite rule. Unchecking the box in the OC FrontEnd won't help. This can be regarded as bug.
To change this, you will have to edit your Web server config. For instance, if you chose nginx as your Web server, uncomment the https rewrite rule in your nginx config file.
Open your config file in an editor:
sudo emacs /etc/nginx/sites-enabled/default
For Apache it should be somewhere in /etc/httpd/conf.d/ssl.conf
Comment out or change the lines containing (this is for nginx):
the server block containing the redirect
change listen 443 ssl to listen 80
ssl_certificate and ssl_certificate_key
fastcgi_params HTTPS on
Re-Read the nginx config files:
sudo kill -HUP `cat /var/run/nginx.pid`
For other servers see:
http://doc.owncloud.org/server/5.0/admin_manual/installation/installation_others.html
There should be a setting in the "Admin" section when logged in as administrative user ("Force SSL") for exactly that.

Google Sitemap Generator - set up HTTPS on Linux

i am new to site maps, and Google sitemap generator.
i am working on a test server and neither localhost nor live. its basically a local test server.
I have installed it and also enabled remote access and am now able to access the admin console using http.
the problem is i need to enable https as well.
when i try to access it through https, i get an "SSL CONNECTION ERROR".
i know that google's documentation on this topic says something like:
To set up HTTPS on Linux:
1.Edit the file /usr/local/google-sitemap-generator/conf/httpd.conf.
2.In the VirtualHost section, edit the SSL settings.
3.Save the file.
4.Restart Apache to effect the changes.
But in the file httpd.conf, there are no "SSL settings" for me to edit.
Can someone remove this 'vagueness' from the directions?
Thanks
I suppose, you have to add to /usr/local/google-sitemap-generator/conf/httpd.conf something like this (into virtualhost directive)
SSLEngine on
SSLCertificateFile /etc/google-sitemap-generator/server.crt
SSLCertificateKeyFile /etc/google-sitemap-generator/server.key
This link was helpful for me: http://groups.google.com/group/google-sitemap-generator/browse_thread/thread/a5b0575efad76328
In my case server.crt and server.key files were generated by openssl command (http://www.akadia.com/services/ssh_test_certificate.html).
Make sure mod_ssl is enabled in Apache (run a2enmod).