SSL on Droplet with Wordpress and subdomain with Discourse

I’ve set up the one-click Droplet with Discourse in a subdomain and Wordpress as the default. Attempting to add SSL and I can only get WordPress to run under https. The SSL certificate is a wildcard cert from Namecheap (COMODO).

Before going any further I think I need to get the correct port for SSL on the subdomain.

With the server blocks shown below, actually shows

Nginx and Docker/Discourse are new to me, so I could use some help in figuring this out - Thank you!


server {
    listen 80 default_server;
    #listen [::]:80 default_server;

    # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
    return 301 https://$host$request_uri;

server {
	listen 443 ssl;

    server_name *;
    ssl_certificate /etc/nginx/ssl/*;
    ssl_certificate_key /etc/nginx/ssl/*;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
	root /var/www/html;
	index index.php index.html index.htm;

	location / {
		try_files $uri $uri/ /index.php?q=$uri&$args;

	error_page 404 /404.html;
    	error_page 500 502 503 504 /50x.html;
    	location = /50x.html {
        	root /usr/share/nginx/html;

    	location ~ \.php$ {
        	try_files $uri =404;
        	fastcgi_split_path_info ^(.+\.php)(/.+)$;
        	fastcgi_pass unix:/var/run/php5-fpm.sock;
        	fastcgi_index index.php;
        	fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        	include fastcgi_params;


upstream forum {
    server fail_timeout=0;

server {
      listen 80;

      root /usr/share/nginx/html;
      index index.html index.htm;

      client_max_body_size 10G;

      location / {
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header Host $http_host;
          proxy_redirect off;
          proxy_pass http://forum;


  - "8080:80"   # fwd host port 80   to container port 80 (http)
  - "2222:22" # fwd host port 2222 to container port 22 (ssh)
  - "443:443" #  (ssl)

By the way, would using two “Let’s Encrypt” certificates work instead of a wildcard certificate (since Let’s Encrypt doesn’t offer wildcards)?

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.


This is because your redirect is just a catch all redirecting anything that isn’t already defined. Since your is configured, the catch all doesn’t do anything; as it’s not needed. You want to update your server block from the forum to listen on 443. Then the default catch-all on port 80 should come into effect here.

I would save your configs and give that a test. As I’ve never done this exact setup, I’m uncertain if it will work. I have done it with docker in the past, just not with Discourse. So it should work, but I’m not 100% certain. If it doesn’t let me know and we can try to work through it.

As for let’s encrypt, yes, you can do that. You would just want to set the ssl_certificate and ssl_certificate_key paths for the forum sub domain.

I think some explanation of how nginx tries to route stuff will help here. You have the 2 catch all server blocks. One for forum and one for your default.

So when you type nginx checks for the server block (which you have), and routes it based on that block. If I put nginx is going to look for that, which you don’t have. So it defaults to the catch-all, which is the redirect. So it will redirect me to and check for that. Which you don’t have. But you have a catch all for that with the * server_name value. So it routes me to that.

If you modify things so that you have the server block listening on 443, it won’t get caught by the 443 catch all and will route to https properly. You just have to define the ssl_certificate and ssl_certificate_key paths in that block.

Then, since you removed the listen 80 for it will get caught by the catch all and be routed to https.

At least it should, if my quick testing of nginx routes was correct.