Nethserver-discourse, Let's Encrypt, and SSL

Hi all,

On LOCAL VMs, I have 2 installations of Discourse: one with nethserver-discourse and one with standard Discourse.

For the nethserver-discourse, I followed exactly: (2 times for 2 installations)

The VM with nethserver-discourse displays:
image image

The VM with standard Discourse does not display such warning.

I compare the 2 configurations and found that nethserver-discourse is missing 2 folders:
image image

For a test, I wanted to try to copy the missing folders from the standard Discourse to the nethserver-discourse.

In nethserver-discourse, I just created a folder letsencrypt and went into it.
To my surprise, even if I didn’t copy nothing yet, the folder was filled up with the same sub-folders as the standard Discourse.

In nethserver-discourse, I created a folder ssl and went into it.
Same thing, it filled up by itself.

I rebooted the nethserve-discourse and no more warning, all is OK.


What am I missing ?


1 Like

need to check, dicourse comes from the docker container that is not in my hand

Salut @stephdl

With the creation of those folders, the keys have changed, I cannot login anymore into discourse.


Deux problèmes, deux fils de question sur le forum michel (two issues two forum threads michel)


Salut @stephdl

I created a new post: Nethserver Docker and option --restart unless-stopped



Je vais regarder cette histoire de discourse, Je vais voir si j’ai le temps, je pars bientôt en vacances :smiley:

I am going to check your issue but I am not sure I have the time because I will be in holidays soon

Hi @stephdl,

It is related to the name of the certificate keys:
cert.pem / privkey.pem
cert.crt / cert.key

# ln -s cert.crt cert.pem
# ln -s cert.key privkey.pem

Then activate https in Discourse -> Security

No more security warnings.

Bonnes vacances ! :slight_smile:



# ls -ls /etc/pki/tls/certs/cert.pem
0 lrwxrwxrwx 1 root root 8  8 juil. 15:29 /etc/pki/tls/certs/cert.pem -> cert.crt

# ls -ls /etc/pki/tls/private/privkey.pem
0 lrwxrwxrwx 1 root root 8  8 juil. 15:31 /etc/pki/tls/private/privkey.pem -> cert.key


server {
    listen 443 ssl http2;  listen [::]:443 ssl http2;
    server_name;  # <-- changer ici

#   ssl on;  # <-- OBSOLETE
    ssl_certificate      /etc/pki/tls/certs/cert.pem;  # <-- changer ici
    ssl_certificate_key  /etc/pki/tls/private/privkey.pem;  # <-- changer ici

Most important:

# reboot
1 Like

Slaut @stephdl,

Sorry to ruin your vacation, but my solution works only with standard Discourse.

With nethserver-discourse, after activating https, I can no longer log in. It says the cookies are not enabled.


Salut @stephdl,

Just to keep you informed.

I am still working on the warning in the URL when accessing Discourse with Firefox or TOR.
There is no warning with Chrome.

If you login with 2 different browsers:

  • With the first browser, enable “force https”. Refresh the page. The warning disappears but you’re no more able to login.
  • On the second browser, disable “force https”. Go back to the first browser, you are able to login again.

It looks like it is related to the SSL configuration in zzz_discourse.conf for Apache.
I tried both .crt and .pem; same problem.

If you use nginx, there is no such warning in Firefox.

I will try to find out more info on SSL config for Apache and let you know.

Continue having a nice holiday in the canyon :slight_smile:


Hi all and especially @stephdl on holiday in the canyon,

After 3 weeks of struggle: installation, reinstallation, standard Discourse, nethserver-discourse, Apache disable / Nginx, Nginx only, HAProxxy, Apache only, I finally found the cause of the warning in the URL bar and the unable to reconnect after “force https”.

With standard Discourse:

The warning in the URL bar is due to the installation of the Logo

  1. It is absolutely necessary not to install the logo when connecting to Discourse for the first time.

  2. You must install the logo only after the configuration is complete with Settings → Branding.

  3. To correct the situation:

  • Remove logo in Settings → Branding.
  • Reinstall the logo in Settings → Branding.

Not able to login is due to Apache

In the file: /etc/httpd/conf.d/zzz_discourse.conf, just before the line ProxyPass, add this line:

 RequestHeader set X-Forwarded-Proto "https"

Restart Apache

# systemctl restart httpd

‡ It should be the same with nethserver-discourse and NGINX /etc/nginx/conf.d/zzz_discourse.conf

force https

  • Settings → Security → activate “force https”.
  • Finally reboot to make absolutely sure everything is working perfectly.

image Complete victory, let us raise the banner of victory.

An how-to will follow soon,


Hi all and especially @stephdl on holiday, if he is out of the canyon, :wink:

For Nethserver-Discourse

After a backup snapshot, restart the VM

Wait at least 2-3 minutes to let time for clamd to finish.
Wait at least another 2-3 minutes to let ruby start Discourse (there are 4 ruby running for discourse).

FILE: /etc/httpd/conf.d/zzz_discourse.conf

ProxyPreserveHost On
ProxyRequests Off

# Add those 2 lines to be always able to login
RequestHeader set X-Forwarded-Proto "https"
AllowEncodedSlashes NoDecode

ProxyPass / unix:/var/discourse/shared/standalone/nginx.http.sock|http://localhost/
ProxyPassReverse  / unix:/var/discourse/shared/standalone/nginx.http.sock|http://localhost/

Restart Apache:

# systemctl restart httpd
# systemctl status httpd  |  grep Active

Clear caches

  • Station:

    ipconfig /flushdns

  • Browser:
    History → Clear Recent History…


  • Login

  • Configuration → Parameters → Security → Activate “force https”
    Refresh page - warning is still there => normal because of the “Branding icons”.

  • Configuration → Parameters → Branding
    Delete “logo” -> click the green check mark to activate the suppression
    Delete “small logo” -> click the green check mark to activate the suppression
    Repeat if more logos.
    Make sure there are no more logos.
    Download a new “logo” -> click the green check mark to activate the new logo
    Download a new “small logo” -> click the green check mark to activate the new “small logo”
    Repeat if more logos.

  • Logout
    The page refreshes to display the home page, there is no more warning in the URL bar.

Reboot, clear caches, and login to be absolutely sure that all is running perfectly.


Use 2 different browsers to login; if you have problems after activating “force https”, you can use the other browser still logged in to deactivate it.

released in my rpm thank

1 Like
1 Like

About X-Forwarded-Proto, We could release a prop that enables the additional headers. The prop can be enabled by default starting from 7.10. I’d avoid a new UI checkbox because the new default behavior shouldn’t harm in 98% of cases :crossed_fingers:

RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
RequestHeader set "X-Forwarded-SSL" expr=%{HTTPS}

Current template:

Also X-Forwarded-For, X-Forwarded-Host and Forwarded are interesting :thinking:

1 Like

Thanks to Stephane we have now this new enhancement!

@michelandre, @quality_team: could you test it? You can find QA instructions here:


Hi @davidep and @stephdl,

Thank you for this improvement, it is appreciated.

Correct me if I’m wrong:

  • X-Forwarded-Proto => to pass the protocol i.e. https originated from SOURCE (client) to DESTINATION (LOCAL host)
  • X-Forwarded-For => to pass the IP address of the SOURCE to DESTINATION
  • X-Forwarded-Host => to pass the hotname of the SOURCE to DESTINATION

So those directives take care of the “Header” of the packet.

I think I have the same kind of problem - packet received by the Proxy is different from the packet received by DESTINATION. The Proxy “plays” with the packet before relaying it.

In my problem with Matrix-Synapse packet received, the packet is “canonized” before being relayed, meaning that any character %40 is replaced with @ and %3A with :

EDIT: If this packet contains a URL, itself containing the above characters, when it is received by DESTINATION it isn’t what is expected.
REF:, especially the post of richvdh.

To resolve this new problem, you have to give the option nocanon.

      ProxyPass /_matrix nocanon

Can you also implement such a directive’s option ?


P.S. Can you please give the CLI command to install/test the new directives.


Normally, mod_proxy will canonicalise ProxyPassed URLs. But this may be incompatible with some backends, particularly those that make use of PATH_INFO. The optional nocanon keyword suppresses this and passes the URL path "raw" to the backend. Note that this keyword may affect the security of your backend, as it removes the normal limited protection against URL-based attacks provided by the proxy.

1 Like

Hi @stephdl,

Martin gave me full acces to his Chat installation and I compared all the configurations with mine.
All are the same except he is running it hosted at some place meaning that it is directly connected to the Internet with nothing in front of his Chat server.

My installation is running on a LOCAL VM and my main NS server redirects all related URL/PORT to the LOCAL server.

As answered on a forum where I asked for any suggestions to resolve the problem:

… your logs showed that something upstream of your server (Apache, presumably, or possibly Cloudflare) was replacing %40 with @ in the request URI of incoming requests (and %3A with : ), hence invalidating the signature made by the sending server.

I suspect that it is my main NS server redirections that are replacing the %40, the %3A, etc… characters but I don’t know if it is the URL or the Port redirections doing it.

I checked /etc/httpd/conf.d/virtualhosts.conf and nowhere there is a nocanon directive parameter.

Since my main server is quite full of all kind of modules/applications which are all working correctly, I don’t want to do a mistake by changing an unappropriate parameter.

Usually, nocanon goes after the retry=30 as in the line below.

ProxyPass  / max=3 retry=30 nocanon

I have a few redirected URL.

Where do you think I should insert the nocanon for the corresponding lines?
Should I modify with a custom template and which ones ?
Will it affect all other vhosts I have, like mediawiki, etc ?

Thank you in advance,


in that case I would simply drop a apache reverse proxypass virtualhost in /etc/httpd/conf.d/myproxyCannonNeeded.conf