Tag Archives: debian

Debian Install SSL Certificates for Apache OpenSSL

Something else that I do not do often and have never documented is the install of an SSL certificate on Debian servers for use with Apache / OpenSSL. For this post I am assuming that an existing SSL certificate has been purchased. I use a lot of wildcard certificates for multiple servers rather than a certificate per site / server.

Go to this directory

[text]# cd /etc/ssl/private/[/text]

By default there is a self-signed certificate key ssl-cert-snakeoil.key in the directory

This directory is restricted to root user and ssl-cert group.

Using an existing certificate, key, and intermediate certificate, create a file for each in the same directory.

Change the relevant ownership

[text]# chown root:ssl-cert *[/text]

and change the access

[text]#chmod 640 *[/text]

This should provide something like:

[text]

/etc/ssl/private# ls -la
drwx–x— 2 root ssl-cert 4096 Apr 14 12:12 .
drwxr-xr-x 4 root root     4096 Mar 28 08:41 ..
-rw-r—– 1 root ssl-cert 1589 Apr 14 12:11 mydomain-intermediate.crt
-rw-r—– 1 root ssl-cert 1704 Mar 20 23:25 ssl-cert-snakeoil.key
-rw-r—– 1 root ssl-cert 2049 Apr 14 12:10 mydomain-cert.crt
-rw-r—– 1 root ssl-cert 1678 Apr 14 12:13 mydomain-key.key

[/text]

Ok, now off to the Apache config

[text]# cd /etc/apache2/sites-available/[/text]

and edit the site file that is relevant so that the Virtual Host *:443 section includes the correct paths to the above certificate files

[text]
# Example SSL configuration
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
SSLCertificateChainFile "/etc/ssl/private/mydomain-intermediate.crt"
SSLCertificateFile "/etc/ssl/private/mydomain-cert.crt"
SSLCertificateKeyFile "/etc/ssl/private/mydomain-key.key"

[/text]

If there is no Virtual Host *:443 section then there should be an existing VirtualHost *:80 for the website and this can be copied / duplicated in the same file, just change the port in the copy from 80 to 443 and insert the above Example SSL lines at the bottom of the new section above the closing tag.

If Apache is a fresh install it may not have SSL enabled

[text]#a2enmod ssl [/text]

Test Apache syntax

[text]#apachectl -t [/text]

Restart Apache
[text]#apachectl graceful [/text]
or
[text]#service apache2 restart [/text]
depending on what you need for existing sites on the server.

 

Debian Linux openvpn connect to Watchguard VPN

I have a Debian Server that I wanted to connect to a Watchguard VPN.

OpenVPN is the tool that I used and the following is based on JoKi’s excellent blog entry with my own adjustments to address the issues that I found.

To start you do need to install and run a connection using the Watchguard MobileVPN on your Windows box to get the configuration files in

C:Usersyour_user_name_hereAppDataRoamingWatchGuardMobile VPN

It took me a while to work out that I had to run it to get the config files created, installing alone is not enough.

Installation in Debian is straightforward

#apt-get install openvpn

Once that is done go to the newly created /etc/openvpn and copy the files from the abovementioned Watchguard directory to it.

ca.crt
client.crt
client.ovpn
client.pem

Now it should all be good to go.

#openvpn --config client.ovpn

Except that I was getting all sorts of errors and warnings……

Wed Nov 12 12:16:50 2014 VERIFY X509NAME ERROR: /O=watchguard_technologies/0.0=f ireware/CN=fireware_sslvpn_server, must be /O=watchguard_technologies/ITU-T=fire ware/CN=fireware_sslvpn_server
Wed Nov 12 12:16:50 2014 TLS_ERROR: BIO read tls_read_plaintext error: error:140 90086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Wed Nov 12 12:16:50 2014 TLS Error: TLS object -> incoming plaintext read error
Wed Nov 12 12:16:50 2014 TLS Error: TLS handshake failed
Wed Nov 12 12:16:50 2014 Fatal TLS error (check_tls_errors_co), restarting
Wed Nov 12 12:16:50 2014 SIGUSR1[soft,tls-error] received, process restarting
Wed Nov 12 12:16:50 2014 Restart pause, 5 second(s)

Everything I read said that the certificate files would be the issue, but that was not logical to me as they were direct from the Watchguard device and not ones I was creating.

But I checked them anyway with

#openssl verify -CAfile ca.crt client.crt

Next I tried addressing the verify X509 Name error by changing the client.ovpn file entry changing

tls-remote

to

verify-x509-name

and messed around with that for a while until in disgust I commented the line out to try and confirm that it was triggering the error.

Of course, it worked first time !!!  Argghhhh!!

So the answer to the above is to remove the tls-remote line completely from the configuration file.

tls-remote “/O=watchguard_technologies/ITU-T=fireware/CN=fireware_sslvpn_server”

Either comment it with # at the start of the line or delete it.

Once that was sorted I had a working connection all that remained was to

#mv client.ovpn client.conf

create an auth.txt file with

myusername
mysecretpassword

#chmod to 0600 auth.txt

Edit the client.conf file to have

auth-user-pass auth.txt

and finally start it as a service
#service openvpn start client

and the last bit of the puzzle, to add it as a service to automatically start

#update-rc.d openvpn enable

Thanks to JoKi for getting me started.

Shellshock BASH Vulnerability: Debian, CentOS, Synology Busybox

Ok, so Heartbleed did as it said, and Shellshock is about to do the same.

I manage some CentOS, some Redhat, some Debian, and other servers. From what I have found so far, and assuming that the patches applied to the latest release of BASH are sufficient, then most servers and devices can be patched / fixed so that they are not vulnerable quite easily.

According to most sources, the test for a vulnerable BASH environment is the following line of code:

[text]
env x='() { :;}; echo vulnerable’ bash -c "echo this is a test"
[/text]

So I quickly hit one of each server / Linux flavour I could think of and these are the results:

SME Server / CentOS based

[text]
# env x='() { :;}; echo vulnerable’ bash -c "echo this is a test"
vulnerable
this is a test
[/text]

so I ran

[text]
# yum update
[/text]

which updates a number of tools including bash-3.2-33.el5.1.i386.rpm which appears to be the correct update version and re-testing after updating the server (includes other updates as well) gives the ‘not vulnerable’ response.

CPanel on CentOS

[text]
# env x='() { :;}; echo vulnerable’ bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x’
this is a test
#
[/text]

which appears to tell me that it is not vulnerable.

I also had a similar message but without the warning from a second CPanel / CentOS server which is configured slightly differently:

[text]
# env x='() { :;}; echo vulnerable’ bash -c "echo this is a test"
this is a test
#
[/text]

The lack of a warning in the above appears to indicate that it is not vulnerable.

Debian

Some of my Debian servers have not been upgraded from stable Squeeze, which I should be updating to Wheezy. I found different responses depending on which version of Debian existed on the server.

To check the Debian version use:
[text]
# cat /etc/debian_version
# 6.0.6
[/text]

Checking the Debian version just as a confirmation of what patch release the server is using.

Debian Squeeze 6.0.6

[text]
# env x='() { :;}; echo vulnerable’ bash -c "echo this is a test"
vulnerable
this is a test
#
[/text]

Vulnerable, so update BASH

[text]
# apt-get update
# apt-get install bash
[/text]

A second test shows:

[text]
# env x='() { :;}; echo vulnerable’ bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x’
this is a test
#

<h2>Debian Squeeze 6.0.10</h2>

This one is a work in progress……

<h2>Debian Squeeze 7.4</h2>

This version of Debian was straightforward and

[text]
# env x='() { :;}; echo vulnerable’ bash -c "echo this is a test"
vulnerable
this is a test
#
[/text]

Oops!

[text]
# apt-get update
# apt-get install bash
[/text]

A second test shows:

[text]
# env x='() { :;}; echo vulnerable’ bash -c "echo this is a test"
this is a test
#

<h2>Synology Busybox</h2>

Synology Busybox uses ASH not BASH but testing can still be done

[text]
# env x='() { :;}; echo vulnerable’ ash -c "echo this is a test"
[/text]

Gave an all clear message on my recently updated Synology unit.