Web Services

The Apache2 web server is an available configuration option for your SLES server. The Apache2 server is a fully functional and very versatile environment. In a default configuration, Apache2 offers web pages using the HTTP protocol on port 80. If required, a certificate can be incorporated to offer secure web pages using HTTPS on port 443. The following options are available under Apache2:

• Access controls

• Server-side includes

• CGI scripting

• Per-user websites

• Virtual servers (by name or by IP address)

You access the Apache2 configuration menus by selecting the Network Service, HTTP Server options in YaST. In a typical environment, a web server offers content housed in a single structure of directories.

By default, Apache2 on SLES points to /srv/www/htdocs as the repository for all centralized web information (see Figure 8.10). Web page requests are pointed to this directory for resolution. Subdirectories can be added within this directory to further segregate content. The directory names then become an integral portion of the requesting URLs. The structure of the website beyond that point is left to the webmaster responsible for the site.

Figure 8.10. The default HTTP server configuration.

For more dynamic content, you can find a system-wide CGI environment in /srv/www/cgi-bin. The web server configuration file defines how documents placed in directories are processed. This specific location is configured to preprocess the requested item through the appropriate scripting engine. Output from the script is then passed back to the requesting client as standard HTML. This allows the website in question to generate dynamic content not normally accessible through raw HTML.

SLES and Apache2 also allow users to publish their own web content. When users are added to a system, they are automatically given a public_html directory in their home directory. Web pages in these directories can be accessed by adding ~username to the default web server path.

An out-of-the-box installation of the HTTP server environment provides a great deal of what a typical website would require. Apache2, however, can provide significantly more functionality. The installed version of Apache2 supports virtual servers, which come in two flavors: IP based and name based.

Because it is possible to bind additional addresses to a server's network interface card(s), you can configure an Apache2 server to recognize these addresses. Each is different and therefore can be associated with a different document structure, providing a segregated web environment.

You can obtain an equivalent separation of websites by simply identifying the web server by different names. Additional DNS entries can be made to point several names to the same server IP address. When Apache2 is asked to invoke a web session, it looks at the HTTP headers in the request. It then adjusts the internal server path for returned documents based on the calling URL.

Figure 8.11 shows the configuration of a virtual web server for the Human Resources department.

Figure 8.11. A virtual server configuration for Human Resources.

Both Castor.UniversalExport.ca and hr.UniversalExport.ca can be placed in DNS, resolving to the same TCP/IP address. As the web server receives the request, it will parse the headers in the HTTP request and transparently pass the request on to the appropriate document tree. In the case of the default website (Castor), documents could be processed from its web root in /srv/www/castor. In the case of the Human Resources page, documents will be viewed from /srv/www/hr. Figure 8.12 shows the updated virtual server information in the main HTTP server setup screen.

Figure 8.12. The main HTTP server configuration page showing available servers.

When websites present general information to a large audience, encrypting the transmission is often unnecessary. Typically, such websites provide online access to information easily accessible through other formats of publishing.

Sometimes, however, sensitive information is generated by an application residing on a website. The Apache2 server included in the SLES distribution is capable of supporting encrypted HTTP traffic called HTTPS. For your HTTP server to generate HTTPS traffic, a certificate is required. A certificate is a mechanism through which a client can get a certain level of assurance that your server is, in fact, trustworthy. Such a certificate is usually generated by a third-party service that is responsible for establishing your authenticity. When this trusted third party, known as a certificate authority or CA, is satisfied that the identification requirements are met, a certificate can be issued for your server.

If your site requirements are for internal purposes only and not as strict, a self-signed certificate may be all you require. Unlike a certificate from a trusted authority, a self-signed certificate generates a warning message at the client end, indicating the source and type of certificate. The client then needs to decide whether it wants to accept the self-signed certificate.

A self-signed certificate can be generated in two ways:

• Using /usr/bin/gensslcert and passing it the appropriate parameters

• Using YaST's CA management option under Security and Users

• OpenSSL

The latter approach provides a more user-friendly interface. Generating a certificate using the YaST CA Management option leverages the CA information provided at build time by the person configuring the server. Assuming your server has not been renamed, the information preexisting in the default CA should be valid.

Selecting the Enter CA option opens a screen of information containing the existing information as well as a button that allows you to view, create, and export certificates. At this stage, it is important to verify that both the server name on the certificate and the email information are correct. After you've done this, you can highlight the certificate and select the Export option.

On export, you need to generate both the certificate and the key information. You can select the Export to File option and export both the certificate and the key in unencrypted PEM format. Using this export function places both the certificate and the key information in the same file. Apache2 expects to find this information in two separate files: /etc/apache2/ssl.crt/server.crt and /etc/apache2/ssl.key/server.key. At this point, you can manually split the file into two, cert and key, and copy each portion to the appropriate Apache2 file.

NOTE

The gensslcert command automatically splits the generated certificate into the appropriate Apache2 files. The trick is to get all the necessary information on the command line to generate a valid certificate.

You can find the command-line options by typing

 /usr/bin/gensslcert -help 

Pay special attention to the email address field and the fully qualified host name. If they do not match exactly what is configured within Apache2 for the secure site, the certificate will not work.

The following changes are required to create a secure virtual website on an Apache2 server under SLES. Though the YaST interface provides a convenient configuration environment for HTTP sites, configuring for HTTPS seems to work better manually:

1.	Ensure that the web services are not running. You can do this by managing the HTTP service in YaST or by issuing the following command: /etc/rc.d/apache2 stop
2.	Create a virtual server environment for the SSL site. The configuration files for Apache2 can be found in /etc/apache2. In this directory, you will find a subdirectory called vhosts.d that houses the configuration of the various virtual hosts. Copy the template for the virtual SSL site into a configuration file: cp vhost-ssl.template vhost-ssl.conf Edit this new configuration file and ensure that the ServerName variable matches the fully qualified server name provided to the certificate. Also, ensure that the ServerAdmin variable matches the certificate's default email address.
3.	Correct the System Configuration file for Apache2. The system configuration file for Apache2, /etc/sysconfig/apache2, is not updated directly by YaST when SSL components are added. You therefore need to verify that the following changes are made: The APACHE_MODULE list contains an entry for SSL. The APACHE_SERVER_FLAGS is set to -D SLL. The APACHE_START_TIMEOUT is set to 5.
4.	Tweak the firewall. Because HTTPS runs under a different port than HTTP, you need to modify the server's firewall to accept connections on port 443. If the server will run unsecured web pages in different virtual hosts, port 80 may be required as well.

At this point, a secure site should be available on the server that can be communicated with through HTTPS. If required later or when moving from a staging environment to production, you can insert a certificate from a trusted third-party vendor into the running configuration. This will prevent the clients from dealing with the warnings generated by self-signed certificates.

NOTE

There are many pitfalls in setting up a website to use certificates. If you are using a third-party Certificate Authority, it should have a number of reference articles to help you through the configuration. In many cases, the support staff will walk you through the various steps.

If you use a self-signed certificate, you may require some external resources. Most errors arise from inconsistent spelling of the various names used to generate the certificate. If you are still experiencing difficulties, you may want to visit

http://venueserver.rcc.ryerson.ca/index.php?option=com_content&task=view&id=26&Itemid=40

http://www.securityfocus.com/infocus/1818

http://www.securityfocus.com/infocus/1820

Configuring most aspects of the Apache2 server is straightforward when you use the YaST tool. The server software allows for a number of various sites to be managed as separate virtual servers. The Apache2 server can also be quickly adapted to support HTTPS.