How to enable https support

[anantagati]

How to enable https support

[omega8cc]

Nothing special, but a few steps:

1. Goto /admin/hosting/features and enable SSL and Nginx SSL modules
2. Goto /node/2/edit and change nginx to nginx_ssl
3. Wait until Aegir will reverify server and hostmaster platform
4. Goto /node/8/edit and choose "Enabled" for Encryption.
5. Wait until Aegir will reverify hostmaster site.
6. Now you can access it both with http and https self signed certificate.

[anantagati]

Thank you for quick response.

I am just reinstalling server with newest version of your script. Will try it after.

[linuxgeneral]

I am having a new problem with SSL

There are no errors on very but when I restart nginx I get:

li71-22:/var/log/nginx# /etc/init.d/nginx restart
Restarting nginx: [emerg]: bind() to 74.207.229.22:80 failed (98: Address already in use)
[emerg]: bind() to 74.207.229.22:80 failed (98: Address already in use)
[emerg]: bind() to 74.207.229.22:80 failed (98: Address already in use)
[emerg]: bind() to 74.207.229.22:80 failed (98: Address already in use)
[emerg]: bind() to 74.207.229.22:80 failed (98: Address already in use)
[emerg]: still could not bind()
nginx.

[obrienmd]

linuxgeneral: I think this is due to nginx not killing all processes upon restart... I've noticed this as well (lots!). Maybe we need a new bugfixed version of nginx. If I run a killall nginx as root, nginx will start just fine, but if I try to restart the service, it tells me it can't bind.

[linuxgeneral]

nginx is segfaulting.

I found these errors on console. I am going to reboot and take a better look at the system logs on startup.

li71-22:~# warning: process nginx' used the deprecated sysctl system call with 1.33. nginx[12494]: segfault at 8378 ip 000000000040f7a7 sp 00007fffc4ccd150 error 4 in nginx[400000+7d000 ] warning: processnginx' used the deprecated sysctl system call with 1.33

[linuxgeneral]

killall nginx and starting nginx worked for me and i had to run it after a verify on any ssl site to get it working.

In addition I think the certificate directory should be shared for all instances to allow for wildcard and multi domain certs to be used without requiring and additional IP

on reboot I still get:
Starting nginx: warning: process `nginx' used the deprecated sysctl system call with 1.33

[omega8cc]

This "deprecated sysctl system call" is irrelevant and "correct" (I mean, by design) see: http://marc.info/?l=nginx&m=120428158303541&w=2

Right now it appears that Debian Lenny secure updates (only for contrib and non-free) are broken for all and install can results with unexpected errors, not related to Barracuda and Aegir.

We need to temporarily change (and rewrite already installed) our /etc/apt/sources.list file for Lenny, since the errors are now on both 32 and 64 bit.

We will confirm when the workaround is ready to use (it is tested now).

Also, the nginx init script is now much better (Barracuda replaces it on upgrade), so standard reload and restart should work without issues.

As for SSL - please open separate issue.

[obrienmd]

Yeah I think the sysctl is not an issue, of course. Omega, are you saying that you've updated the script w/ a new init script that will solve the manual kill requirement when restarting nginx?

[omega8cc]

The new init script should work better. However on every site create/verify it runs reload, not a full restart, so not sure if that can still affect SSL related changes.

[linuxgeneral]

Shared SSL cert and secure login is now enabled "out of the box" (including chive).

We can now skip the 6 steps listed above.
Thanks to a quick turnaround on this issue:
http://github.com/omega8cc/nginx-for-drupal/issues/issue/65/#comment_419303
and here:
http://drupal.org/node/872064

[stevenwood]

Looking for a few bits of advice...

Just did a update, and noticed the certs Common Name was *.$_THISHOST and I'm not sure how to change it or if I should.

I can access chive via https, but I can still access it via http, unlike aegir which is being forced to https.

[omega8cc]

Hello,

To replace self signed certs with your own, real certs, run this:

cd /etc/ssl/private
cp -af nginx-wild-ssl.crt nginx-wild-ssl.crt-old
cp -af nginx-wild-ssl.key nginx-wild-ssl.key-old
cp -af your-crt-pem-file nginx-wild-ssl.crt
cp -af your-key-file nginx-wild-ssl.key
service nginx restart

Only hostmaster instances have forced SSL now, while both Chive and Collectd are by design available in http and https mode.

Kind Regards,
Matt
http://omega8.cc

[linuxgeneral]

Here is how I got multiple verified certs working for individual sites with the SSL features enabled.

As this this is work in progress it may be subject to change.

Note: You should always test this on a non production server and have tested restoring your backups files before trying this on a live production site.

1. Goto /admin/hosting/features and enable SSL and Nginx SSL modules
2. Goto /node/2/edit add any additional IP addresses and change nginx to nginx_ssl
3. Wait until Aegir will reverify server and hostmaster platform
4. Edit your site and choose "Enabled" for Encryption and specify the certificate name.
5. Wait until Aegir will reverify hostmaster site.
6. Now you can access it both with http and https self signed certificate.
7. Log in as your Octopus user and cd to the location of your signed certs.
8. cp -af your-crt-pem-file /data/disk/(your-octopus-instance)/config/ssl.d/(your-certificate-name)/openssl.crt
9. cp -af your-key-file /data/disk/(your-octopus-instance)/config/ssl.d/(your-certificate-name)/openssl.key
10. Reverify the site and your site should now have your new certificate installed

[zkrebs]

In this model does each SSL enabled site need to be running on an Octopus instance?

[linuxgeneral]

No, A single instance can manage multiple domains and certificates.

I am currently using separate instances for user access privileges to the sites file system.

[linuxgeneral]

Keep in mind that this is all work in progress. Omega8 contrib is ahead of agier core. We are kicking the tires as we go on this bleeding edge.

I believe this is the future of Drupal.

Posting results will help with documentation.

[arielqgold]

Is a separate IP address needed for each domain with a SSL?

[linuxgeneral]

A separate IP is needed for each installed certificate. Multi domain and wild card certificates will allow for additional domains and sub-domains on the same cert. (not supported by IE6)

For $49.00 you can get unlimited certs at: http://www.startssl.com/

[stevenwood]

Although aegir can create a self signed cert, after step 7, I did this to create a new self signed certs with my own info (just so it looks nice)

$cd /data/disk/(your-octopus-instance)/config/ssl.d/

$ openssl req -new -nodes -keyout myssl.key -out myssl.csr

fill in form

$ openssl x509 -req -days 365 -in myssl.csr -signkey myssl.key -out myssl.crt

Continue with step 8..

"Posting results will help with documentation."

Every thing worked fine for me, with no problems until I ran out of IP's.

Then I decided I should actually try and get the Octopi to have individual certs with their own IP - which was a bit disastrous (but fun).

I can get mydomain.com to appear with the generic under construction page
but octopus.mydomain.com comes up saying unable to connect to server.

I know that this DNS stuff is all work in progress but was wondering how you got it working linuxgeneral http://github.com/omega8cc/nginx-for-drupal/issues/issue/73

[arielqgold]

@linuxgeneral

Looking at your 10-step instructions above:

If I have barracuda installed on server.example.com and octopus at octopus.example.com and want to install a 3rd-party verified SSL cert on a site that is on the octopus instance, do i do steps 1 and 2 on octopus.example.com ?

[linuxgeneral]

@arelqgold

Yes, and also for each hostmaster instance that manages sites that would use the 3rd-party certificate you installed. As could be the case for wildcard or multiple domain certs.

One thing to note that as of Alpha14, the hostmaster instance will not be aware of a cert that it not create. To configure an existing certificate for an additional hostmaster instance, type in the certificate name in the "New encryption key" field of the create site screen while "Generate a new encryption key" is selected. Your existing cert will then be available on future new site installs for that host master instance.

You also have to be careful not to generate certificates that you don't have IP addresses for nginx to bind the cert with. in some cases I have had manually delete certificates because nginx would not start on boot.

@omega8cc

Where should i open this issue?

[omega8cc]

I can't reproduce it. I was able to restart the Nginx, reboot the VM w/o any issue while using global self-signed cert/SSL proxy and valid true certs for sites managed in Octopus instances on the same (one) IP. I tested it with Safari, Chrome, Opera and FF on a Mac. Please open a new issue and include more details so we could analyze it better.

[omega8cc]

Also, when using true, signed certs, I recommend to add a self signed certs in Aegir first and then only replace the content of those files, without touching its filenames etc.

[arielqgold]

i purchased valid certificates and got it working after chatting with omega8cc, without multiple ip addresses, but a separate octopus instance for each domain with a ssl cert.

Only one problem, which I'll file a separate issue for: In some browsers, including the factory browser on my Droid X and IE6, I get a security warning that the cert doesn't match the domain name. Somehow those browsers are picking up the wildcard cert for *.myserver.mydomain.com and not the individual, valid cert.

[linuxgeneral]

@arielqgold
Yes and if you use a wild card or multi domain cert they can be used in multiple Octopus instances and domains. You just specify the cert name when creating the site. You don't need an additional IP for that because the nginx binds that cert to the IP for you. As for the DNS entry I make 2 records because some name servers need it.
example.com or @
*.example.com

However, some browsers do not support it like IE6. be sure to view the offending cert in your complaining browser. You may see that it is the valid cert. if not you may have to append the key file supplied by your certificate provider to get it to work.

Don't forget to clear the stored self signed certs from your modern browser when you test it.

[linuxgeneral]

@omega8cc
Re: "I can't reproduce it."
From memory, It was when i misspelled the cert name while creating a site. The install failed because there was no IP's left and a certificate was created that i had to manually delete.

[linuxgeneral]

@omega8cc
Something new on todays upgrade:
INFO: Installing default SSL Wildcard Nginx Proxy, please wait...
==> WARNING!

We can't enable Wildcard HTTPS Proxy for all your hosted sites,
including all Hostmaster instances, because you have already
enabled SSL on the IP address used by your core Hostmaster instance.

If you wish to use provided now by Barracuda Wildcard HTTPS Proxy,
please disable the SSL you enabled, or use the built-in Aegir SSL
feature on another IP address available and not used by the Hostmaster,
and other hosted sites.

We will continue in 30 seconds...

I Unselected nginx on all Octopus servers and ran the Barracuda upgrade again. All platforms reverified and sites that were non SSL enabled are accepting SSL connections. Does this mean we now have a full SSL proxy?

If so this eliminates several steps above for at least first cert.

Nice work Grace!

[arielqgold]

@linuxgeneral

So you're saying I can somehow avoid getting IE6 or other browsers to give a security alert? Can you explain how?

Just to clarify, when I visit example.com (which has a valid cert installed per your instructions above) a security alert comes up saying it is a valid cert, but that it doesn't match the domain. Then when I view the cert I see that it doesn't show the cert installed for example.com but the wildcard cert *.aegirserver.mydomain.com
On most browsers, the connection is secure without any warnings, but not the "modern" browser on my very new Droid X or IE6.

[linuxgeneral]

If your commercial cert is for a single domain and configured properly IE6 will not complain.

IE6 will always complain about a wild card cert and all browsers will on self signed certs until they are installed in the browsers during the initial error,

Based on the recent update noted above, the install instructions will be much simpler.
I could be that we can just put the first one in /etc/ssl/private. I currently have this working.

A more detailed discussion is here:
http://github.com/omega8cc/nginx-for-drupal/issuesearch?state=open&q=ssl#issue/65

The other instructions above would now be for multiple certs and IP addresses but lets let omega8cc chime in with the intended use case.

[arielqgold]

If your commercial cert is for a single domain and configured properly IE6 will not complain.

That's good to hear. Do you think you can help me get there?
See https://test.choresheet.com
Connects without any issues on most browsers and when I view certificate it is for test.choresheet.com. Gives warnings on IE6 and browser on Droid X and when I look at certificate details shows *.aegir.mydomain.com not test.choresheet.com

[omega8cc]

Well, there is nothing like "the intended use case". Instead, we are listening your suggestions and trying to introduce some handy defaults.

In this case the basic concept is simple: every site can use HTTPS proxy (and you can replace its cert with your "valid" cert), while on the same server you should be able to use any number of certs enabled per site (and per Octopus instance) using Aegir built-in SSL feature. Plus, we are forcing SSL mode for all Octopus based hostmasters.

We are open to ideas on how it can be improved.

[linuxgeneral]

@arielqgold

Octopus is serving the certificate properly.
E = [email protected]
CN = test.choresheet.com
OU = StartCom Verified Certificate Member
O = Ariel Gold
L = Scottsdale
ST = Arizona
C = US

You may have to clear your browser certificates and cache.

Did you chain your cert from the Authority Certificates Repository? It is located here:
http://www.startssl.com/certs/
The proper forum for support on your issue is here:
http://forum.startcom.org/

[linuxgeneral]

@omega8cc

It looks like you have the ability for 2 modes or use cases for SSL.

1. A plain SSL enabled site, as is the default Aegir configuration. The drawback of this is that it is not a reverse proxy and SSL connections may lose much of the performance gains provided by Pressflow.
2. Like the path you on with the default config. The core hostmaster has, by default a main domain, wild card cert and reverse SSl proxy for all sub-domains. If the certs are handled by a separate server, the pressflow sites and octopus instances would not have to manage encryption because all packets would be unwrapped and delivered unencrypted. The drawback here is that this might have to be manged outside of Aegir for now.

I am considering using the default domain redirect for admin access to all domains by default. This would be a nice hosting feature to implement.

One question I have is: How can I set the sites to encryption required outside of aegir that will be supported by you in the future?

[omega8cc]

I have a feeling your are mixing some unrelated stuff here.

I'm not sure what you mean in the 1, the entire SSL stuff has no relation to performance delivered by Pressflow. Of course the HTTPS protocol is slower, but I don't understand how you see any difference between using a server wide HTTPS proxy and SSL enabled for site using Aegir SSL feature. There is also already enabled global SSL optimization for all SSL requests, and it doesn't matter if they go via proxy or via Aegir SSL enabled vhost. Remember: all vhosts and HTTPS proxy share the same Nginx engine and configuration.

The 2 is something I don't understand completely, could you explain it in more detail? Again, I have a feeling you are using some "shortcuts" in this explanation, which are not known to the reader and not obvious even for Barracuda author :)

Regarding forced/required SSL connections for only some URLs, there are modules to do just that, but there are known issues with such setups, fixed in d7 by using 2 cookies: plain and secure, so you can safely click between HTTP and HTTPS parts of your site and you will not loose the sessions and there is no risk your secure cookie will be sent over plain HTTP. In general, we should be always compatible with those solutions, since we operate on a low level here and entire sessions stuff must be managed properly on the app (Drupal) level.

See also:

http://drupal.org/node/1577
http://drupal.org/project/securepages
http://drupal.org/project/securepages_prevent_hijack
http://crackingdrupal.com/blog/greggles/drupal-and-ssl-multiple-recipes-possible-solutions-https
http://drupal.org/project/session443
http://www.slideshare.net/fourkitchens/is-drupal-secure
...the list can be much longer.

At any rate, at the Barracuda/Aegir/Nginx level we will always work on making things transparent when it comes to HTTPS, so you should be able to introduce/use your own preferred modules/tweaks on the app level. Of course some global stuff could be added in global.inc. Suggestions are more than welcome.

[arielqgold]

Even after purchasing a valid cert still having problems. This time it's with IE8 on xp where example.com gives a certificate error saying that that the cert for *.barracuda.mydomain.com doesn't match example.com

I don't need wildcard SSL, so I thought as a workaround to disable the wildcard cert might help.

Per omega8cc's instructions I removed /var/aegir/config/server_master/nginx/pre.d/nginx_wild_ssl.conf and commented out forced SSL in /var/aegir/config/includes/global.inc lines 35-38

Then I got a cert error, this time complaining that the cert for example2.com doesn't match the site name example.com. So I tried to login to octopus to disable encryption on example2.com, but I still get redirected to https, confirm a security exception, and get a 403 error on https://octopus.mydomain.com/install.php. So I put the wildcard cert back, uncommented lines, logged into octopus, disabled encryption on example2.com, got rid of wildcard cert, recommented lines, and finally IE8 doesn't give any errors with a https connection on example.com.

This workaround seems like it will only allow you to have a single site working with SSL, and breaks UI of octopus.

[omega8cc]

This is probably because IE doesn't support TLS/SNI on Windows XP - see: http://en.wikipedia.org/wiki/Server_Name_Indication#Browsers

[arielqgold]

OK. Is there a way to support Windows XP?

I came across this: http://nginx.org/en/docs/http/configuring_https_servers.html
which says, "A common issue arises when configuring two or more HTTPS servers listening on a single IP address...The oldest and most robust method to resolve the issue is to assign a separate IP address for every HTTPS server"

Will adding ip addresses fix the issue?

[omega8cc]

Since Win XP doesn't support TLS/SNI, you need to add more IPs (as separate servers nodes in Aegir) or create separate Octopus instances for every SSL enabled IP/domain.

Of course adding more ssl enabled servers with separate IPs on the same Aegir instance is much easier to manage, while using separate Octopus is really not good idea in this case.

[arielqgold]

you need to add more IPs (as separate servers nodes in Aegir

I logged into barracuda instance at aegir.mydomain.com and did create content -> server:
title: s1.mydomain.com
ip: separate ip address
mysql: none
web: nginx

Then the verify fails with:

• array_key_exists(): The second argument should be either an array or an object verify.provision.inc:28
• /var/aegir/config/includes could not be synced to remote server s1.mydomain.com. Changes might not be available until this has been done. (error: ssh: connect to host s1.mydomain.com port 22: Connection refused rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7])
• An error occurred at function : drush_provision_drupal_pre_provision_verify

I have ssh on a nonstandard port not permitting root login. I have two ip addresses pointed at the same physical server and wasn't anticipating needing to remotely access it. I suspect I added the server incorrectly. What am I doing wrong? Does it need to remotely access the same machine?

[omega8cc]

Adding only web server can cause unexpected results like this one. Try to add another server with same settings for mysql server. Previously also adding more IPs to the existing server worked (without creating another) but then they changed http to listen on wildcard instead on IP for Apache and I'm not sure how it is expected to work in the future. We need to test it better.

[zkrebs]

If I add a new server with a new IP address, how do I move a site to use SSL from that server?

[omega8cc]

This is probably a good question to post/add to the docs on the Aegir community site, since it is not a Barracuda/Nginx specific.

[zkrebs]

I answered it myself, I basically copied the platform from the primary Barracuda server to the new Octopus instance with its own IP, and then copied my site folder over, de-activated the old site, and then added the platform in the Octopus UI. It recognized my site afterwards, verified it. Changed the site to use nginx_ssl and had it make a new key for me. Bougth a SSL certificate, and then copied my certs into the placeholder that AEgir sets up, and re-verified. Seemed to work ok. Now, possibly this was insanely dumb and slow way, but hope it helps a lost soul.

Feature request? Migrate a platform + a site of choice on it to another instance of Aegir (Octopus)

[omega8cc]

Migrating platforms/sites between Octopus instances is already on our wish list and todo. Thanks for sharing your how-to.

[zkrebs]

Q? is this necessary https://github.com/omega8cc/nginx-for-drupal/blob/master/docs/SSL.txt - I really appreciate the help, but at the top it recommends Aegirs built in SSL handling..

If I have

Barracuda Instance - Hosting one SSL Enabled Site
webserver: aegir.mydomain.com

and then, an Octopus Instance - Hosting One SSL Enable Site
webserver: aegir.mydomain.com

if the Barracuda webserver aegir.mydomain.com has 2 IP addresses listed, will Site A and Site B get SSL certs delivered properly?

I'm experiencing an issue where the Barracuda Instance site is receiving the certificate for the Octopus site. Ideas here? Again, thanks!