Procedure B.5. Configuring a Squid Proxy

1. Obtaining a Keypair

   Obtain a keypair and certificate for the HTTPS port of the Squid proxy server.
   You can obtain this keypair the same way that you would obtain a keypair for another SSL/TLS service. The keypair is in the form of two PEM files which contain the private key and the signed certificate. In this document we assume that they are named proxy.key and proxy.cer.
   The keypair and certificate can also be generated using the certificate authority of the oVirt engine. If you already have the private key and certificate for the proxy and do not want to generate it with the oVirt engine certificate authority, skip to the next step.

2. Generating a Keypair

   Decide on a host name for the proxy. In this procedure, the proxy is called proxy.example.com.
   Decide on the rest of the distinguished name of the certificate for the proxy. The important part here is the "common name", which contains the host name of the proxy. Users' browsers use the common name to validate the connection. It is good practice to use the same country and same organization name used by the oVirt engine itself. Find this information by logging in to the oVirt engine machine and running the following command:

   [root@engine ~]# openssl x509 -in /etc/pki/ovirt-engine/ca.pem -noout -subject
   

   This command will output something like this:

   subject= /C=US/O=Example Inc./CN=engine.example.com.81108
   

   The relevant part here is /C=us/O=Example Inc.. Use this to build the complete distinguished name for the certificate for the proxy:

   /C=US/O=Example Inc./CN=proxy.example.com
   

   Log in to the proxy machine and generate a certificate signing request:

   [root@proxy ~]# openssl req -newkey rsa:2048 -subj '/C=US/O=Example Inc./CN=proxy.example.com' -nodes -keyout proxy.key -out proxy.req
   

   Note

   The quotes around the distinguished name for the certificate are very important. Do not leave them out.
   The command will generate the key pair. It is very important that the private key isn't encrypted (that is the effect of the -nodes option) because otherwise you would need to type the password to start the proxy server.
   The output of the command looks like this:

   Generating a 2048 bit RSA private key
   ......................................................+++
   .................................................................................+++
   writing new private key to 'proxy.key'
   -----
   

   The command will generate two files: proxy.key and proxy.req. proxy.key is the private key. Keep this file safe. proxy.req is the certificate signing request. proxy.req doesn't require any special protection.
   To generate the signed certificate, copy the private.csr file to the oVirt engine machine, using the scp command:

   [root@proxy ~]# scp proxy.req engine.example.com:/etc/pki/ovirt-engine/requests/.
   

   Log in to the oVirt engine machine and run the following command to sign the certificate:

   [root@engine ~]# /usr/share/ovirt-engine/bin/pki-enroll-request.sh --name=proxy --days=3650 --subject='/C=US/O=Example Inc./CN=proxy.example.com'
   

   This will sign the certificate and make it valid for 10 years (3650 days). Set the certificate to expire earlier, if you prefer.
   The output of the command looks like this:

   Using configuration from openssl.conf
   Check that the request matches the signature
   Signature ok
   The Subject's Distinguished Name is as follows
   countryName           :PRINTABLE:'US'
   organizationName      :PRINTABLE:'Example Inc.'
   commonName            :PRINTABLE:'proxy.example.com'
   Certificate is to be certified until Jul 10 10:05:24 2023 GMT (3650
   days)
   
   Write out database with 1 new entries
   Data Base Updated
   

   The generated certificate file is available in the directory /etc/pki/ovirt-engine/certs and should be named proxy.cer. Copy this file to the proxy machine:

   [root@proxy ~]# scp engine.example.com:/etc/pki/ovirt-engine/certs/proxy.cer .
   

   Make sure that both the proxy.key and proxy.cer files are present on the proxy machine:

   [root@proxy ~]# ls -l proxy.key proxy.cer
   

   The output of this command will look like this:

   -rw-r--r--. 1 root root 4902 Jul 12 12:11 proxy.cer
   -rw-r--r--. 1 root root 1834 Jul 12 11:58 proxy.key
   

   You are now ready to install and configure the proxy server.

3. Install the Squid proxy server package

   Install this system as follows:

   [root@proxy ~]# yum -y install squid
   

4. Configure the Squid proxy server

   Move the private key and signed certificate to a place where the proxy can access them, for example to the /etc/squid directory:

   [root@proxy ~]# cp proxy.key proxy.cer /etc/squid/.
   

   Set permissions so that the "squid" user can read these files:

   [root@proxy ~]# chgrp squid /etc/squid/proxy.*
   [root@proxy ~]# chmod 640 /etc/squid/proxy.*
   

   The Squid proxy will connect to the oVirt engine web server using the SSL protocol, and must verify the certificate used by the engine. Copy the certificate of the CA that signed the certificate of the oVirt engine web server to a place where the proxy can access it, for example /etc/squid. The default CA certificate is located in the /etc/pki/ovirt-engine/ca.pem file in the oVirt engine machine. Copy it with the following command:

   [root@proxy ~]# scp engine.example.com:/etc/pki/ovirt-engine/ca.pem /etc/squid/.
   

   Make sure that the "squid" user can read that file:

   [root@proxy ~]# chgrp squid /etc/squid/ca.pem
   [root@proxy ~]# chmod 640 /etc/squid/ca.pem
   

   If SELinux is in enforcing mode, change the context of port 443 using the semanage tool. This permits Squid to use port 443.

   [root@proxy ~]# yum install -y policycoreutils-python
   [root@proxy ~]# semanage port -m -p tcp -t http_cache_port_t 443
   

   Replace the existing squid configuration file with the following:

   https_port 443 key=/etc/squid/proxy.key cert=/etc/squid/proxy.cer ssl-bump defaultsite=engine.example.com
   cache_peer engine.example.com parent 443 0 no-query originserver ssl sslcafile=/etc/squid/ca.pem name=engine
   cache_peer_access engine allow all
   ssl_bump allow all
   http_access allow all
   

5. Restart the Squid Proxy Server

   Run the following command in the proxy machine:

   [root@proxy ~]# service squid restart
   

6. Configure the websockets proxy

   Note

   This step is optional. Do this step only if you want to use the noVNC console or the Spice HTML 5 console.
   To use the noVNC or Spice HTML 5 consoles to connect to the console of virtual machines, the websocket proxy server must be configured on the machine on which the engine is installed. If you selected to configure the websocket proxy server when prompted during installing or upgrading the engine with the engine-setup command, the websocket proxy server will already be configured. If you did not select to configure the websocket proxy server at this time, you can configure it later by running the engine-setup command with the following option:

   engine-setup --otopi-environment="OVESETUP_CONFIG/websocketProxyConfig=bool:True"

   You must also make sure that the ovirt-websocket-proxy service is started and will start automatically on boot:

   [root@engine ~]# service ovirt-websocket-proxy status
   [root@engine ~]# chkconfig ovirt-websocket-proxy on

   Both the noVNC and the Spice HTML 5 consoles use the websocket protocol to connect to the virtual machines, but squid proxy server does not support the websockets protocol, so this communication cannot be proxied with Squid. Tell the system to connect directly to the websockets proxy running in the machine where the engine is running. To do this, update the WebSocketProxy configuration parameter using the "engine-config" tool:

   [root@engine ~]# engine-config \
   -s WebSocketProxy=engine.example.com:6100
   [root@engine ~]# service ovirt-engine restart

   Important

   If you skip this step the clients will assume that the websockets proxy is running in the proxy machine, and thus will fail to connect.

7. Connect to the user portal using the complete URL

   Connect to the User Portal using the complete URL, for instance:

   https://proxy.example.com/UserPortal/org.ovirt.engine.ui.userportal.UserPortal/UserPortal.html

   Note

   Shorter URLs, for example https://proxy.example.com/UserPortal, will not work. These shorter URLs are redirected to the long URL by the application server, using the 302 response code and the Location header. The version of Squid in Red Hat Enterprise Linux and Fedora (Squid version 3.1) does not support rewriting these headers.