...

The old (Windows 2003) server runs SQL Server 2000, but starting from release 404 (July 2012), the Exact software does not support this any more. So  So I had to upgrade to SQL Server 2008 R2.

This supports IPv6 just fine. All users in accounting all run Windows 7, so the operating system itself shouldn't be a problem, but I was a bit wary of potential client side application issues. While While testing I quickly found out that the Exact application was using ODBC, which did support IPv6 right away, so the application works on IPv6 .

Delta software

This is proprietary software made by Dutch company BCS BCS HRM en Salarisadministratie B.V..

Recently we bought a server license, and after some research I found out that is made up of a network share with files, and a database component.

The network share can do IPv6 as mentioned earlier.

Sybase SQL AnyWhere

The database is a Windows Service, based on a file called dbeng11.exe. It's not stated as such in the BCS documentation, but this is an instance of SQL AnyWhere Personal Server:

Image Modified

The BCS support desk had no clue what IPv6 was, so I did some research myself.

There is a nice and very clear PDF that explains SQL AnyWhere networking essentials. According  According to this document, SQL AnyWhere supports IPv6 from version 10, which is from 2006. Version  Version 11 and 12 support it explicitly. These docs came in handy because they list some special connection options that I needed.

Since we only have one instance of SQL Anywhere, which is running in a different network than the clients, I figured it didn't make much sense to implement the broadcast/multicast stuff that is needed for the service discovery. Instead, I hardcoded the server FQDN, which worked fine. After  After opening up TCP port 2638 the software worked 

Crypto

I wasn't really sure how safe this SQL Server traffic was, but running Wireshark revealed plain text SQL queries on the wire . I think it's good practice to encrypt traffic containing personal data, even though it's inside our own network. SQL Server 2008 R2 supports SSL encryption, and because because we get "free" SSL certificates through through SURFnet (which is part of the TERENA Certificate Service), we should be good to go!

I created the cryptographic materials on one of our Ubuntu systems because those already have OpenSSL installed. All of this is also perfectly possible on Windows, but you do need some extra bits such as Microsoft Visual C++ 2008. I just didn't want to pollute my Windows system with extra software that is already installed elsewhere in our network.

openssl req -new -keyout server.key -out server.csr -subj /CN=hayek.terena.org/

...

cp cert-11988-hayek.terena.org.pem all.pem
cat chain-11988-hayek.terena.org.pem >> all.pem
openssl pkcs12 -export -inkey server.key -in all.pem -out server.pfx

After copying the PFX file to the Windows server, I ran mmc and added and added the Certificates snap-in. When  When it asked for who to manage certificates, I selected the selected the "Local System" account, because I was running the snap-in as Administrator.

Expand: Console Root -> Certificates (Local Computer) -> Personal.

Right-click -> All Tasks -> Import. Navigated to Navigated to the pfx file and imported it, including all extended properties.

I kept "Mark this key as exportable" unchecked, as I already have the key materials in a different place. I figured that since it is not needed on this machine, we might as well disable it, so any future malicious export attempts will be impossible (or at least more difficult).

Configuring MS SQL Server to use the certificate

...

In my case nothing would show up 

According to this Howto, the the name of the certificate must be the fully qualified domain name (FQDN) of the computer. Since the TCS certificates we use can only contain a valid FQDN as the Subject's Common Name (CN), this had to be correct. I checked permissions and those seemed to be OK as well.

...

Since we now have a nice server certificate in the Windows Certificate Store, I figured I might as well use it to secure more services that run of this machine. The most obvious service is of course the channel by which the machine is managed: Remote Desktop Protocol (RDP). Based  Based on the docs, RDP does support SSL (TLS1.0). The installed certificate can be configured with the Remote Desktop Session Host Configuration. While at it, I also selected to only use SSL (TLS 1.0), and High Encryption level:

Using Wireshark it is again easy to spot that the session is encrypted.

...

All of this stuff is very nice, but what good is a service when it is not being monitored?

We already run a Nagios-3.2 instance on an Ubuntu system in a remote data centre, and my goal is to monitor as much services on my new Windows host as possible.

Host alive

The check-host-alive test is a basic test from the nagios-plugins-basic package, and is based on check_ping, which can do IPv4 and IPv6, and defaults to IPv4. It  It is defined in /etc/nagios-plugins/config/ping.cfg.  Interestingly Interestingly, there are checks to deal with dual stack monitoring:

####
# use these checks, if you want to test IPv4 connectivity on IPv6 enabled systems
####
 
# 'check-host-alive_4' command definition
define command{
    command_name    check-host-alive_4
    command_line    /usr/lib/nagios/plugins/check_ping -H '$HOSTADDRESS$' -w 5000,100% -c 5000,100% -p 1 -4
    }

...

Now that the server has an SSL certificate, it should be monitored so that we get a warning when it is about to expire in about 3 years. The  The way I usually do this is by using a Nagios plugin to monitor a service that uses the certificate, and then pick the certificate expiration option of the plugin. For  For example the check_smtp plugin has this option:

 -D, --certificate=INTEGER
    Minimum number of days a certificate has to be valid.

The common way to test this sort of stuff is with OpenSSL's s_client, but unfortunately that does not support IPv6. Off then to GnuTLS.

Connecting to SQL Server on port 1433 does not do anything, so that's a dead end. Connecting  Connecting to RDP on port 3389 however happens with a nice TLS 1.0 handshake 

bofh@nagios:~$ gnutls-cli hayek.terena.org -p 3389 --x509cafile /etc/ssl/certs/ca-certificates.crt
Processed 142 CA certificate(s).
Resolving 'hayek.terena.org'...
Connecting to '2001:610:148:bad:250:56ff:fe86:9:3389'...
- Certificate type: X.509
 - Got a certificate list of 3 certificates.
 - Certificate[0] info:
  - subject `C=NL,O=TERENA,OU=CFO,CN=hayek.terena.org', issuer `C=NL,O=TERENA,CN=TERENA SSL CA', RSA key 2048 bits, signed using RSA-SHA, activated `2013-01-23 00:00:00 UTC', expires `2016-01-23 23:59:59 UTC', SHA-1 fingerprint `513523a823b8d5c15c30a80f2772e58d826605ba'
 - Certificate[1] info:
  - subject `C=NL,O=TERENA,CN=TERENA SSL CA', issuer `C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware', RSA key 2048 bits, signed using RSA-SHA, activated `2009-05-18 00:00:00 UTC', expires `2020-05-30 10:48:38 UTC', SHA-1 fingerprint `3a881764472b6441ddb3afdd47c6b8b76ee7ba1d'
 - Certificate[2] info:
  - subject `C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware', issuer `C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root', RSA key 2048 bits, signed using RSA-SHA, activated `2005-06-07 08:09:10 UTC', expires `2020-05-30 10:48:38 UTC', SHA-1 fingerprint `3d4b2a4c64317143f50258d7e6fd7d3c021a529e'
- The hostname in the certificate matches 'hayek.terena.org'.
- Peer's certificate is trusted
- Version: TLS1.0
- Key Exchange: RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed

This indicates that it possible to monitor the certificate the same way as with HTTPS web sites. I tested this and it works 

Concluding, this is what the monitoring looks like in the end:

...