Hosting Project 2.0
From wiki.dod.net
Contents |
Objectives
History
Apache
PHP
CGI
SSI
SSL
Project DoD 2.0 offers two different types of SSL service: Standard SSL and Collective SSL. The former is simply a traditional SSL service, while the latter is a service that we provide to all users for free.
Standard SSL Service
This service is done manually because we hardly ever get requests for SSL, and because we need to add an IP address and reverse DNS, which we have no automated system for yet. We manually generate a certificate-signing request for the user’s domain or wildcard address, which the user can take to his or her SSL vendor to get signed. Once the user gets the certificate from the vendor, we will put it in place on the server. This is done using [Pound] and a traditional virtual host configuration in Apache. We do have plans to automate this process when we release Project DoD 3.0, but for now those users that need standard SSL will need to do it manually. If you or someone you know is interested in setting up standard SSL please contact someone in support: https://support.dod.net/.
Collective SSL
Collective SSL is a term we use to describe a shared SSL service for all users of Project DoD. With a small footprint, Collective SSL allows Project DoD to use its validated wildcard SSL certificate for all sub-domains on dod.net. This means that users can sign up for a sub-domain with Project DoD and get validated SSL service by hitting https://subdomain.dod.net/. That is, if you’re just a normal user like http://chris.dod.net/, you can access your domain with validated SSL by simply going to https://chris.dod.net/. This is a huge win for any collective user that wants to run a secure service on their website. It helps with anything that requires user login or secure authenticated content. Sure the domain must reside at dod.net, and the validation shows Project DoD, but our users gain the validated SSL service through collective organization with no annoying warnings. For more information on how this works please read the technical information section.
We call this service Collective SSL, because we are all working together to share the resource. That is, your donations go to pay for Project DoD’s wildcard certificate, and we share that service with you. We have bigger and better plans for this service in Project DoD 3.0, but for now it does exactly what we want.
Project DoD and SSL
To try and remove user questions about whether or not it was safe to use Project DoD’s account manager, webmail, or other secure services, we decided to get our certificate signed by a third party. Since we supported Project DoD in the 1.0 phase virtually out of pocket, and our major goal for the 2.0 phase was that Project DoD and the collective be self sustaining, we went with the least expensive certificate authority we could find. This choice only partly did the job, as the certificate authority was not recognized in all browsers, but at least those people affected could verify the identity of Project DoD and the certificate authority.
Nevertheless, this certificate only worked for secure.dod.net, and we had a need to use it on other sub-domains like pop3, smtp, mail, ftp, and more. What’s more, we wanted to offer validated SSL services to our users with the same constraints we put on our other services: that they’re free. It looked as though we could solve this problem with a wildcard certificate, but few authorities offered such a service, and at the time less browsers recognized them. Over time, wildcard certificates have become more widely accepted, but they have always been expensive. The first year we finally scraped together enough money to purchase a wildcard certificate was 2008. It cost $600.00 from [Network Solutions], a widely accepted certificate authority, and it took a substantial proof of identity. Paying for the wildcard certificate was almost fully made possible by Seeds of Justice and Richa of http://richa.dod.net/. His contribution of $500.00 in 2007 was used to purchase the wildcard cert for the first time.
Technical Information for SSL
We did have some problems trying to use the wildcard cert on one IP address with Apache. Now, anyone who knows anything about SSL certificates knows that Apache can only serve one SSL certificate per virtual host. This is because the “Host” header of the HTTP packet is needed to select a virtual host, but because SSL encapsulates the entire HTTP packet Apache has no way to know what virtual host the packet is destine for when it chooses the certificate to use. Thus, the virtual host section for an SSL connection is usually tied to a unique IP and port. Now, the same IP address could be used for multiple HTTPS virtual hosts if the port changes each time, but this does not dynamically grow and shrink well enough for our needs. That is, we would need to code a solution to this knowing that we have less than 65535 possible ports it could run on, that each entry in the httpd.conf would need to be different for SSL virtual hosts, that we would have to open that port in the firewall for each virtual host, and that it would not be functional enough for users to have to specify the port in their domain.
The other solution would be to provide another IP address for each user that wanted SSL. This will always be the case with Standard SSL certificates, but again it only solves the problem with not having to specify a port. We have a bigger problem with growing the service because each address would need to be thrown into ifconfig, the startup scripts, and have reverse DNS that matched the domain. While this is a perfectly acceptable limitation of a normal host based SSL certificate, we were not ready to throw in the towel and ignore the flexibility of wildcard certificates.
From our research it appeared to be true that our configuration would not be possible with Apache. While it could certainly open a wildcard SSL certificate, read the ‘Host’ header, and then designate a virtual host to handle it, Apache was not designed to do so. We knew we could write an SSL proxy ourselves, change the relevant portions of the header, and forward the connection on, but we first tried to leverage the Open Source community to meet our needs. Sure enough we found [Pound], and after reading up on how to use it and looking at some of the source we were able to come up with the following solution.
[Pound] gave us the ability to designate an address and port that will listen for SSL connections, match all *.dod.net ‘Hosts’, and forward them to Apache on port 80 to be handled by normal virtual hosts. One can see this in the following figure:
The beauty of this configuration is that it requires no additional work in Apache. That is, we can use a standard virtual host directive like the one below to run all *.dod.net domains:
<VirtualHost 1.2.3.4:80>
ServerAdmin subdomain@dod.net
DocumentRoot /serve/www/subdomain/subdomain.dod.net/public_html
ServerName subdomain.dod.net
Action cgi-wrapper /cgi-bin/global/cgiwrap/subdomain
Alias /perl/ /serve/www/subdomain/subdomain.dod.net/public_html/perl/
CustomLog "|/usr/local/sbin/cronolog \
/serve/www/subdomain/subdomain.dod.net/logs/%Y/%m/subdomain.dod.net.%Y%m%d" combined
ErrorLog /serve/www/subdomain/subdomain.dod.net/logs/subdomain.dod.net.err_log
</VirtualHost>
In addition to not having to change the Apache configuration, this gave every sub-domain at dod.net validated SSL abilities by simply addressing the domain with https rather than http. The result is that every user with a dod.net sub-domain can now do SSL without those annoying warnings.
Now, one might argue that those annoying warnings are there for a reason, and that offering validated SSL services to un-validated users breaks the security model. As it turns out those arguments are correct, and for that reason we would suggest any domain that needs to perform an e-commerce transaction get their own certificate that we will set up on the server manually. Since requests for SSL are rare we are more than willing to perform this service. However, when it comes to other uses of SSL, and the Project DoD collective certificate in particular, we believe this service is in keeping with our objectives. We are simply solving a need for both Project DoD and our users by collectively organizing our resources to obtain a validated SSL certificate. This action is in keeping with the spirit and intention of what Project DoD is [| organized] for, and we invite anyone to join the collective.
The [Pound] configuration was beautiful in its simplicity once we figured it out. We simply set up a listener on the address our virtual hosts reside on, and bound Pound to port 443 on that address. When the connection comes in we strip the SSL off using Project DoD’s validated certificate, and pass it through to the Apache server running on the same address. You can view the pound configuration here:
User "root"
Group "root"
Daemon 1
DynScale 0
Alive 30
Client 15
TimeOut 20
Grace 30
ListenHTTPS
Address 1.2.3.4
Port 443
Cert "/path/to/cert.pem"
Service
HeadRequire "Host:.*dod.net.*"
BackEnd
Address 1.2.3.4
Port 80
End
End
End
Renewing Project DoD's Wildcard Certificate
As a point of interest to any administrator tasked with generating future certificates for Project DoD, we're posting the process to request a new cert. We have to do this once a year, and the going rate for wildcard certs is about $600.00 as of 2009. Make sure you pay for the service before starting the Reissue process. Once you have renewed, follow the steps in the e-mail:
- Use the following command to generate a CSR:
darkside <18:54:56># cd /serve/certs/dod.net/ darkside <18:55:04># ls dod.net.crt dod.net.csr dod.net.key dod.net.pem intermediate_crt.txt darkside <18:55:32># mkdir new darkside <18:56:33># cd new darkside <18:56:34># openssl req -new -nodes -key ../dod.net.key -out dod.net.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:Maine Locality Name (eg, city) []:Portland Organization Name (eg, company) [Internet Widgits Pty Ltd]:Project DoD Inc. Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:*.dod.net Email Address []:admin@dod.net Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: darkside <18:59:19># ls dod.net.csr darkside <18:59:21># cat dod.net.csr
- Now copy the results from dod.net.csr into the form on the Network Solutions page and choose Apache/ModSSL from the drop down box and hit Go>>>.
- You will be prompted for some verification information. Fill this out to the best of your ability.
- Now normally you wait, but feel free to call network solutions just to make sure. They say it takes a few hours for the request to propagate over to them, so you may want to wait a while. Don't worry about calling them. After all, we're paying them $600.00 a year and they hardly have to do anything. Make them earn it.
- Once they have validated us again -- which is much easier the second and third time around -- they will mail you with instructions on downloading the certs.
- Copy over the existing files from the old cert into the new directory.
darkside <19:00:01># cd /serve/cert/dod.net/new darkside <19:00:02># cp ../dod.net.crt ../dod.net.key ../dod.net.pem ../intermediate_crt.txt ../root.crt .
- Update dod.net.crt with the downloaded cert.
- Update dod.net.pem with the new dod.net certificate with your text editor. You can tell which entry to edit by looking at the old cert, finding that section in the new file, removing it, and putting the new certificate in its place. The rest of the data in the intermediate file, the root file, and the dod.net.pem should remain the same, but you should double check it.
- Now go back a directory and move the old files into a backup directory named after the year, month, and date the original certs were issued (YYYMMDD). Also move the new files into place.
darkside <19:00:03># cd .. darkside <19:00:04># mkdir YYYYMMDD darkside <19:00:05># mv * YYYYMMDD darkside <19:00:06># mv YYYYMMDD/new/* . darkside <19:00:07># rm -fr YYYYMMDD/new
- Restart pound (/etc/init.d/pound restart)
darkside <19:00:10># /etc/init.d/pound restart
- Now you will want to update the IRC server too. You can do this by going the irc user home directory, finding the files name server.*, fixing them up right, and restarting the IRC server. (I got lazy here)
