Problems serving using spdy module over SSL

[sread]

Trying to serve this role over SSL. I copied the entire "owncloud_nginx_server:" block from /vars/main.yml and added the following:

ssl: True
redirect_to_ssl: True
ssl_crt: /path/to/crt
ssl_key: /path/to/key

I can access the login screen properly over HTTPS, and everything is nice there, but as soon as I put in the username/password, the little login spinner just goes around. I can't find any errors in any logs that relate to this (although I'm new to nginx). If I put in a wrong password, it knows.

Help?

[drybjed]

I presume that you don't use debops.pki role for certificates. Can you show the generated nginx configuration?

[sread]

No, I don't use the debops.pki role on purpose (yet! Waiting for ACME ;) ) but I think it still does some stuff with DH parameters. Anyway, other SSL sites work fine.

Another data point that makes me sure it's something nginx/php related: when I enable both the http(s) sites (redirect_to_ssl: False), I still can only log in on http, but once I've authenticated and moved on to index.php/files address, I can switch the https server. It seems like the login POST to index.php is getting dropped on the https server.

I've attached the nginx file, with the domain replaced with "example.com"
cloud.example.com.conf.txt

[drybjed]

One of the things that comes to mind is the blocking of dotfiles in nginx, ownCloud uses /.well-known/ addresses, maybe that's something to do with it... You could try removing it and checking if it works, if yes then it could be disabled by default.

DH parameters are probably handled by debops.dhparam role - nginx seems to have detected it and used accordingly. I don't expect that to be an issue.

What happens if you remove redirect_to_ssl: True from your config? If you use ssl: True, or even by default nginx role sets the configuration so that HTTP is redirected to HTTPS. This is detected automatically if you use debops.pki. But for the other case when it's not present, nginx might not work right...

[sread]

It can't be the dotfiles since everything works fine over http with the same dotfiles blocking.

I had tried redirect_to_ssl: False, as described above (and True, originally).
If I remove that setting entirely, the default is not obvious but it does seem to generate the http site with a 301 redirect to https. To be clear, the https connection to index.php works properly until I attempt to log in.

One final data point, on chromium I get a This web page is not available: ERR_SPDY_PROTOCOL_ERROR when trying to login but google tells me this is just a general site not working error when SPDY is involved. Turning off the nginx spdy setting has no effect I can see.

[drybjed]

Not much more I can help with this... Do you do this on Debian? Did you try it with "full" DebOps, PKI and all, just to see if it works then?

[sread]

Thanks for your ideas! I'll keep banging away at it and report back if I figure it out. I think this role should be SSL enabled (probably default) so I'll work towards that.

[sread]

I did some more digging around the project, and found debops/ansible-nginx#71 (comment) and now I understand what you meant by "full" debops. Apparently by missing the bootstrap_domain variable, I am missing out on some nice stuff! I'll try it.

As an aside, that comment (verbatim, probably) would make a great "Getting started" guide of sorts. A lot of the ones I've found scattered around the project are conflicting / inaccurate / wrong.

[drybjed]

I'm working on updates to the general playbook documentation, since it was written a while ago.

I think one of the hard to solve problems with project like DebOps is that some specific parts, say, HTTPS enabled in a webserver, depend on other parts, in this case a set of X.509 certificates present on a host. Without the certificates nginx will fail to start after enabling them in the configuration, but on the other hand it's perfectly OK for a webserver to work with only HTTP available, for example as an application server behind load balancer. And the issue is not that the certificates are available or not, the issue is that if you create a set of self-signed certificates (like many, many tutorials on the web do), it's still useless in multi-host environment like DebOps because other hosts don't trust them.

The debops.pki role was created to solve that chicken-and-egg problem of untrusted certificates. (NB, working on a new version if you want to check it out). It automatically creates a set of valid certificates using central CA authority with other hosts under your control trust, and that lets them work together over encrypted connections from the start. You can (or will be in the near future) easily switch from "internal" certificates to "external" certificates, that are trusted by the general userbase if you want, and all your applications will hopefully "just work".

But, to do its job, debops.pki needs to either be configured beforehand, or it expects a working DNS domain on a host. Without the domain known by the role certificates generated by it will be worthless, so if it doesn't detect a valid domain, it does not generate the certificates automatically. Other roles will work just fine without them, but some functionality won't be easily available.

So the whole relationship chain is something like, DNS -> debops.pki -> X.509 certificates -> debops.nginx -> HTTPS website. This is probably very obscure without knowing about all these relationships, and if you accidentally or intentionally break one part of the chain, weird things might happen. I'm trying to make this easier, a better documentation and perhaps some tutorials could go a long way, but it will take time.

What I'm getting here at is, DebOps roles are meant to work together, it is intentional. If you try to use them separately, they will most likely work, but using them together gives you definitely a better experience. As they say, the whole is more than just the sum of its parts.

[sread]

Okay, now that I've drunk the full pki koolaid ;) I revisited this issue. I also learned that spdy module binds per-socket on nginx. If I (manually) remove the spdy module from all listen 443 server blocks, this issue is no longer present. This is obviously not a permanent solution but I'll update this issue when/if I find the root cause.

For reference, the following browsers fail in some way after successful owncloud login:

• Firefox 43
• Chromium 46
• Mobile Safari 9.2.1

This browser works:

• Epiphany (Web) 3.18.3

[drybjed]

@sread So... Just for kicks, I've set up a host with ownCloud, MariaDB, nginx 1.6.2 from Debian Jessie with enabled spdy and ran full DebOps playbook on it. I can login to ownCloud using Chromium 47 from Debian Jessie, over HTTPS (the CA certificate isn't even trusted), install applications, upload files, basically everything works...

Did you try it with basically full DebOps playbook, or just custom set of roles?

[sread]

That's my setup exactly...
I think I'm now using a basically full DebOps debops -l host configuration, but originally I didn't have the domain and pki stuff set properly. My only major change at the moment is disabling ferm as I haven't gotten that working with my weird VPS yet, but I don't see how that could affect things.

Thanks for going the extra mile, I'll poke around at this again when I have some time.

[ypid]

@sread Any updates?