This will search the drupal.org issue queues across the various projects that make up the Aegir system. If there are no relevant results, please submit an issue there.
I prefer this workflow for an existing/third-party cert ..
In "New encryption key" enter the domain name for the site. (note- wildcards are not supported here, so I am using the site's main name. This key is going to be ignored/replaced) -- mytest.mydomain.com
On your server, cd to /var/aegir/config/server_master/ssl.d/mytest.mydomain.com/
Remove existing aegir-generated files (openssl.key, openssl.crt, receipt) or move them into a new subdirectory (I call this "self")
Place the original CRT, CSR, KEY and "bundle" .crt in this folder.
ln -s mytest.mydomain.com.key openssl.key
cat mytest.mydomain.com.crt >openssl.crt
cat gd_bundle.crt >>openssl.crt
Verify the site (or just restart the web server)
The key here is that your certificate and the CA's certificates can be in the same file if your certificate is first. This requires no special alteration of vhosts for support.
If we had the ability to copy/paste a server key and corresponding CRT into a site's edit screen, this would become much less painful. :)
Thanks for the comment...This workflow might solve my related issue (see my post in the discussion forum...). Fortuitous that you added this comment today...will give it a try, and modify the doc pages accordingly.
Here is yet another method of adding commercial SSL via Aegir when you have other non-Aegir sites using SSL on the same server as well.
The steps on node/29 for users with Commercial Certificate File(s) are mainly corrct for this situation, following are the caveats for making Aegir SSL work with non-Aegir SSL sites.When referencing node/29 conduct step 1 to generate the necessary folders. Skip steps 2-4 unless you need a CSR file. For step 5 symlink the files, examples below, rather than copying the files as these files will be shared between several sites.
We have an SSL certificate per server that is populated with Service Alternate Names (SANS) so we are not able to prescribe to Aegir's one IP address per cert methodology. Aegir also invokes the ssl_module prior to Apache's ssl.d conf file so that needed to be addressed as well.
Three files need to be modified, 1 in .drush/provision/http/ and 2 in .drush/provision/http/apache_ssl/
The two files that need to be modified in .drush/provision/http/apache_ssl/ to allow Aegir to exist alongside our other non-drupal SSL enabled sites.
<strong>File 1</strong><br> /var/aegir/.drushrc/provision/http/apache_ssl/vhost_ssl.tpl.php Remove the variable at the top of the script {$ip_address} and replace it with an * .
To further confound Apache, Aegir will insert an IP address for the NameVirtualHost causing Apache to issue a warning, as well as trying to reload the ssl module. To fix this the following further edits were made.
The other file that needs to be modified is .drush/provision/http/http.ssl.inc. You want to comment out the loop that checks for ip addresses.
Line 172
// try to assign one foreach ($server->ip_addresses as $ip) { //if (!provisionService_http_ssl::get_ip_certificate($ip, $server)) { touch("{$path}/{$ssl_key}__{$ip}.receipt"); return $ip; //} }
I would encourage you to either make these changes with a version control system in place or at least backup the original files in case you need to switch back to the original.
Finally, there is no need to copy keys and crts into the ssl directories for each site, simply symlink them as appropriate. In our case this looked like the following:
Don't worry if your symlinks don't point to anything, once you verify your site they will be transported to the proper server and the links will be valid.
Thanks for these details theMusician and the patch.. I feel this is a big step in the right direction for being able to run Aegir along side other sites on a single server..
I am planning on changing the way Aegir generates the .conf files so that it simply manages vhosts and doesn't try take over the config of the whole server.. Your changes help with that.. Now I just have to figure out how to allocate specific IP's to specific SSL based sites that I specify.. :)
I'm having an issue that I'm unable to figure out. Granted I have very limited experience with Aegir, and system administration. I follow these directions to the letter and everything looks fine but the sites I set up with SSL still do not accept any HTTPS traffic.
No error logs, no nothing....what I did notice is that a2enmod ssl enables SSL for apache, but it is not paying attention to the virtual hosts defined by Aegir. So I can visit https://example.com on that server if example.com is in the /var/www home as defined by the default_ssl sites in /sites-enabled and sites-available in the apache2 dir in /etc. anything in /var/aegir is not enabled for SSL despite the keys being generated correctly, and the virtual hosts aegir created being updated correctly.
If anyone can suggest something I would greatly appreciate it. I'm using Ubuntu 12.04 server with, as far as I know, everything installed and updated from the default 12.04 repos. Forgive me if this is a stupid issue, I'm just a bit too new to figure this out it would seem. Thanks for any help!
So I've done a lot of digging and found a pretty simple problem for my particular issue.
The root issue is that I'm using AWS to host this Aegir deployment and the IP address Aegir detects for itself in setup is all well and good for hitting traffic on *:80, however it is not valid beyond that. I'm guessing because it's just taking any traffic on that port. Regardless...there is another issue here
So this documentation doesn't mention setting NameVirtualNost *:443 in /etc/apache2/ports.conf which is because it seems Aegir, by default, wants to use IP to determine domain for SSL traffic? It took me a while to even check this because I assumed it was already doing this. Why is it preferred to use <VirtualHost ip_address:443 over <VirtualHost *:443? It seems much easier and less stressful (especially for folks on Amazon) to use name based SSL.
Anyway if anyone is having this same issue set that NameVirtualHost and then modify your domains in /var/aegir/config/server_master(or whatever)/apache/vhost.d to use *:443 instead of ip_address:443. Then it works as intended.
Of course if you re-verify a site that'll undo this so remember to redo it.
@theMusician - THANKS for the patch! Every time I verify my platform I have to manually edit and comment out the IP address on my AWS server for SSL to work, no longer now that I have your patch, sweet, thanks! --Tony
Documentation on initial SSL setup is pretty good, but what about a renewal? I really dont want to fix anything that doesnt need fixing. Aegir can be unforgiving when missing the small stuff:-) I cant exactly test this out on a staging site. Do I need to generate a new rsa key for a renewal? I'm using a wildcard cert on a single Linode server running CentOS/Apache, that hosts rabout a dozen Atrium sites through Aegir under individual subdomains under a single domain name.
If I need to upload something new, what folders do I put it in? And do I need to manually update all the virtual hosts of my existing Atrium sites, or will this happen automatically??? Here's where I'm at (with deer-n-headlights look).
I paid for the new SSL with godaddy, and downloaded 2 files
1. gd_bundle.crt
2. mydomain.crt
Inside var/aegir/config/ssl.d/godaddy I have the following files:
gd_bundle.crt (this one has 3 chained certs, but the one I downloaded from godaddy only has 2. Just leave the new one as is and upload it? Thoughts?)
openssl.crt (what I was planning to do is replace the contents of this file with what I have in mydomain.crt -copy/paste and upload it. Yes?)
openssl.csr (I alerted godaddy to use my existing csr during activation, so I'll do nothing here. Yes?)
openssl.key (I suppose this is the key generated the first time. Do I need to regenerate on a renewed SSL? Would rather not...)
info.txt (this file appears to be a public cert. I don't recall how it was generated, what should I do about this mystery? It starts like so:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
2x:67:z3:
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certificates.godaddy.com/repository, CN=Go Daddy Secure Certification Authority/serialNumber=123456
Validity
Not Before: Apr 16 22:18:16 2012 GMT
Not After : May 3 17:00:47 2013 GMT
Subject: O=.example.com, OU=Domain Control Validated, CN=.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:c0:1d:5a:07:98:42:b1:be:de:b7:20:b5:79:d2:
ae:3e:99:06:e3:4b:a8:fc:59:18:f1:3a:05:aa:50:
94:1f:64:71:9f:ea:90:eb:06:e9:1d:a0:89:00:a8:
No sweat. Here it is: Upload/overwrite existing gd_bundle.crt into the active ssl folder. Copy/paste the contents of domain.crt into the openssl.crt file. Make sure to put both files in ssl.d and servermaster/ssl.d. Restart apache & enjoy.
I'm quite confused how SSL works now in Aegir2 with IP's being allocated in the front-end. I posted a question about this at the end of move the SSL IP allocation to the frontend, but I'm guessing as this is a closed issue, it might slip below the radar. Any info on this or a pointer in the right direction is much appreciated.
Seems to be a bug (omission?) in Provision that ignores ssl chain files. I found that the vhost file wouldn't get updated with the SSLCertificateChainFile entry even when following the documentation. Perhaps I was doing something incorrectly but if I was, I never found it. In the end I ended up applying a couple patches, reverifying my platform and all was right with the world. I did have to remove some whitespace in between the two diffs in the patch but other than that it applied to provision 6.x-1.9 (bit of patch fuzz but otherwise ok)
#1
I prefer this workflow for an existing/third-party cert ..
In "New encryption key" enter the domain name for the site. (note- wildcards are not supported here, so I am using the site's main name. This key is going to be ignored/replaced) -- mytest.mydomain.com
On your server, cd to /var/aegir/config/server_master/ssl.d/mytest.mydomain.com/
Remove existing aegir-generated files (openssl.key, openssl.crt, receipt) or move them into a new subdirectory (I call this "self")
Place the original CRT, CSR, KEY and "bundle" .crt in this folder.
ln -s mytest.mydomain.com.key openssl.key
cat mytest.mydomain.com.crt >openssl.crt
cat gd_bundle.crt >>openssl.crt
Verify the site (or just restart the web server)
The key here is that your certificate and the CA's certificates can be in the same file if your certificate is first. This requires no special alteration of vhosts for support.
If we had the ability to copy/paste a server key and corresponding CRT into a site's edit screen, this would become much less painful. :)
#2
Jason...
Thanks for the comment...This workflow might solve my related issue (see my post in the discussion forum...). Fortuitous that you added this comment today...will give it a try, and modify the doc pages accordingly.
#3
SSL coexsiting with Aegir and non-drupal sites
Here is yet another method of adding commercial SSL via Aegir when you have other non-Aegir sites using SSL on the same server as well.
The steps on node/29 for users with Commercial Certificate File(s) are mainly corrct for this situation, following are the caveats for making Aegir SSL work with non-Aegir SSL sites.When referencing node/29 conduct step 1 to generate the necessary folders. Skip steps 2-4 unless you need a CSR file. For step 5 symlink the files, examples below, rather than copying the files as these files will be shared between several sites.
We have an SSL certificate per server that is populated with Service Alternate Names (SANS) so we are not able to prescribe to Aegir's one IP address per cert methodology. Aegir also invokes the ssl_module prior to Apache's ssl.d conf file so that needed to be addressed as well.
Three files need to be modified, 1 in .drush/provision/http/ and 2 in .drush/provision/http/apache_ssl/
The two files that need to be modified in .drush/provision/http/apache_ssl/ to allow Aegir to exist alongside our other non-drupal SSL enabled sites.
<strong>File 1</strong><br>/var/aegir/.drushrc/provision/http/apache_ssl/vhost_ssl.tpl.php
Remove the variable at the top of the script {$ip_address} and replace it with an * .
To further confound Apache, Aegir will insert an IP address for the NameVirtualHost causing Apache to issue a warning, as well as trying to reload the ssl module. To fix this the following further edits were made.
<strong>File 2</strong> /var/aegir/.drush/provision/http/apache_ssl/server_ssl_tpl.phpAlter the existing function to output NameVirtualHost *:443 and comment out the ssl_module routine
The file will end up looking like this
<?php foreach ($server->ip_addresses as $ip) : ?>
NameVirtualHost <?php print "*:" . $http_ssl_port . "\n"; ?>
<?php endforeach; ?>
#<IfModule !ssl_module>
# LoadModule ssl_module modules/mod_ssl.so
#</IfModule>
<?php include('http/apache/server.tpl.php'); ?>
The other file that needs to be modified is .drush/provision/http/http.ssl.inc. You want to comment out the loop that checks for ip addresses.
Line 172
// try to assign oneforeach ($server->ip_addresses as $ip) {
//if (!provisionService_http_ssl::get_ip_certificate($ip, $server)) {
touch("{$path}/{$ssl_key}__{$ip}.receipt");
return $ip;
//}
}
I would encourage you to either make these changes with a version control system in place or at least backup the original files in case you need to switch back to the original.
Finally, there is no need to copy keys and crts into the ssl directories for each site, simply symlink them as appropriate. In our case this looked like the following:
ln -s /etc/path/to/certs/certificate.crt openssl.crt
ln -s /etc/path/to/key/servername.key openssl.key
ln -s /etc/path/to/certs/bundle.crt sf_bundle.crt
Don't worry if your symlinks don't point to anything, once you verify your site they will be transported to the proper server and the links will be valid.
This is a patch that changes the provision files as outlined above. https://github.com/theMusician/aegir-wildcard-ssl/blob/master/.drush/sha...
#4
Thanks for these details theMusician and the patch.. I feel this is a big step in the right direction for being able to run Aegir along side other sites on a single server..
I am planning on changing the way Aegir generates the .conf files so that it simply manages vhosts and doesn't try take over the config of the whole server.. Your changes help with that.. Now I just have to figure out how to allocate specific IP's to specific SSL based sites that I specify.. :)
#5
This doc could be updated now that SSL is no longer listed under "Experimental"
#6
Important NOTE: Please note to this issue: http://drupal.org/node/1493286
This is a bug in hostmaster 1.7. And this tutorial won't work until the patch is applied.
#7
I'm having an issue that I'm unable to figure out. Granted I have very limited experience with Aegir, and system administration. I follow these directions to the letter and everything looks fine but the sites I set up with SSL still do not accept any HTTPS traffic.
No error logs, no nothing....what I did notice is that a2enmod ssl enables SSL for apache, but it is not paying attention to the virtual hosts defined by Aegir. So I can visit https://example.com on that server if example.com is in the /var/www home as defined by the default_ssl sites in /sites-enabled and sites-available in the apache2 dir in /etc. anything in /var/aegir is not enabled for SSL despite the keys being generated correctly, and the virtual hosts aegir created being updated correctly.
If anyone can suggest something I would greatly appreciate it. I'm using Ubuntu 12.04 server with, as far as I know, everything installed and updated from the default 12.04 repos. Forgive me if this is a stupid issue, I'm just a bit too new to figure this out it would seem. Thanks for any help!
#8
So I've done a lot of digging and found a pretty simple problem for my particular issue.
The root issue is that I'm using AWS to host this Aegir deployment and the IP address Aegir detects for itself in setup is all well and good for hitting traffic on *:80, however it is not valid beyond that. I'm guessing because it's just taking any traffic on that port. Regardless...there is another issue here
So this documentation doesn't mention setting NameVirtualNost *:443 in /etc/apache2/ports.conf which is because it seems Aegir, by default, wants to use IP to determine domain for SSL traffic? It took me a while to even check this because I assumed it was already doing this. Why is it preferred to use <VirtualHost ip_address:443 over <VirtualHost *:443? It seems much easier and less stressful (especially for folks on Amazon) to use name based SSL.
Anyway if anyone is having this same issue set that NameVirtualHost and then modify your domains in /var/aegir/config/server_master(or whatever)/apache/vhost.d to use *:443 instead of ip_address:443. Then it works as intended.
Of course if you re-verify a site that'll undo this so remember to redo it.
#9
@theMusician - THANKS for the patch! Every time I verify my platform I have to manually edit and comment out the IP address on my AWS server for SSL to work, no longer now that I have your patch, sweet, thanks! --Tony
#10
Documentation on initial SSL setup is pretty good, but what about a renewal? I really dont want to fix anything that doesnt need fixing. Aegir can be unforgiving when missing the small stuff:-) I cant exactly test this out on a staging site. Do I need to generate a new rsa key for a renewal? I'm using a wildcard cert on a single Linode server running CentOS/Apache, that hosts rabout a dozen Atrium sites through Aegir under individual subdomains under a single domain name.
If I need to upload something new, what folders do I put it in? And do I need to manually update all the virtual hosts of my existing Atrium sites, or will this happen automatically??? Here's where I'm at (with deer-n-headlights look).
I paid for the new SSL with godaddy, and downloaded 2 files 1. gd_bundle.crt 2. mydomain.crt
Inside var/aegir/config/ssl.d/godaddy I have the following files:
Certificate: Data: Version: 3 (0x2) Serial Number: 2x:67:z3: Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certificates.godaddy.com/repository, CN=Go Daddy Secure Certification Authority/serialNumber=123456 Validity Not Before: Apr 16 22:18:16 2012 GMT Not After : May 3 17:00:47 2013 GMT Subject: O=.example.com, OU=Domain Control Validated, CN=.example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:c0:1d:5a:07:98:42:b1:be:de:b7:20:b5:79:d2: ae:3e:99:06:e3:4b:a8:fc:59:18:f1:3a:05:aa:50: 94:1f:64:71:9f:ea:90:eb:06:e9:1d:a0:89:00:a8:
#11
No sweat. Here it is: Upload/overwrite existing gd_bundle.crt into the active ssl folder. Copy/paste the contents of domain.crt into the openssl.crt file. Make sure to put both files in ssl.d and servermaster/ssl.d. Restart apache & enjoy.
#12
I'm quite confused how SSL works now in Aegir2 with IP's being allocated in the front-end. I posted a question about this at the end of move the SSL IP allocation to the frontend, but I'm guessing as this is a closed issue, it might slip below the radar. Any info on this or a pointer in the right direction is much appreciated.
#13
Seems to be a bug (omission?) in Provision that ignores ssl chain files. I found that the vhost file wouldn't get updated with the SSLCertificateChainFile entry even when following the documentation. Perhaps I was doing something incorrectly but if I was, I never found it. In the end I ended up applying a couple patches, reverifying my platform and all was right with the world. I did have to remove some whitespace in between the two diffs in the patch but other than that it applied to provision 6.x-1.9 (bit of patch fuzz but otherwise ok)
See http://nicksantamaria.net/article/getting-ca-chain-certificates-work-usi... and http://nicksantamaria.net/sites/nicksantamaria.net/files/article_attachm... if you have the same problem. :)