Although MySQL uses a clear text protocol by default, it can make use of secure connections. This is necessary if a MySQL client is to get service from a MySQL server over a network (such as the Internet) that cannot be trusted. This module discusses the concepts and steps to secure a MySQL database.
SSL (Secure Socket Layer) is now called TLS (Transport Layer Security). As the new name implies, SSL/TLS is a transport layer mechanism to ensure privacy. It can be used to secure any protocol that relies on TCP/IP.
SSL is a certificate-based protocol. This means that a server needs to have a certificate in order to service client requests. This should be contrasted to SSH, which is key-pair based. There are two advantages to a certificate based secure protocol. First, there is no need to establish an account on the server side. SSH requires an account be set up on the server side. Second, a certificate can be checked to ensure it is signed by a certificate authority, which makes it difficult for hackers to imitate a legitimate server.
From the networking perspective, SSL/TLS is an encapsulation mechanism. This means that each packet of the original protocol is encapsulated by an SSL/TLS envelope. SSH, on the other hand, is a tunneling protocol. As a tunneling protocol, there is no correlation between the tunneled packets and the tunneling packets.
By using an SSL/TLS library, many services can make use of SSL/TLS. For example, even protocols like Telnet and HTTP can be secured when they are encapsulated by SSL/TLS. MySQL is also linked with SSL/TLS libraries to enable the use of SSL/TLS.
To use SSL/TLS, you need to get a certificate for your server. Here is how to do it.
First, install openssl as a package. It includes the necessary tools to complete this process. Use aptitude install openssl to install the package.
First, you need to create a server key and a server certificate. Note that you can use the same key for Telnet, MySQL, HTTP, CUPS and etc. Run the following command as root after changing to /etc/ssl/private as the current working directory:
This step generates a private key for your machine. You should replace domain.key with the actual domain name. For example, use a file name like mysite.com.key. You will be prompted for a pass phrase. If you specify one, you will need to enter the pass phrase every time the private key is to be used. This includes the time when a server that depends on the certificate starts up.
If you want to configure a server to be able to start up without human intervention, you should consider not specifying a pass phrase. However, a private key that does not have pass phrase protection can be disastrous if fallen into the wrong hands!
Next, execute the following command:
This will prompt you for answers to some questions. You will be asked about Country Name, answer US for the United States. Then specify your state and city name. If you provide fake answers to these questions, a potential client my choose not to trust you. It is best to answer these questions properly unless you are merely testing a set up.
When you are asked the Organization Name, be sure to enter a company name or a an organization name, as accurately as possible. The Organizational Unit Name is optional, you may leave it empty if the certificate is to be used by the organization as a whole.
The Common Name is the most important part, as it will be used to identify the owner of the certificate. You should use the fully qualified domain name of the server as the answer. The Email Address is optional, but it allows someone, such as a signing authority, to email you before trusting the certificate.
As the last step, you can optionally specify a challenge password and a company name.
After you answer all the questions, a CSR (certificate signing request) file is created as domain.csr.
A CSR includes all the answers of the questions, along with the public key that corresponds to the private key generated by the first step.
You have two options here. If you are merely testing SSL/TLS, or your server is only to serve clients that you operate, you can self-sign the certificate. However, if your server may be accessed by people that you may not know personally, it is best to have the certificate signed by a certificate authority (CA).
To get the certificate signed by a CA, you have to send the CSR file (or copy-and-paste its content) to a CA. The CA will, then, use the whois data of your domain (if a domain name is registered) to determine who to contact to confirm the authenticity of the request. Once authenticity is verified, a CA will send back a certificate file. You should save that as domain.crt.
If self signing will suffice, this is how you do it:
First, become a self-claimed CA. To do this, you need to create another private key as a CA:
Next, create a self-signed certificate as a CA, be sure that the Common name part is different from what you used earlier to create domain.csr!
Now that you are a self-claimed CA, you can sign certificates.
This creates a certificate that is self signed. A self signed certificate will not be trusted by anyone because the originator can self claim to be any organization. It will be sufficient for testing purposes, or be used by people who can trust the origin of the self-signed certificate.
It is time to handle the files created so far. The /etc/ssl/private folder should be protected from all except root. In Debian distributions, the folder is set up to only allow root (rwx) and members of the group ssl-cert (--x) access to its content.
The private key files, domain.key and ca.key, must remain in the protected folder. You should also double check that the file itself is accessible only by the root user.
However, the certificates (ca.crt and domain.crt) can be moved to /etc/ssl/certs.