A blog named for the muse of Astronomy containing musings by an astronomer

Securing your Snow Leopard Web Server

Posted on April 05, 2011 by Juan

I run several blogs as well as some WebDAV servers on my MacOS X web server, all of which use passwords to authorize access.  I recently decided it would a good idea to support HTTPS (secured, encrypted HTTP) on my web server so that my passwords for accessing my blogs and webDAV server were not sent plaintext and unsecured over the internet.

Initially I had balked at this because the typical SSL Certificate, needed to encrypt and decrypt the traffic from the web server, cost on the order of $100 per year if signed by a Certificate Authority (one of the companies that all the web browsers come set up to ‘trust’ as signers of SSL certificates).  Such a digital signature is necessary if you want your https connections to be recognized as trusted by all web browsers.

However, I recently learned that it is possible to simply ‘self-sign’ your SSL certificates and so long as you only need the encryption for yourself (for example, when using a password to log in as an admin on a blog), this is a free solution that works.  The certificate will not be marked as ‘trusted’ by any authority, but if you can trust it, it will allow you to encrypt the traffic to and from your web server.

The solution I outline below is partly based on a hint provided at MacOSXHints for getting a full Certificate Authority signed certificate installed (here) and a hint from the CentOS wiki (here) for self-signing your certificates.

I’ll outline the procedure I used below, but as a warning, you need to have a familiarity with the command line and the use of sudo.  I am also assuming you are using Snow Leopard (MacOS 10.6.x).

  1. Create Directory to store certificate: Start by creating a directory you want to place the certificates in and then “cd” into that directory on the command line.  I used /etc/apache2/local_certs/ as my directory.
  2. Generate the Private Key file: Next, from the command line, generate a private key:
    openssl genrsa -out ca.key 1024
    during the command the output should look like this:
    Generating RSA private key, 1024 bit long modulus
    e is 65537 (0x10001)
  3. Generate a Certificate Signing Request file: Next you need to generate a certificate signing request. You won’t ask anyone else to sign this, but you need it in order to create the public key file. So from the command line type:
    openssl req -new -key ca.key -out ca.csr
    and you will be asked a series of questions. Your answers should be as follows:
    1. For Country Name (2 letter code) answer with the two letter code for your country, for the United States it was “US”.
    2. For State or Province Name (full name) I answered “Minnesota”.
    3. For Locality Name I entered my city.
    4. For Organization Name I entered my name (Juan Cabanela) since this is a server run by my school, but not managed by my school.
    5. For Organizational Unit Name I just hit “enter” and left it blank, your answers may vary.
    6. For Common Name I entered by server’s URL iparrizar.mnstate.edu.
    7. For Email Address I used my email address. It appears in the certificate so I suppose it could lead to spam, but I figured it was better to give people stumbling across the certificate an email address they could contact for questions.
    8. For A challenge password and An optional company name, I hit enter. I don’t expect to need to get the certificate signed.
  4. Generate a Public Key file: The last step in certificate creation is you need to generate the self-signed public key which will actually be what users get when they access your server. The user uses this public key which decrypts the traffic the web server will encrypt with the private key (only accessible to the web server).  To generate the public key file, use the command line to run:
    openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt
    This will only make your public key valid for 365 days, you might want to change this if you don’t want to have to generate a new public key every year.
  5. Set up the web server: Now you have to edit your MacOS web server configuration to support encrypted HTTPS traffic.  This comes down to editing two files. ou will need ‘admin permission’ to edit both of these files, so you will either need to use sudo with a command line text editor (like vi or emacs) or you will need to use a text editor that supports editing files with ‘admin’ permission. The changes you need to make are the following:
    1. Open the main web server configuration file, /private/etc/apache2/httpd.conf, in a text editor and uncomment (remove the leading ‘#’ from) the following line (it’s line 473 in my installation):
      Include /private/etc/apache2/extra/httpd-ssl.conf
    2. Edit /private/etc/apache2/extra/httpd-ssl.conf and make sure the following lines are set as follows:
      • SSLCertificateFile points to /private/etc/apache2/iparrizar_ssl_new/ca.crt or where ever you have your ca.crt file you created in step 4. SSLCertificateKeyFile points to /private/etc/apache2/iparrizar_ssl_new/ca.key or where ever you have your key file you created in step 2.
      • Make sure the lines containing SSLCACertificateFile and SSLCARevocationPath (these are two seperate lines) are commented out (add a leading ‘#’ to each line). Since these certificates will not be signed by a certificate authority, you have no need to point people to CA certificate files or revocation paths.
  6. Restarting the web server: Now all you should have to do is restart you apache web server and see if everything works. From the command line type:
    sudo apachectl restart
    This should restart the web server.  Assuming no error messages appear, you can next test the connection.
  7. Testing the web server: See if you can go to your web server using https://your.domain.name.here/ as the URL in your web browser. You will be presented with the ‘untrusted’ certificate and asked if you want to accept it.  In Safari on the Mac, accepting the certificate adds it to the Keychain.  I am not sure about where Firefox or Chrome store the certificate, but they should hold on to it for future use, ensuring your future connections to the web server are secure (if done via “https”).
  8. Bonus Step for iOS device users: If you want to add these self-signed certificates to your iOS device, you can do this by simply ‘exporting’ the certificate as a ‘crt’ file from the Keychain (or finding the original “crt” public key file you created earlier).  Email that public key .crt file to yourself and open that email on the iOS device.  If you click on the attached certificate in that email you will be presented with the option of adding that certificate to your iOS profile.  Doing so will allow Safari and other programs on the iOS device to connect securely to your web server.

Leave a Reply

  • Translate

  • Astro Pic o' the Day

  • Archives

  • Admin

↑ Top