SSL Support

SSL stands for Secure Socket Layer, a protocol developed by Netsacpe for secure transactions across the Web. SSL uses a form of public key encryption, where the information can be encoded by the browser using a publicly available public key, but can only be decoded by someone who knows the corresponding private key.

The most common ciphers used with SSL are RC2 and RC4. These ciphers use 128-bit keys, which offers a high degree of security. An "export" version of these ciphers is also available; the export versions use 40-bit keys, but are otherwise idential to their equivalent 128-bit versions. Inside the USA a license from RSA is required to use these ciphers.

US Export Restrictions
The US Government imposes export restrictions on arms, in a set of rules called ITAR (International Traffic in Arms Regulations). Among other this, ITAR restricts "strong" encryption software. Software that implements SSL in the US cannot be exported without government approval. Presently, the US Goverment is allowing companies to export encryption with a maximum of a 56-bit key.

Certificates
A server certificate is a digitally-encrypted message that informs the browser what organisation it is accessing. To prevent people from making up certificates and pretending to be official organizations, certificates can be obtained from a certificate authority, who act as a third-party to verify that the organisation using the certificate is who they say they are. Probably the best know authority is Verisign in the US. GeoTrust has also been confirmed to work with the Sambar Server (special thanks to James Wright and Ken Stoddart for verifying this); you'll likely find GeoTrust's customer service and pricing more appealing than Verisign's. Important: Equifax certificates have not been supported by the Sambar Server. A problem in the server's use of chaining code prevents the Equifax certificate from being recognized authority. This may now be resolved (as GeoTrust certs work) as Equifax now owns their own RootCA.

Configuration
The Sambar Server can run a Secure Socket Layer (SSL) Server Daemon. This implementation uses DLLs from the OpenSSL library. OpenSSL is a free implementations of the Secure Socket Layer protocol written by Eric Young. The current version of the Sambar Server uses OpenSSL DLLs v0.9.5.

The SSL DLLs are now shipped with the Sambar Server. In order to run in secure mode, the appropriate Sambar Server configuration parameters must be set and the OpenSSL DLLs ssleay32.dll and libeay32.dll must be found in the bin directory where the Sambar Server is installed. If these DLLs are not present, the server will fail to startup if HTTPS is enabled.

In order to initiatine a SSL-connection, the secure server must have a certificate (see Verisign Information Desk and RSA FAQ on Cryptography for more informat). The Sambar Server does not currently provide client-certificate verifications.

The first step of running the Sambar SSL Server is to generate a Private Key. For that, feed a file of random text (randfile) to the key generation routine provided with the SSLeay libary.

To generate a key, type:

openssl genrsa -rand randfile -out key.pem 1024

This command sequence will generate a 1024-bit RSA private key and store it in the file key.pem. This key file should be copied to the config directory of the Sambar Server. The key should look like:

-----BEGIN RSA PRIVATE KEY-----
MIIBOwIBAAJBALtv55QyzG6i2PlwZ1pah7++Gv8L5j6Hnyr/uTZE1NLG0ABDDexm
q/R4KedLjFEIYjocDui+IXs62NNtXrT8odkCAwEAAQJAbwXq0vJ/+uyEvsNgxLko
nWmM1KvqnAo5uQIhALqEADu5U1Wvt8UN8UDGBRPQulHWNycuNV45d3nnskWPAiAw
ueTyr6WsZ5+SD8g/Hy3xuvF3nPmJRH+rwvVihlcFOg==
-----END RSA PRIVATE KEY-----

Obtaining a certificate (Digital ID)

Next you must generate a Certificate Signing Request (CSR). The CSR is what contains the name information for the certificate (Country, State/Province, City, Organization, Division, Web Server Domain Name, etc). It also contains your public key.

The formats of certificate and CSR used by the Sambar Server are the same as those used by Apache-SSL (both servers use SSLeay for their SSL implementations). CSR should be sent for verification to Certificate Authority (CA) e.g. Verisign (www.verisign.com) or Thawte (www.thawte.com).

To generate your CSR, run:

openssl req -new -key key.pem -out req.pem -config ..\config\openssl.cnf

This command sequence will prompt you for the attributes of your certificate. Remember to give the secure server domain name when you would be prompted for "Common Name".

The request should look like:

-----BEGIN CERTIFICATE REQUEST-----
MIIBGzCBxgIBADBjMQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDEa
MBgGA1UEChMRQ3J5cHRTb2Z0IFB0eSBMdGQxIzAhBgNVBAMTGkNsaWVudCB0ZXN0
2NNtXrT8odkCAwEAATANBgkqhkiG9w0BAQQFAANBAC5JBTeji7RosqMaUIDzIW13
oO6+kPhx9fXSpMFHIsY3aH92Milkov/2A4SuZTcnv/P6+8klmS0EaiUKcRzak4E=
-----END CERTIFICATE REQUEST-----

You will now have a private key file (key.pem) and a CSR file (req.pem). Finally, send the req.pem file to the Certificate Authority (i.e. Verisign or Thawte).

Upon reception of a signed certificate from CA, name the certification cert.pem and place it in the config directory along with the key.pem file.

The certificate should look like:

-----BEGIN CERTIFICATE-----                                     
MIICLjCCAZcCAQEwDQYJKoZIhvcNAQEEBQAwWzELMAkGA1UEBhMCQVUxEzARBgNV
BAgTClF1ZWVuc2xhbmQxGjAYBgNVBAoTEUNyeXB0U29mdCBQdHkgTHRkMRswGQYD
dp7jnmWZwKZ9cXsNUS2o4OL07qOk2HOywC0YsNZQsOBu1CBTYYkIefDiKFL1zQHh
8lwwNd4NP+OE3NzUNkCfh4DnFfg9WHkXUlD5UpxNRJ4gJA==                
-----END CERTIFICATE-----                                       

You can also generate a temporary (untrusted) test certificate by running:

openssl req -new -key key.pem -out cert.pem -x509 -config ..\config\openssl.cnf

You can get a 21 day temporary untrusted certificate from Thawte at Thawte.com. For internal corporate use, you might want to get a free trial certificate server from Verisign (choose Apache-SSL) or from Thawte (chose Generate an X.509v3 certificate & Use the most basic format).

The certificate file recieved from VeriSign or Thawte must be placed in the config directory and either named cert.pem or the Certificate File parameter in the config.ini file must be modified to the name of the file containing the certificate. Similarly, the private key file must be named key.pem or the Private Key File parameter in the config.ini file must be modified. Finally, the CA Certificate File parameter in the config.ini file should be configured to be ca-bundle.crt (included in the default installation).

Starting the HTTPS Server
The HTTPS server does not start by default, it must be enabled via the config.ini file entry Act As HTTPS Server = true. By default, the HTTPS server runs on port 443; this too can be changed via the config.ini entry HTTPS Port = 443.

SSL and Virtual Hosts
Presently, only a single private key and certificate file can be configured for the Sambar Server. As a result of this implementation, the SSL package cannot be used with virtual hosts. There appears to be a significant architectural limitation of SSL that prevents it from being used with virtual hosts. The problem is that the SSL handshake must come first (during which the CERT is exchanged) and then the HTTP header can be parsed; the HTTP Host: header is used to route the request to the appropriate virtual host. So a new CERT for each virtual host doesn't seem possible unless each host is associated with a separate IP address or server port.