LPI Linux Certification/Maintaining A Web Server

208.2 Maintaining A Web Server

Detailed Objectives (208.2)

(LPIC-2 Version 4.5)

Weight: 3

Description: Candidates should be able to configure a web server to provide HTTPS.

Key knowledge areas

• SSL configuration files, tools and utilities.
• Generate a server private key and CSR for a commercial CA.
• Generate a self-signed Certificate.
• Install the key and certificate, including intermediate CAs.
• Configure Virtual Hosting using SNI.
• Awareness of the issues with Virtual Hosting and use of SSL.
• Security issues in SSL use, disable insecure protocols and ciphers.

Terms and Utilities:

• Apache2 configuration files
• /etc/ssl/, /etc/pki/
• openssl, CA.pl
• SSLEngine, SSLCertificateKeyFile, SSLCertificateFile
• SSLCACertificateFile, SSLCACertificatePath
• SSLProtocol, SSLCipherSuite, ServerTokens, ServerSignature, TraceEnable

Overview

Apache is an impressive and powerful application. It is not only able to serve simple (static) HTTP pages, which is (essentially) a trivial task. Apache can host multiple web sites (http://www.example.com and http://www.beispiel.de) on one physical machine at one IP address using one Apache process by using "virtual hosts". Apache can also use multiple IP addresses to store different web sites on the same physical machine, which does not (necessarily) need different networking card. This is also realized by "virtual hosts".

Also, Apache can use very sophisticated methods to redirect queries.

Most importantly, at least to me, is the use SSL (as OpenSSL). SSL can do many things for many people: it can secure (encrypt) the content going back and forth between the web client and the web server. It can also ensure the identity of both parties communicating, the server and the client.

Virtual Hosts

VirtualHost sections contain directives that apply only to a specific hostname or IP address. See [1] and [2]

OpenSSL

OpenSSL(link) is a collection of tools that implement and handle certificates(link) that conform to the Transport Layer Security (TLS) ??? protocol(link).

What are certificates?

Secure Socket Layer (SSL)(link), or Transport Layer Security (TLS)(link) as SSL versions beyond 3 are called now, uses Public Key Cryptography(link) to protect transactions over the insecure and not secureable internet. Like all public key cryptographic schemes (I know of) TLS uses a secret private key and an openly shared public key, called a certificate. The special twist with TLS certificates is the certification authority (CA)(link). For a TLS certificate to be recognized as valid, it has to be (cryptographically) signed by a "Certification Authority".

Flashback Public Key Crypto

In a nutshell, public key crypto works like this: there are two keys, one public key for everyone to have, and one private key, for my eyes only. The private key is also (usually) protected by a very strong password.

Both keys can be used to encrypt data that only the other key can decrypt. There is in principle no difference between the public and private key!

On the other hand side it seems to make no sense to encrypt data with your private key, because everyone on the internet has already or can get your public key and decrypt the data. But if you encrypt data with your private key, you can prove you are in possession of the private key. This way you can (cryptographically) sign the data. To sign a piece of data we usually don't encrypt the whole but a (cryptographic) hash(link) of it and so can prove the authenticity of the data, provided we guard our private key very carefully. The password simply is a second security measure, in case the private key leaked into the public or gets lost.

What does a CA do exactly?

A Certification Authority signs our public keys with its private key. Then they are called certificates. Thats it! Almost. We send in a "certificate signing request" (more on this later), a claim of your identity and a varying sum of money and the CA tries (depending on the amount of money we spent) to check our identity and if succeeded will sign our request and finally send back the signed certificate. But keep in mind that there is only so much The Hong Kong Post Office(TM) (or any other CA) can do to verify e. g. a Brazilian identity. But now the problem is to get the certificate of the CA... and here the trick is: we already have it! Most pieces of software that can use TLS certificates come with a list of trusted (this is the magic word) CAs. Any new certificate (e. g. shop.example.com) signed by this trusted CAs (e. g. by StartSSL) with their certificates installed on our machines is also regarded as trusted. Unsigned certificates or ones signed by unknown CA are regarded as "not trusted" an we are presented with a dire warning.

How do certificates work exactly?

We can use TLS certificates with almost any insecure service on the internet, if we only try hard enough.

• Web browsing (HTTPS instead of HTTP)
• Sending Mail (SMTPS instead of SMTP)
• Receiving Mail (IMAPS instead of IMAP/POP3S instead of POP3)
• Chat (IRC over TLS)
• VPN (OpenVPN)

How does it work (for web surfing)? A bit simplified:

1. the client connects to the server
2. the server sends over the certificate
3. the client checks certain properties of the certificate
   1. the certificate is bound to the Full Qualified Host Name (FQHN) of the server we connect to. The web browser checks if the FQHN of the server and the certificate match, if not it generates an error.
   2. the certificate needs to be signed by a trusted CA, if not the web browser generates an error.
   3. certificates have a limited lifetime, depending on the amount of money we paid. The web browser checks if the certificate is still "fresh" and if not, it generates an error.
   4. there is a list of invalid certificates on our computer. These certificates are revoked for different reasons: they were compromised, had errors, were stolen, ... If the server certificate is on that list, the client software generates an error.
4. if the certificate is deemed valid (or if an invalid certificate is accepted, despite being not valid) the client encrypts a random value with the certificate and sends it to the server.
5. only the client (because he generated it) and the server (because only he can decrypt it) know the random value, generated by the client
6. from the random value a symmetric key is generated on both ends and any further communication both ways is encrypted with this generated key. (A symmetric key is used, because encryption and decryption are much easier to handle by the CPU.)

How to find and use certificates

CA root certificates are stored on our computers in lots of different places. Often every piece of software that uses TLS brings their own list of trusted CAs.

• openssl: /etc/ssl/certs
• firefox:
• thunderbird:
• claws-mail: ~/.claws-mail/certs/

On the other hand side openssl can act as an TLS client for classical "clear text" protocols like, well like all the internet protocols, e. g. POP3