Damit man über einen Reverse-Proxy auf einen Web-Server zugreifen kann, welcher seinerseits wieder mit HTTP Basic Authentifizierung geschützt ist (und im Backend andere Login-Informationen als für die Anmeldung am Reverse Proxy erforderlich sind), muss die HTTP-Authentifizierung für den Backend-Server im Proxy-Abschnitt mitgegeben werden.

Dazu muss zuerst Benutzername und Passwort in eine Base64-Zeichenkette encodiert werden:

echo -n "User:Pass" | base64
VXNlcjpQYXNz

(auch wenn kein Benutzername benutzt wird, muss das Doppelpunkt im zu encodierenden String enthalten sein!)

Danach in der Konfiguration des als Reverse-Proxy verwendeten Frontend-Servers folgendes z.B. in einen Location-Abschnitt hinzufügen.

Apache:

RequestHeader set Authorization "Basic VXNlcjpQYXNz"

Nginx:

proxy_set_header Authorization "Basic VXNlcjpQYXNz";

Technischer Hintergrund:

Sofern dieselben Anmelde-Informationen im Backend verwendet werden wie im Frontend (Reverse-Proxy), sollte dieses bei der nachfolgenden HTTP-Auth Anfrage transparent vom Client Web-Browser weitergereicht werden, und obiger Parameter ist nicht notwendig.

Wird hingegen versucht, sich mit unterschiedlichen HTTP-Auth Passwörter anzumelden (zuerst dasjenige für den Reverse-Proxy, dann dasjenige, welches der Backend-Webserver verlangt), ist darauf sofort die Anmeldung am Proxy nicht mehr gültig -> Ein Zugriff würde so also nie funktionieren!

Add the following to your SSL configuration section:

   # Disable SSLv2 & SSLv3 against POODLE issue (CVE-2014-3566)
    SSLProtocol All -SSLv2 -SSLv3

Note to insert this to all VirtualHost sections where SSL is enabled!

Check your config:

apachectl configtest

Then restart apache server:

sudo service apache2 restart

To check if SSLv3 is turned off:

openssl s_client -connect server.domain.tld:443 -ssl3

Then you shold see a message like this:

error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1260:SSL alert number 40

To disable SSLv3 within other services:
see this post

First, set the common name (CN, ~FQDN) for the certificate:

CN=host.domain.tld

Change to the directory where you would like to store the data relevant for certificates, e.g.:

cd /etc/ssl

Then create a private key:

openssl genrsa -out private/${CN}.key 2048

Generate the signing Request, either:
a) interactively, you'll have to answer some questions...:

openssl req -new -key private/${CN}.key -out ${CN}.csr

b) using a customized openssl config file:

openssl req -new -config ${CN}-openssl.cnf -key private/${CN}.key -out ${CN}.csr

Now you may either:
a) send the certificate request to an (official or internal) Certificate Authority to sign the Certificate

b) for testing purposes only, you can also self-sign the certificate:

openssl x509 -req -days 1825 -in ${CN}.csr -signkey private/${CN}.key -out certs/${CN}.crt

When you have received signed (or self-signed) certificate, you can copy all the files to the appropriate location.

Probably you have to create a combined pkcs#12 (.p12, .pfx) file, containing private key and certificates:

openssl pkcs12 -export -in ${CN}.crt -certfile cafile.pem -inkey ${CN}.key -out ${CN}.pfx

(where cafile.pem is the ca certificate bundle of issuing certificate authority)

Clear the shell variable for the Common Name:

CN=

This small perl script removes a VirtualHost configuration section

Call with:

remove_virtual.pl <webname> <apache conf file>

<webname> is to be replaced with the FQDN of the name based virtual host (ServerName)

<apache conf file> is the full path to the apache configuration file that contains the VirtualHost