Setting up SSL with my domain name and Discourse instance


#1

Hey there, I’ve been spending a few days trying to get my Discourse site running exactly how I’d like it, but I’ve run into some problems along the way. I’ll do my best to outline the issue below, but please forgive me if I do a poor job explaining anything.


What I’d like to accomplish:

  • Create an SSL certificate using Let’s Encrypt and access my site by navigating to https://example.com or https://www.example.com

Some notes on my installation of Discourse:

  • I am currently running Discourse on a VirtualBox instance of Ubuntu 16.04.1 server.

  • I can access the site from outside my home network through port forwarding using a different port other than 80 (My ISP blocks 80). An example of what I would navigate to is: 34.7.74.33:123

  • I purchased a Google domain and linked it to my Discourse site. I’ve been able to access it by www.example.com:123, but never without including the port.

  • I’ve tried redirecting the domain name to my public IP. Like: example.com -> 34.7.74.33:123 which allows me to access the site without using the port, but it doesn’t keep the domain name, it’s just a redirect.


What I’ve tried:

  • My ISP hasn’t blocked the https port (443), so I would like to certify my site in order to utilize that port. It’s my understanding that if I use https as the protocol, it will automatically try to use that port.

  • I’ve edited my app.yml to include all of the information specified in the howto tutorial for using Let’s Encrypt with Discourse.

  • After trying various configurations of my domain settings, I always get the error “…Verify Error:Could not connect to …”

  • When I ls -l the ssl folder, I have had different results. Sometimes one file is created, sometimes all three, but one constant is that the .cer file is always empty/missing.

I realize there are a lot of points in this topic, but if anyone has suggestions for any of the aspects, I would love to hear them! Thank you for reading :slight_smile:


(Matt Palmer) #2

You’re not going to be able to use the built-in Let’s Encrypt support, since that relies on being able to talk to your site on port 80 (that’s how Let’s Encrypt validates domain control). You could get a certificate issued from Let’s Encrypt by hand, using the DNS domain control validation method, but that won’t be automated (meaning you’ll need to do it again, by hand, every couple of months), and we can’t provide any support for your attempts to make it happen.


#3

Thanks for the reply! That is extremely useful info that will help me from running around in circles. I’ll look into the “by hand” certification method. It may not be ideal, but it sounds like it might be might the best option with my current setup. Thanks again!


(James Mc Mahon) #4

Are you setting up SSL for security reasons, or the performance benefits of HTTP2 (previously SPDY)?

If it’s the latter you can use cloudflare’s free package to handle SSL + HTTP2 along with providing caching for some static assets closer to your users. You also get to masquerade the IP address of your server behind their nameservers.

The connection from cloudflare to your server will still be unencrypted, so in this scenario it should be considered for performance only, not encryption of data from your server to your users.


#5

The main purpose of the SSL in my mind was to attempt to get around the problem of having port 80 blocked by my ISP. I was hoping I could channel everything through port 443 by getting an SSL. I may be way off in my understanding of how this all works, but that was my original intention. Security was definitely a strong second reason.

I’ve found some promising potential solutions, and Cloudflare is written down as something I need to check out.

This is something that is very important to me, so that’s fantastic if it ends up working the way I would need it to.

In the end, I would love to have performance benefits, security, and mask my the IP of my webserver using the domain name I purchased, but we’ll see if I can pull all that off. I’m learning as I go :slight_smile:

Anyway, thanks for pointing me to Cloudflare! I’ll reply to this page or edit my initial post with whatever I end up settling with just in case it’s helpful to others down the road.


(James Mc Mahon) #6

I’d highly recommend installing on an inexpensive VPS from linode or interserver, rather than messing with a consumer internet connection.

We’re running discourse on a VPS from Interserver. Paying for two “slices” as they call them. Base install of discourse has run great so far. I picked KVM emulation, installed docker + discourse on centos (their ubuntu image was giving me headaches with updates so I switched to centos). I’m paying 16/mo right now. They have a $6mo package with 1GB of memory. Not ideal, but would probably get you going.

Linode might work our cheaper as you can power down the units to save money, somewhat like AWS\GCP etc.


#7

My concern is with scaling. I’m glad these cloud servers have that ability, but I suspect it can get out of hand. It would be way less than ideal, but I can probably manage to spend the $240 a year it would take to run a solid instance of Discourse on Digital Ocean. But there are all kinds of variables I just don’t know about.

I want to run a small private photography forum with about 8 members. Sharing and maintaining high quality photos for the life of the forum will end up taking a toll on the base storage restrictions of these cloud servers, even within the first year. In contrast, I can buy a few 1-2TB physical hard drives for a home web server and it would be a one-time cost that should last for a very long time.

The monthly payments and the additional costs when you reach your limits with the cloud hosting makes me nervous. I don’t have an income that allows for a ton of flexibility right now and I’ve made it a pretty solid decision that I don’t want to ask my members for money toward hosting.

If I break it down to a worst-case scenario of storage:

  • Each photo posted is 12MB
  • A member posts 80 photos in a photo-oriented topic
  • There are 80 photo topics a year
  • That would make for ~76GB of storage adding up a year.

I don’t know exactly if/how you can manipulate where attachments are stored with Discourse, but if the files need to be on the same “drive” as the Discourse instance, I would have to change to the $80 a month plan at Digital Ocean within the first year. Maybe there are ways of scaling the SSD storage that I’m not fully grasping, and if there are, I would appreciate any pointers on how that works.

The bottom line in my logic is that it seems like a much more stable and cost-effective method to do all of this with my own hardware, but maybe I am incredibly naive and would be in for a world of hurt with this method.


(Rafael dos Santos Silva) #8

You could use block storage with some symbolic links and so, but for a Photo Centric I would just use a shared Google Photos Account for $1.99 a month and link photos in the board, that would run in the cheaper plan I could find.

Looks like Google Photos Onebox just fine. And I have lovely dogs :dog: .

EDIT: I think that Flickr also works. They give a LOT of space nowadays.


(James Mc Mahon) #9

Ah, your assets (photos) should not be on the same server as your Discourse install in cases like that… and yes you could be in for a world of hurt if your computer gets damaged/fails, gets stolen, motherboard takes out both drives (it happens!) etc etc.

You should be using a cloud storage solution like Amazon S3. You’ll have more available bandwidth for your users when they upload/download simultaneously as well as built-in fault tolerance. You can even go a step further and periodically backup assets on to Amazon Glacier. And/or you could setup home box to keep a copy of what’s in S3 as well.

The great news is that discourse supports S3..

So, move your Discourse install onto a VPS (with or without SSL, up to you), configure S3 and feast your eyes on the awesomeness.

Lastly, you can also configure your Discourse installation to backup to S3 as well.