How to make ocsigen-start https only?

Hi !
I have installed ocsigen-start on a distant server for deployment testing. I could run it (but js and css files did not load. According to my browser console, I assumed this was because cookies were not secure, but I am not sure now) over 80 port. Then I created a key and a valid ssl certificate (using certbot).
Following configuration instructions there, I edited ocsigenserver configuration file adding


and uncommenting <securecookies value="true" />.
I modified default PORT variable from Makefile.options from 80 to 443 (default port for https).
I built again the project with

make all
sudo make install

and I could not connect in https to the site. (a request in http was immediately rejected while a request in https was timing out after a while, with my browser console warning 6 cookies will be treated as cross-site from my app url as the scheme does not match (in French : Le cookie « eliomservicesession|S|||userindep » sera bientôt traité comme un cookie intersite vis-à-vis de « » car le schéma ne correspond pas.).

I found nothing interesting in logfiles.
Here is the server console output when I launch the server in case it is useful:

[WARNING] Running as root is not recommended
==== The website is available at http://localhost:443 ====
ocsigenserver.opt "-v" -c /usr/local/etc/app/app.conf
ocsigenserver.opt: ocsigen:config: While parsing config file, tag <host>: No defaulthostname, assuming it is "ip-some_ip.internal"
ocsigenserver.opt: ocsigen:main: Ocsigen has been launched (initialisations ok)

I also tried to add attribute protocol="HTTPS" to port setting in file, without success.
Do you have any hint of what could be wrong with it ? (What I want is running the app https only, so if you know how to redirect http request to https with ocsigenserver I take it also :slight_smile: )
Have a good evening !

I would recommend using Nginx or something similar to do SSL termination. For a proper deployment you’ll need a reverse proxy anyway, so might as well set it up now.


Thanks for your answer @yawaramin ! I am not familiar with this, but after searching on use of reverse proxies, it looks like it has value when several servers are involved (,, I set up an MVP, on a single server, and when I will need to increase capacity, my cloud provider have ssl facilities for their load balancing service, so I think I wont need a reverse proxy (at least for ssl). Of course I can set it up on my single machine, and then on every one, but I do not see the benefits of it. Maybe I am wrong ?

If your cloud provider gives you SSL termination out of the box, then turn it on and problem solved :slight_smile:

A reverse proxy is needed for things like:

  • Load-balancing requests to multiple instances of your server
  • SSL termination
  • Caching responses
  • Compressing responses
  • URL rewriting
  • And many other production use cases.

In order to get this I have to add a load balancer, and I find it is overkill for a single little MVP server (with built in ssl support) that will take time to get a lot of requests. Moreover, ocsigenserver supports compression, url rewritting, and ssl.

However, I am about to learn about how to set up NGINX to perform this because I have not that much alternative for now, thank you for giving me this :slight_smile: (you are right, I will need it some day, I just prefer to launch things fast)

As long as ocsigenserver supports ssl, if someone has a clue on how to fix it, I still take it :wink:

Thanks a lot for your insight on nginx @yawaramin. I realize I could not appreciate how valuable was this advice at the time you gave it to me, but it is really what I needed.

For people that wonder (like I was) why one would set up a common reverse proxy like nginx for SSL/TLS stuff : because it is far more easier (or barely possible) to set a secure TLS suite and to keep it up to date than with ocsigenserver that lacks documentation about this (and probably some features), among other advantages.

Best !

1 Like

Hi, it’s a nice coincidence–I recently wrote a post on common system architecture issues that I come across, and I even included a section on SSL termination which strongly echoes what you said:

1 Like