Encryption


You can encrypt data sent between two devices so that no one can see, change, spoof, or subvert the packets. One of the devices is your Mac OS X Server. The other device can be any client computer that connects to your server. This section discusses how to enable encryption on your server so that various services can take advantage of better security.

The first type of encryption, Secure Sockets Layer (SSL), is the most common. Perhaps your Mac OS X Server is a Web server used to sell a product. Your Web site has pages that handle sensitive user data or credit card information. When users navigate to your Web site and enter a page that is secure, you should be ready. Or perhaps you wish to encrypt the transaction of sending and receiving mail, or the process of user authentication for home folders on your server.

The type of encryption this section discusses involves obtaining a certificate from a Certificate Authority (CA), creating your own certificate, or using one created for you by a non-CA. If you wish to obtain a certificate from a trusted source, you must be prepared to offer important business and personal information to Thawte, VeriSign, or another, smaller CA. To do so, navigate to the CA's Web site and ask for a certificate. Certificates come in various encryption levels and types, so you may want to choose one with a higher level if you have potential customers overseas. Chances are this certificate will cost you money, and you'll have to decide if the cost is worth the effort. Most CAs place great stock in making certain your business or organization is who it says it is. The cost of the certificate is profit for companies who have built their names on trust. Many Web sites today rely on these companies to verify them. However, some CAs don't charge as much as others. You must decide if your organization requires a name-brand certificate signed by a well-known CA, or if a lesser-known CA will do. There are no right answers here; it all depends on which CA you trust the most.

The reason for the cash transfer is that authentication has to start somewhere. If you're www.yourstore.com, how can people purchasing from your site know that you are who you say you are? You must prove to someone that you are indeed who you say you are and not a Web site that looks like you but is an imposter. By purchasing a certificate from a CA, you're telling people coming to your site that you underwent a thorough business check and that the CA says, "Yes, this site is the site they purport to be. I, Thawte, checked their background and had them issue me a certificate-signing request, which I signed. They now have a certificate registered with me so that when a customer's browser asks me to validate them, I can."

Private keys

Before you have a certificate to sign, you must create your own private key. Several parameters are involved when you create a key. In most cases, you'll want to create a 1024-bit private key, although you can create keys with a higher and lower encryption bit level and a different cipher, such as Blowfish, SHA-1, or MD5. Increasing the bit level for a key or changing the cipher may hinder others who try to connect to you; for as you know, people still use older, less secure operating systems to access the Internet.

To create a private key:

1.

Open the Terminal application located in /Applications/Utilities.

Become root by typing sudo s, pressing Return, and entering the root password.

2.

To create a private key, enter the command

 openssl genrsa des3 1024 > privatekey.pem 

This tells the openssl command to generate an RSA-style key with a Triple-DES cipher at 1024 bits and to save the key as privatekey.pem (Figure 10.41).

Figure 10.41. Generate a Triple-DES, 1024-bit encrypted private key using openssl.


3.

Enter a passphrase that you will not forget!

Tip

  • To expand on your understanding of the openssl command line tool, type man openssl in the Terminal.


Certificate Signing Requests

You've now created a private key, which only you have; do not give this key file to anyone! Now you must create a Certificate Signing Request (CSR) with that key.

CSRs are made on behalf of a server or service and presented to a CA. This process is done via the command-line interface on Mac OS X Server. Therefore, you must ensure that you make no typos, because the command-line interface (CLI) isn't forgiving.

To create a Certificate Signing Request:

1.

In the Terminal, type the following command on one line (Figure 10.42):

 openssl req new key privatekey.pem out mycsr.csr 

This command tells openssl to create a new key out of privatekey.pem and write it out as the file mycsr.csr.

Figure 10.42. Create a CSR based on the private key using openssl.


2.

Enter the passphrase that you used when you created your private key (Figure 10.43).

Figure 10.43. Enter the password associated with your private key to proceed.


3.

Enter the data required for the seven entries when creating the CSR (Figure 10.44):

  • Country Name

  • State Name

  • Locality Name

  • Organization Name

  • Organizational Unit

  • Common Name

  • Email Address

Figure 10.44. Enter the appropriate information for the requested fields in the CSR using openssl.


Be sure the common name matches the Web address if you're using this certificate as a Web server certificate, as in Figure 10.42. You also have the option of adding two other entries before writing out the request.

They are:

  • Challenge Password

  • Optional Company Name

4.

Send your CSR to Thawte, VeriSign, or one of the other CAs to start the process of obtaining your signed certificate.

Contact the appropriate Web site for instructions on how to submit the CSR.

Tip

  • Apple has an in-depth document on openssl at http://developer.apple.com/internet/serverside/modssl.html.


Acting as a Certificate Authority

Another possibility is that you don't need to pay for a CA to tell you that you're you. You know who you are, and you trust you. More important, your server may be inside a small school or organization where you don't need it for Web-page encryption but for encryption of another service (such as email) or to encrypt the transfer of data when requesting user data via the LDAP protocol. In these cases, you can sign your own certificate, thus avoiding the cost of having some else do it.

To act as your own CA:

1.

Open the Terminal application located inside /Applications/Utilities.

Become root by typing sudo s, pressing Return, and entering the root password (Figure 10.45).

Figure 10.45. Create a root shell on the server.


2.

Create a folder called certs inside /private/etc (any name will do, although the name cert or certs makes sense).

Change directories so you're inside the certs folder (Figure 10.46).

Figure 10.46. Change directories so you're inside the certs folder.


3.

Do one of the following:

  • Move your private key into this folder.

  • Create a new private key, as shown in step 2 of the task "To create a private key" (Figure 10.47).

    Figure 10.47. Create another private key to self-sign certificates.


4.

Enter the following command in the Terminal (Figure 10.48):

 openssl req -new -x509 -days 365 - key privatekey.pem -out ca.crt 

The command creates a request for a new X509 certificate for 365 days based on the private key previously generated; the resulting file is named ca.crt.

Figure 10.48. Create an X509 certificate using openssl.


5.

Enter the passphrase from your private certificate when asked (Figure 10.49).

Figure 10.49. Enter your passphrase when requested.


6.

Enter the required information when asked (Figure 10.50).

Figure 10.50. Enter the appropriate information when prompted.


The common name should be the fully qualified domain name of your server.

7.

Use the old CSR or create a new CSR, and enter all appropriate data (Figure 10.51).

Figure 10.51. Use the old CSR or create a new CSR, and enter all appropriate data.


8.

Create a new folder called demoCA in the certs folder.

Create two folders in demoCA: private and newcerts (Figure 10.52).

Figure 10.52. Create two folders inside demoCA: private and newcerts.


9.

Copy your ca.crt file from etc/certs to /etc/certs/demoCA, and rename it cacert.pem.

Move your privatekey.pem from the same original location to /etc/certs/demoCA/private, and rename it cakey.pem (Figure 10.53).

Figure 10.53. Move and rename ca.crt and privatekey.pem.


10.

Create a file called index.txt in the demoCA folder.

Create another file called serial, containing the value "01" (Figure 10.54).

Figure 10.54. Create two files, and enter data into one of them.


11.

Navigate to the /etc/certs folder (Figure 10.55).

Figure 10.55. Navigate to the /etc/certs folder.


12.

Enter the following command in the Terminal to sign your own CSR (Figure 10.56):

 openssl ca -policy policy_anything - in castor.csr -out castorserver.crt 

Figure 10.56. Self-sign a certificate, and enter all the appropriate data.


13.

Enter the letter y when asked about signing and again when asked about committing the certificate (Figure 10.57).

Figure 10.57. Confirm the signing and committing of the certificate.


You now have, as far as your server is concerned, a signed certificate. You must copy the certificate to any client computers that you want to use the encryption.

Tip

  • Some folders and files (like the demoCA folder) require certain names when dealing with self-signed certificates. Read the openssl.cnf file in /System/Library/OpenSSL/, which contains the default settings for using openssl with self-signed certificates.


To add the certificate to client computers:

1.

Copy the file ca.crt from /etc/certs on your server to any client computers that need to know about the server.

You should probably insure a secure copy from the server to the clients so no one can tamper with or see this file. Use a USB key drive, a FireWire drive, or secure connection to transfer the file from your server to client machines.

2.

Once the certificate file is on the client computer, double-click it.

The Keychain Access application opens and presents an Add Certificates dialog (Figure 10.58).

Figure 10.58. Double-click the certificate on the client to open an Add Certificates dialog.


3.

Click the View Certificates button to be sure it's the correct certificate (Figure 10.59).

Figure 10.59. Clicking the View Certificate button shows the contents of the certificate for visual verification.


4.

Click OK , and then click OK again to close the Add Certificate dialog.

View the Keychain Access application, and locate your new certificate in the X509Anchors file (Figure 10.60).

Figure 10.60. View the certificate in the keychain after you add the certificate to the X509Anchors file.


If this doesn't work, enter the following in the command line:

 sudo certtool i /etc/certs/ca.crt k=/System/Library/Keychains/ X509Anchors 

Implementing certificates

Whether you've created your own signed certificate or had a certificate signed by a CA, you can implement certificates in a variety of ways. Mac OS X Server can use certificates with the following services using the Server Admin tool:

  • Open Directory

  • Web sites

  • Mail server

By default, if you're using a Mac OS X Server as an Open Directory master, all communications between your client computers and your server with regard to LDAP are passed as clear text. This is a potential security issue. You should set up the server to use Secure Sockets Layer (SSL) encryption and let the client computer know about this as well.

If you have a Web site, you should use the certificate to encrypt communications when customers come to your site.

If you're running a mail server, you should encrypt all email running through your server.

To encrypt Open Directory master communications:

1.

Launch the Server Admin tool located in /Applications/Server, and authenticate as the administrator (Figure 10.61).

Figure 10.61. Launch the Server Admin tool, and authenticate.


2.

Choose the Open Directory service from the Computers & Services list (Figure 10.62).

Figure 10.62. Select the Open Directory service from the Computers & Services list.


3.

Click the Settings tab , and then click the Protocols tab (Figure 10.63).

Figure 10.63. Select the Settings tab and then the Protocols tab, and select the Use SSL check box.


4.

Select the Use SSL check box (Figure 10.64).

Figure 10.64. Select the check box to enable SSL.


Click the ellipsis buttons , navigate to the /etc/certs directory, and choose the appropriate certificates and the private key (Figure 10.65).

Figure 10.65. Choose the appropriate certificates and keys by using the ellipsis button to bring up a navigation dialog.


5.

Click the Save button to save the changes to the Open Directory settings (Figure 10.66).

Figure 10.66. Click Save to save the changes to the Open Directory settings.


Now, anyone connecting to your Mac OS X Server via LDAP must have the required certificate and have SSL active from the client computer.

Setting up Directory Access SSL LDAP

You must now tell your server to see itself over SSL. The same procedure outlined in the following task is done on the client machines when you bind to an LDAP server over SSL.

To set up Directory Access SSL LDAP:

1.

On your server, open the Directory Access application located in /Applications/Utilities, and authenticate as the administrator using the lock (Figure 10.67).

Figure 10.67. Use Directory Access to view the LDAP plug-in.


2.

Double-click the LDAP plug-in, click the disclosure arrow next to Show Options if necessary, and select the SSL check box (Figure 10.68).

Figure 10.68. Check the SSL box to allow secure connections on the server.


Click the OK button .

3.

Deselect the LDAP plug-in, and select it again.

Doing so highlights the Apply button ; click it (Figure 10.69).

Figure 10.69. Deselecting and selecting the LDAP plug-in activates the Apply button.


4.

Test thoroughly to ensure that your server certificates were created properly. If this doesn't work, it's possible that the certificate creationespecially the common name in the certificate setupisn't correct.

Once the server can see itself again (verified by a successful launching of Workgroup Manager and seeing the LDAP users), you can run through this list for clients that have the LDAP plug-in activated.

DHCP LDAP SSL

If you set up your server as a DHCP server and you're pushing LDAP information down to your client, you should enable SSL there.

To enable SSL for the LDAP DHCP option:

1.

Launch the Server Admin tool located in /Applications/Server, and authenticate as the administrator (Figure 10.70).

Figure 10.70. Launch the Server Admin tool, and authenticate.


2.

Choose the DHCP service from the Computers & Services list (Figure 10.71).

Figure 10.71. Select the DHCP service from the Computers & Services list.


3.

Click the Settings tab , double-click your subnet, and click the LDAP tab .

4.

Select the "LDAP over SSL" check box (Figure 10.72).

Figure 10.72. Select the "LDAP over SSL" check box.


5.

Click the Save button .

Your DHCP server will alert you that it needs to be restarted.

Web SSL setup

When setting up your Web site for SSL, you must consider whether you wish to use the same certificate. This section assumes you're using the same certificate.

To enable SSL for the Web server:

1.

Launch the Server Admin tool located in /Applications/Server, and authenticate as the administrator (Figure 10.73).

Figure 10.73. Launch the Server Admin tool, and authenticate.


2.

Choose the Web service from the Computers & Services list (Figure 10.74).

Figure 10.74. Select the Web service from the Computers & Services list.


3.

Click the Settings tab , and then click the Modules tab .

Select the SSL module, and click the Save button (Figure 10.75).

Figure 10.75. Select ssl_module on the Modules tab of the Settings tab.


4.

Click the Sites tab, select your Web site, and click the edit button (Figure 10.76).

Figure 10.76. Choose the Sites tab, and select the Web site.


An Editing dialog opens.

5.

Click the Security tab , and select the Enable Secure Sockets Layer check box (Figure 10.77.

Figure 10.77. Click the Edit button and select the Security tab to reveal the Enable Secure Sockets Layer check box.


Doing so enables SSL for this Web site.

6.

Enter the passphrase from your Certificate Signing Request.

Click the ellipsis button next to the SSL Log File field, and choose a file for the log (Figure 10.78).

Figure 10.78. Enter your certificate passphrase, and choose a log file location.


7.

Use the ellipses buttons to open a navigation dialog and navigate to and select the following (Figure 10.79):

  • Certificate file

  • Private key file

  • Certificate Authority file

Figure 10.79. Use the ellipses buttons to navigate to and select the appropriate certificates and private key file.


8.

Click the Save button .

Start the Web service using the Start Service button in the Server Admin Toolbar.

Tip

  • To avoid having the Web server ask you repeatedly whether to restart, you can stop the Web service prior to this configuration and start it back up when you're finished.


Secure email

Another service that can take advantage of SSL is the Mail service in Mac OS X Server. There are many options for connecting to your mail server, but the mail itself is still transferred in clear text unless you enable SSL.

To enable SSL for mail:

1.

Launch the Server Admin tool located in /Applications/Server, and authenticate as the administrator (Figure 10.80).

Figure 10.80. Launch the Server Admin tool, and authenticate.


2.

Choose the Mail service from the Computers & Services list, and click the Settings tab (Figure 10.81).

Figure 10.81. Select the Mail service from the Computers & Services list, and click the Settings tab.


3.

Click the Advanced tab (Figure 10.82).

Figure 10.82. Clicking the Advanced tab reveals the SSL options for the Mail service.


To utilize SSL for both incoming (POP and IMAP) and outgoing (SMTP) mail from the pop-up menu next to the SMTP SSL and IMAP and POP SSL text, choose one of the following methods (Figure 10.83):

Don't use doesn't use SSL at all.

Use uses SSL if both the server and client mail application are configured properly.

Require doesn't permit any unencrypted communications.

Figure 10.83. Choose a method to use SSL for incoming and outgoing mail.


4.

Click the Save button to save the changes.

Because of the way Cyrus and Postfix work with SSL, they have special requirements for enabling SSL.

5.

Join the content of your server certificate and private key into one file, and move that file into both the /etc/postfix folder and the /var/imap folder (Figure 10.84).

Figure 10.84. Create a new file with the combined contents of the private key and certificate.


Doing so allows Postfix and Cyrus to see the certificates. You could also make a symbolic link inside the postfix and cyrus directories pointing back to the /etc/certs directory.

Depending on how you copied the files, you may need to ensure that group mail has read access to the file server.pem inside the /var/imap directory.

6.

Start the Mail service with the Start Service button in the Server Admin Toolbar.

Tips

  • A symbolic link is like an alias. You create a symbolic link in the terminal with the command ln s /path/to/original/file /path/where/you/want/the/link/to/go.

  • You may want to stop the Mail service before you make any changes. Once all the changes are made and saved, you can restart the Mail service.


Certificate Setup

If certificates don't work for one service, they're unlikely to work for another. Create your certificates, and test them with only one service before moving on.

The best service to test is the Web service, because failure won't cripple the server the way a failed test on Open Directory would. Because of the extra configuration steps involved in setting up SSL for mail, this also isn't a wise choice to test your first certificates.

If you're using self-signed certificates, and things aren't working, check DNS first and be sure your common name was correct in the certificate. If you feel there may have been errors, delete the certs folder inside /etc and start again. You can consult the /System/Library/OpenSSL/openssl.cnf file for more instructions.


ssh keys

Another option when you're securing a server is to restrict who can access the server via ssh. Since ssh is turned on by default when you install and configure Mac OS X Server, a good password may not be enough to keep others out. You can use open-source software contained in Mac OS X Server to generate a key and then give the key to individuals who are permitted to log in via ssh.

To create an ssh key:

1.

On a Mac OS X client computer, open the Terminal application located in /Applications/Utilities.

2.

Enter the command ssh-keygen t dsa, and press the Return key (Figure 10.85).

Figure 10.85. Create a public and private key using the ssh-keygen command.


This command generates the two files necessary for encryption using the type dsa: id_dsa, which contains the private part of the key; and id_dsa.pub, which is the public part of the key.

3.

You're asked to provide a filename, which you need not do.

You're also asked for an optional passphrase, which you can add for even more security; it encrypts the private key with Triple-DES encryption.

4.

Copy the id_dsa.pub file to your administrator's home folder on the server via any method you choose.

If it doesn't already exist, create a folder called .ssh in the home folder on the server. Move the id_dsa.pub file into the .ssh/ folder, and rename it authorized_keys (Figure 10.86).

Figure 10.86. Change to the .ssh directory on the server, and rename the id_dsa.pub file to authorized_keys.


5.

If you're remotely logged in to your server via ssh, log out.

Attempt to log in again from the client computer that generated the keys, and enter the passphrase if you gave it one when requested (Figure 10.87).

Figure 10.87. Attempt to log in from the client computer that generated the keys.


If anyone else attempts to log in using your short name, they must also have the private key on their computer, which isn't likely.

Tips

  • Make a backup copy of the keys, and install them on all machines that may require other administrators to ssh into the server. You may also wish to copy the authorized_keys file from one administrator account to other accounts or to generate individual keys for each user.

  • If you don't enter a passphrase when you generate a key, then when a user opens the Terminal and attempts to log in with the admin account, they won't be asked for a password or passphrase. This can be dangerous, because the client computer can access the server by opening the Terminal and typing in ssh admin_name@ip_address.

  • There are many other ways to make your server secure. These are just a few of the more popular ways, and most of them are also supported in the interface of Server Admin.

  • Remember, security is never-ending. It all starts with a common-sense approach to guarding your passwords and data; then you work up from there.




    Mac OS X 10. 3 Server Panther. Visual QuickPro Guide
    Mac OS X Server 10.3 Panther: Visual QuickPro Guide
    ISBN: 0321242521
    EAN: 2147483647
    Year: 2004
    Pages: 105

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net