Support SSL #5

josh opened this Issue Mar 10, 2011 · 45 comments


None yet
josh commented Mar 10, 2011

Support SSL connections

danreedy commented Apr 7, 2011

node.js and Connect support serving SSL pages. I've forked the project and when I have a spare moment I'm hoping I'll have a chance to dig through the configuration and add SSL support.

For ease of use I think it's best to go with a wildcard certificate for *.dev or *.test. I'm thinking it'd be best to generate this during and save it to $POW_ROOT/SSL. The OS X command sudo /usr/bin/security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" $POW_ROOT + "SSL/certificate.pem" could be used to trust the certificate.

Those are my initial thoughts on the matter anyway.

josh commented Apr 7, 2011

I really didn't need this feature, I just thought it would be fun to play with node's ssl api.

Good point about the cert issue. I didn't really think about that. Hopefully we can make that setup painless.

danreedy commented Apr 7, 2011

SSL cert generation can be annoying and I'm not certain there would be an easy way to implement it in a manner where you aren't making the user type in their information (including the wildcard for the CN field). I wonder if including a "generic" private.pem and public.pem in the installation would be the wiser move.

I imagine most people wouldn't need this, but for ensuring SSL is functioning it would be a sweet option. Painless SSL? Unimaginable for most...


If Pow doesn't support SSL connections, how do 37signals devs run apps that force SSL connections like Campfire?

josh commented Apr 7, 2011

@danreedy Anyway we can generate one generic cert for everyone?

@joshpuetz Force ssl is disabled in development mode

ssoroka commented Apr 7, 2011

It shouldn't matter if it's one cert for everyone, you can generate certs like @danreedy suggested. Generate a sensible default that works and the user can overwrite them with legit certificates if they have them.


Supporting SSL out of the box would be fantastic.

danreedy commented Apr 7, 2011

There are obvious security concerns if you are sending out a default root certificate that has been trusted as an authority by anyone installing pow. If you can pass defaults while creating the cart it may work and work well.

On Apr 7, 2011, at 4:25 PM, wrote:

It shouldn't matter if it's one cert for everyone, you can generate certs like @danreedy has. Generate a sensible default that works and the user can overwrite them with legit certificates if they have them.

Reply to this email directly or view it on GitHub:
#5 (comment)


+1 on the SSL support, it's really the biggest reason why i would need something POW. it would instantly become my default server for development if it supported SSL.

danreedy commented Apr 8, 2011

Did a little leg work and I've created two public gists that are proof of concept for an auto generated self-signed multi domain ssl certificate.

The first gist would theoretically go into I currently have everything saving to the same folder but this could be modified to use a POW folder ($POW_HOME/SSL). This file generates the key and the certificate in one pass. The last step requires the sudo command and adds this new cert to the trusted roots keychain.

The Second gist is a example node.js https instance setup to be run in the same folder as the previous gist and serves up the self-signed cert.

Because the last step of the first gist makes the cert trusted, you should not receive any warnings on any .dev domains.

Now it's time to work it into POW.



mataki commented Apr 12, 2011



This would be really, really helpful.





josh commented Apr 17, 2011

@sstephenson This is going to be tricky. We're going to need to extend connect.HTTPSServer too. Somehow we'd need to move the code in pow.HttpServer into a mixin so we can share it between both classes.


In that case, we ought to use composition instead of a mixin -- it wouldn't make sense for the HTTPS server to have its own set of Nack workers.

josh commented Apr 17, 2011

Hrm, right, we need to worry about that too. Maybe we need an HttpHandler class.

HttpServer  -\                 /- RackApplication
              |- HttpHandler -| - NodeApplication
HttpsServer -/                 \- ProxyApplication

Does this fit into the EventEmitter emitter stuff you are already working on?

gvarela commented Apr 18, 2011

You can setup an SSL proxy through nginx until it is supported by pow.

Just follow these instructions:






+1 ... ssl support is the only thing stopping me from using pow.

On a side note, I'd love to hear more about the how and why of disabling ssl in development mode.


+1 SSL support would be awesome!

estoner commented Jun 6, 2011


ghost commented Jun 7, 2011

+1 I just began building an ecommerce function and now can't use my POW :-(


@blueheadpublishing Sure you can. If you use a middleware or before_filter to force SSL, just skip it when Rails.env is development. That's what we do for all our apps at 37signals.


@sstephenson that works great for apps that are wholly behind ssl, but not so much for sites that are a mix. I'm sure I'm doing it wrong, but I've always felt more comfortable with using real ssl in dev mode. I don't think I'm alone in that regard, but I'd love to be convinced otherwise.

josh commented Jun 7, 2011

Considering closing this issue. I don't really feel like working on it anymore.

No number of +1s is going to magically produce a working patch.

gvarela commented Jun 7, 2011

If you need SSL that bad just use an Nginx proxy as I linked to above. It takes ten minutes.


Yep, I'm with @josh on this one -- closing the ticket. If anyone wants to take a shot at implementing SSL, feel free to make a patch and open a pull request.

@sstephenson sstephenson closed this Jun 7, 2011

Zero-config SSL support (with self signed cert) built-in to pow would save time setting up dev machines and make it easier to get people to adopt pow over other more complicated setups!

cmer commented Dec 25, 2011


fred commented Jan 28, 2012

just use nginx from brew, add this config
and just edit the line that says server_name

server_name *.dev;

very easy steps:

  1. brew install nginx
  2. setup vhost file
  3. generate selfsigned ssl
    use *.dev as domain and full name when you generate the ssl.
  4. start nginx…

Installing and configuring nginx defeats the entire purpose of using a zero-conf app server. I quit using pow based on how slow bugs were being fixed and because once I had to install and configure nginx to support SSL, I realized it wasn't any harder to just use unicorn or thin than it was to use pow.

fred commented Jan 29, 2012

jeremyhaile, yes true, if you have a few apps.
If you have many apps, let's say, 40+ apps. it make things a lot lot easier, starting unicorn/thin for each app, creating the nginx vhost, reload nginx, setup host file domain.

otherwise in pow only need one command :)

$ ln -s ~/projetos/app43 ~/.pow/

jugyo commented Mar 7, 2012

My solution is here:
This is a proxy to http from https.


would really help now that Facebook requires https


fred: my point wasn't that pow isn't easier than nginx/unicorn - but rather that if I have to configure ssl with nginx, it isn't that much harder to just run with unicorn at that point. If pow would add ssl support, I could eliminate having to run nginx on my dev machine altogether.

cmer commented Mar 19, 2012

@paulnicholson I just tested this and it works very well. Thanks! I wish 37s would bundle your solution into Pow. I would be fine to have Stud as a dependency for SSL support.


thanks @paulnicholson, works great!


Thanks @paulnicholson your solution is very helpful!


thanks @jugyo, tunnels works like a charm though won't daemonize but that's not a problem.

$ gem install tunnels
$ rvmsudo tunnels

after which all traffic to 443 will pipe over to port 80 where pow's waiting to pick up.

...i did try stud but no go, though prefer the less invasive tunnels solution


Just in case somebody uses rbenv: :)

apsoto commented Mar 9, 2016

another option:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment