Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nginx HTTPS with Let's Encrypt SSL certificates #43

Open
zejdad opened this issue Aug 18, 2020 · 5 comments
Open

nginx HTTPS with Let's Encrypt SSL certificates #43

zejdad opened this issue Aug 18, 2020 · 5 comments
Assignees

Comments

@zejdad
Copy link

zejdad commented Aug 18, 2020

First of all, many thanks for the fine docker image!

Please, do you have a recommended way how to serve taiga by https with certificates obtained from Let's Encrypt?

I suppose I will have to

  1. set TAIGA_SCHEME=https in .env

  2. edit docker-taiga/container-files/opt/taiga-conf/nginx/nginx.conf.j2

Official instructions may serve as a good starting point for this:
https://taigaio.github.io/taiga-doc/dist/setup-production.html#_taiga_hardening_https

However, I will have to add the details for Let's Encrypt certificate renewals at least in the nginx config.

  1. install and configure certbot within the taiga container.

I still have to figure out how to perform this last step the right way due to my limited experience with docker.

Please, am I right with the procedure? Or do you have any relevant recommendations? Clear instructions would be truly appreciated!

Wishing you all the best.
David

@blackandred
Copy link
Contributor

blackandred commented Aug 19, 2020

Hi,

I suggest you to setup an additional container with NGINX/Traefik and some container that automatically renewes LetsEncrypt certificates , that's the production-like way in DMZ-like architecture (you hide your services behind a NGINX proxy and expose them via gateway)

In few weeks I will prepare a Taiga installer with a just few commands to enter to get it working with SSL automatically - basing on https://github.com/riotkit-org/riotkit-harbor

@blackandred
Copy link
Contributor

blackandred commented Aug 19, 2020

Created an additional task for automatic prod-like environment setup based on compose: #44

If you are totally green with docker, then you can wait for this task to be done.

@blackandred blackandred self-assigned this Aug 19, 2020
@zejdad
Copy link
Author

zejdad commented Dec 1, 2020

Hi, Andrew,

thank you very much for your initial answer - besides all your fine work on docker-taiga!

Since the problem become more urgent, I had to resume my efforts to find a solution.

So, I configured a separate Apache (running on the same box but outside of docker) equipped with SSL certificates to act as a reverse proxy for taiga docker's nginx ( replaced by the actual taiga IP):

RewriteRule (.*) http://<TAIGAIP>:80/$1 [L,P]

In riotkit .env config I changed only:

TAIGA_SCHEME=https

and restarted everything. Now I can access the taiga instance via HTTPS, nice!

However, the following problem is resisting my efforts:

One user thumbnail picture is still being requested by taiga source via HTTP (though eventually loaded by HTTPS because of the Apache proxy intervention), leading to the "mixed content" browser complaint about HTTP mingling with HTTPS.

What is weird - all other contents, including all other image thumbnails, are being loaded via HTTPS. The problem persists even with cache disabled completely by browser developer tools.

In the subsequent investigation, since I don't have the credentials of the user whose picture is causing the problem, I even tried to remove any reference to this particular misbehaving picture straight from the database (tables users_user, thumbnails_thumbnail, thumbnails_source - I did not find it being mentioned anywhere else). However, the picture is still being loaded, leading to "mixed content", aargh. Why so, if it is no longer referenced by the database? Could some kind of server-side cache be in play?

When I tried to remove the image physically from the docker volume, still it is being asked by taiga program, leading to 404 error reported in browser developer tools in addition to the "mixed content" browser complaint. 404 is understandable, but no progress regarding the problem.

Furthermore, the misbehaving image is not used anywhere on the page - it relates to a user associated with a different project than the one being shown.

This is the part of browser developer console stacktrace related to the HTTP fetch attempt:

attr @ jquery.js:4103
ke @ jquery.js:141
attr @ jquery.js:4103
(anonymous) @ app.js:26994
...

It is pointing to app.js file, the modules/user-settings/notifications.coffee section, namely to:

module.directive("tgUserNotifications", UserNotificationsDirective);

UserNotificationsListDirective = function($repo, $confirm, $compile) {
  var link, template;
  template = ... (removed)
  link = function($scope, $el, $attrs) { <---- this line

Please, do you have any idea how to solve the problem?

Regards,
David

Since I am not sure if the problem is more docker-taiga or taiga related, I posted the question also to taiga google group: https://groups.google.com/g/taigaio/c/k_oYAKNIIQ8

@marshalleq
Copy link

To cap this off, I use a docker container with NGINX / Letsencrypt built in. It handles multiple domains, multiple hosts / single host, VLANS and the likes and is all well maintained by a 3rd party so you don't have to. https://docs.linuxserver.io/general/swag I highly recommend it. I can share my specific config if anyone wants it.

@marshalleq
Copy link

marshalleq commented Aug 14, 2021

Have come back here trying to find solutions for nginx reverse proxy stuff - their (as in Taiga's) documentation and response on the topic is pretty lacklustre to say the least. I really wish they'd put some actual forums in rather than google groups too. Anyway, I'm sorry for slightly hijacking this thread - can you tell me which of these two scenarios you run?

Custom NGINX --> TAIGA NGINX --> TaigaFront OR
Custom NGINX. --> TaigaFront

Where custom NGINX is on a different host to taiga.

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants