Enabling TLS with MySQL

Modern SQL databases, such as MySQL, its variants and PostgreSQL, can protect communication between clients, such as Kea, and servers using SSL/TLS. In MySQL, the TLS configuration is split between clients and servers. As such, to enable TLS, both Kea and MySQL server configuration needs to be updated.

Checking the TLS support status of your MySQL installation

Most MySQL installations have TLS enabled during compilation time. However, some deployments may have it disabled. If it was compiled without a TLS support, recompilation or migration to a more modern MySQL installation is necessary. An excellent resource is Secure Connections Overview by MariaDB that explains how to check if the installation has TLS support. You can check the status with the following query:

SHOW GLOBAL VARIABLES LIKE 'have_ssl';

The interpretation of the result is:

If it is NO, then the server was not compiled with TLS support. You need to either recompile or install a different version.
If it is DISABLED, then the server was compiled with TLS support, but TLS is not configured yet. You need to tweak your MySQL configuration.
If it is YES, then the server was compiled with TLS support, and TLS is enabled. Your MySQL should be ready to accept TLS connections from Kea.

Here's a good documentation about enabling TLS for MariaDB. Note that the TLS support depends on the crypto library (OpenSSL in most cases) capabilities. Sometimes, an update to OpenSSL library is necessary.

Enable TLS support on MariaDB

First, you need a server certificate, a private key and a certificate of the Certificate Authority (CA) that issued them. How you get them is very deployment specific. Larger organizations may have their own CA. A good example is described in Certificate Creation with OpenSSL explains how to generate everything on your own if you don't have a real CA that could issue the certificates for you.

Second, you should update the MySQL configuration. Again, this is very deployment specific, but the configuration files are typically stored in /etc/mysql/. You should add the following entries there:

[mysqld]
ssl_cert = /etc/mysql/tls/server-cert.pem
ssl_key = /etc/mysql/tls/server-key.pem
ssl_ca = /etc/mysql/tls/ca.pem

Care should be taken so the MySQL process is able to read the files. Note that server-key.pem (and all other private keys) are generated by OpenSSL with 600 permissions, meaning only the owner of the file is able to read them. Usually, the following command will solve the problem:

sudo chown mysql.mysql /etc/mysql/tls/*.pem

Enabling TLS support on Kea

To enable TLS support on Kea, you need the CA certificate (which in most cases will be the same used for the server), Kea's secret key and Kea's certificate. One way to self-generate those certificates is as follows. To generate a CSR (Certificate Signing Request), use this command:

openssl req -newkey rsa:2048 -days 365000 -nodes -keyout kea-key.pem -out kea-req.pem

And then use the CA's certificate and CA's secret key to generate certificate for Kea:

openssl x509 -req -in kea-req.pem -days 365000 -CA /etc/mysql/tls/ca.pem -CAkey /etc/mysql/tls/ca-key.pem -set_serial 01 -out kea-cert.pem

As a result, you should have kea-cert.pem (Kea certificate), kea-key.pem (Kea secret key) and kea-req.pem (Kea signing request, no longer needed). You can update your Kea configuration file to point to those files. You typically want to update the lease-database, hosts-database and possibly config-databases. An example lease database configuration could look like this:

  "lease-database": {
    "type": "mysql",
    "name": "keatest",
    "user": "keatest",
    "password": "secret1",
    "host": "localhost",
    "port": 3306,
    "trust-anchor": "/etc/mysql/tls/ca.pem",
    "cert-file": "/etc/kea/tls/kea-cert.pem",
    "key-file": "/etc/kea/tls/kea-key.pem"
  },

When you start Kea, you should see the logs similar to this:

$ kea-dhcp4 -c mysql-ssl.json 
2022-03-14 19:28:53.787 INFO  [kea-dhcp4.dhcp4/527862.140606264556544] DHCP4_STARTING Kea DHCPv4 server version 2.1.4-git (development) starting
...
2022-03-14 19:28:53.790 INFO  [kea-dhcp4.dhcpsrv/527862.140606264556544] DHCPSRV_MYSQL_DB opening MySQL lease database: cert-file=kea-cert.pem host=localhost key-file=kea-key.pem max-reconnect-tries=3 name=keatest password=***** port=3306 reconnect-wait-time=3000 trust-anchor=/etc/mysql/tls/ca.pem type=mysql universe=4 user=keatest
...

An example configuration file for Kea DHCPv4 is provided here: mysql-ssl.json. The DHCPv6 database configuration is identical.

Optional hardening

The TLS protocol allows several modes of operation. The server authentication is a model that is frequently used by bank website. The client (web browser) will check if the server (the bank) is legitimate or not, but the server won't verify client on the TLS level. Typically that verification is done with other means, such as user credentials and 2FA. This is less secure.

The more secure, but harder to deploy alternative is to have mutual authentication, or Client Certificate Verification as it's being called by the MariaDB documentation. We recommend to enable mutual authentication so clients validates the server certificate and the server validates client certificates. You can go further on the the second point to check the client is really this one so protect against an authorized client faking another one.

NOTE: If you do not use client certificate verification, the traffic is encrypted so protected against eavesdropping. This is enough against offline attacks but of course not against inline attacks as Man-in-the-Middle.

NOTE: Certificate Revocation Lists (CRLs) and similar features are complex to administrate without a clear benefit. You can still use them but only in the MySQL configuration.

The optional peer certificate validate which is the only point where you can get differences between MySQL variants. If you want to enable this, please consult your MySQL or MariaDB documentation.

It should be possible which certificates can be used to access specific databases, although this has not been tested. "require SSL' is not enough, if you control what users use as their entity certificates you should constraint connections from users using for instance 'REQUIRE SUBJECT' per user clause. This is done when creating or altering MySQL users.