mysql v3 certs

_posts/2023-04-10-mysql-ssl-guide.md

@@ -7,7 +7,7 @@ date: 2023-04-10
 
 By default, all communication between a MySQL or MariaDB server and its clients is unencrypted. That's fine if both the database server and client are on the same machine, or connected by a network you fully control, but as soon as anything touches the internet — or even an internal data center network the [NSA may have secretly tapped into](https://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html) — all bets are off, and you need SSL to ensure that the communication cannot be spied on or tampered with. This post will guide you through the entire process in an abundance of detail.
 
-To be clear, I'm no expert on cryptography, and I certainly wasn't expecting to be writing a whole tutorial on setting up SSL for MySQL / MariaDB + PHP within hours of getting mine to work, but while researching this I found so much outdated or just straight up bad information that I took time to dig deep into every step of the process. While reading this guide, you should never feel you're being told to run a command or change some code without an explanation that justifies the decision.
+To be clear, I'm no expert on cryptography, and I certainly wasn't expecting to be writing a whole tutorial on setting up SSL for MySQL / MariaDB + PHP within hours of getting mine to work, but while researching this I found so much outdated or just straight up bad information — including issues in the official MySQL and MariaDB documentation — that I took time to dig deep into every step of the process. While reading this guide, you should never feel you're being told to run a command or change some code without an explanation that justifies the decision.
 
 # 0. Prerequisites
 
@@ -21,15 +21,15 @@ This section is largely based on the official documentation of [MySQL](https://d
 
 Let's establish some basic terminology. We will be using "asymmetric cryptography", in which every entity needs a key pair — a private key, and a public key. The private key is used to encrypt or sign messages, and the public key is used on the receiving end to decrypt messages and verify signatures. For SSL, when we generate public keys, they will be immediately turned into public key *certificates* which contain some additional information besides just the public key itself.
 
-Every entity will end up with a file containing the *private key*, and a file containing the *public key certificate*. From now on, I will simplify the terminology and use "key" to mean the private key, and "certificate" or "cert" to mean the public key certificate. Later we will see this simplified terminology used in both MySQL / MariaDB configuration, and in the PHP code for configuring the database connection.
-
-Before generating anything, we must pick an *algorithm*. Both official documentations use 2048-bit RSA. As far as RSA goes, 2048 bits is the absolute minimum nowadays. It might be a good idea to increase the key size to 3072, 4096, or even more bits for better resilience against progress in (non-quantum) computing performance, but that comes at the expense of spending more time establishing every connection. The world seems to be moving away from RSA and towards elliptic curves, which have much smaller keys and other benefits, so we might as well use the current best thing. Based on the recommendations from [Trail of Bits](https://blog.trailofbits.com/2019/07/08/fuck-rsa/) and [Soatok](https://soatok.blog/2022/05/19/guidance-for-choosing-an-elliptic-curve-signature-algorithm-in-2022/), I will use Ed25519.
+For every entity, we will end up with a file containing the *private key*, and a file containing the *public key certificate*. From now on, I will simplify the terminology and use "key" to mean the private key, and "certificate" or "cert" to mean the public key certificate. Later we will see this simplified terminology used in both MySQL / MariaDB configuration, and in the PHP code for configuring the database connection.
 
 ## Certificate Authority
 
 First, we roleplay as a "Certificate Authority" (CA), the first entity on our list. If you hate fun, you can take inspiration from modern "Free-to-play" games and simply pay a *real* Certificate Authority to skip this part.
 
-We will generate a "CA key" and a "CA certificate" (which, as a reminder, is what I'm calling the private key and public key certificate respectively) out of ~~magic~~ a bunch of math. The purpose of the CA is to *sign* other certificates. We will distribute the CA certificate to every computer that either hosts the database server or connects to it. When these *other certificates* are sent and received over an untrusted network, our trusty CA certificate will verify their signature. If the signature is valid, because we know we can trust the CA, we can also trust these *other certificates*. If the signature is not valid, it means the *other certificate* has been forged or otherwise corrupted, and it is impossible to establish secure and trusted communication to the database server.
+We will generate a "CA key" and a "CA certificate" (which, as a reminder, is what I'm calling the private key and public key certificate respectively) out of ~~magic~~ a bunch of math. The purpose of the CA is to *sign* other certificates. We will distribute the CA certificate to every computer that either hosts the database server or connects to it. When these *other certificates* are later sent and downloaded over an untrusted network, our trusty CA certificate will verify their signature. If the signature is valid, because we know we can trust the CA, we can also trust these *other certificates*. If the signature is not valid, it means the *other certificate* has been forged or otherwise corrupted, and it is impossible to establish secure and trusted communication to the database server.
+
+Before generating anything, we must decide which *algorithm* to use. Both official documentations use 2048-bit RSA. As far as RSA goes, 2048 bits is the absolute minimum nowadays. Increasing the key size to 3072, 4096, or even more bits, increases resilience against progress in (non-quantum) computing performance, while also increasing how long it takes to establish every connection. The world seems to be moving away from RSA and towards elliptic curves anyway, so we might as well try to use the current best thing, and hopefully not worry about it for a while. Based on the recommendations from [Trail of Bits](https://blog.trailofbits.com/2019/07/08/fuck-rsa/) and [Soatok](https://soatok.blog/2022/05/19/guidance-for-choosing-an-elliptic-curve-signature-algorithm-in-2022/), I will use Ed25519.
 
 It's terminal time. Navigate to a folder where you want your certificates.
 
@@ -47,9 +47,9 @@ Let's go through what this means:
 1. `openssl req -new` means we are creating a new "certificate signing request".
 2. `-x509` means that the "certificate signing request" will be immediately turned into a self-signed certificate in the X.509 format.
 3. `-nodes` ("no DES") disables encryption of the certificate. If encryption is enabled, you will be asked for a passphrase, and then must provide this passphrase whenever you want to use the certificate. Encrypting certificates provides more security at the expense of convenience, but I cannot find any evidence that either MySQL or MariaDB supports encrypted certificates, so we don't have a choice here.
-4. `-days 365000` sets the expiry time to roughly 1000 years, which is fairly optimistic considering how humanity is going. You can use shorter expiry times, but you need to think about renewal and this s\*\*t is already complicated enough. Shorter expiry times can help if your private key leaks and you never realize, but recommended expiry times are often in the realm of months or years, which is plenty of time for an attacker to cause harm. Moreover, if you do realize your private key leaked, you can simply regenerate all keys and certificates and swap them out easily — since you have full control over your PHP scripts.
+4. `-days 365000` sets the certificate expiry time to roughly 1000 years, which is fairly optimistic considering how humanity is going. You can use shorter expiry times, but you need to think about renewal and this s\*\*t is already complicated enough. It can be a useful feature in case your private key leaks and you never realize, however recommended expiry times are often in the realm of months or years which is plenty of time for an attacker to cause harm, and if you do realize that your private key leaked, you can simply regenerate all keys and certificates and easily swap them out since you have full control over your PHP scripts.
 5. `-subj ...` is the spicy stuff. It is a slash-delimited sequence of key-value pairs of various fields embedded in the certificate. Most are optional, but useful for documenting where the certificate came from. There are standards for these, but since you are the only one using these certificates, for the unimportant fields just type in whatever doesn't crash `openssl`.
-   - `C` is a two-letter country code. The lesser-known your country is, the more I recommend setting it.
+   - `C` is a two-letter country code. The smaller and less known your country is, the more I recommend setting it.
    - `O` is the organization name. Despite my lack of organization, I set it to my nickname.
    - `OU` is the organizational unit. I set it to `mysql` to describe where these certificates will be used.
    - `CN` is the common name, which is supposed to identify the certificate's origin. For the CA, it's not really important. For example, you can just set it to your username. I set it to the domain name of the server which stores the CA key and certificate, but if you are planning to do that, you must use a different domain name than the one used for the database server — we will come back to that later.
@@ -58,7 +58,7 @@ Let's go through what this means:
 6. `-key` is the file name of the private key.
 7. `-out` is the file name to create for the certificate.
 
-We end up with a private key `ca_key.pem` that we need to keep secret, and a public key certificate `ca_cert.pem` that needs to be copied to the database server and to every client that connects to the database server.
+We end up with a private key `ca_key.pem` that we need to keep secret, and a public key certificate `ca_cert.pem` that needs to be copied to the database server and to every client that wants to use SSL to connect to the database server.
 
 ## Server Certificates
 
@@ -75,20 +75,12 @@ Most of these arguments are the same as before. The differences are:
 1. `-newkey` is like `-new`, but it also generates a private key at the same time as the certificate signing request. Note that this time there is no `-x509`, so we do actually create a certificate signing request that we will sign later.
 2. `ed25519` uses the Ed25519 algorithm for the private key.
 3. `-subj ...` is largely the same, **but!**
-   - `CN` must be the hostname of the database server you use in your PHP script! If it doesn't match, the connection will fail with an error:
-     ```
-     Peer certificate CN=`...' did not match expected CN=`...'
-     ```
-     It must also be different from the `CN` field you used for the Certificate Authority, otherwise database servers with OpenSSL will reject the connection with this error:
-     ```
-     OpenSSL Error messages: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
-     ```
-     Inconveniently, MariaDB documentation does not mention this at all, and MySQL documentation does but too early — before you learn what any of this even means.
+   - `CN` must be the hostname of the database server you use in your PHP script! This will be checked, and if it does not match, the connection will fail with an error: ``Peer certificate CN=`...' did not match expected CN=`...'``. It must also be different from the `CN` field you used for the Certificate Authority, otherwise the connection is rejected by database servers with OpenSSL with this error: `OpenSSL Error messages: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed`. Inconveniently, MariaDB documentation does not mention this at all, and MySQL documentation does but too early — before you learn what any of this even means.
 4. `-keyout` is the file name to create for the private key.
 
 At this point, both official documentations say to run a command to "remove the passphrase" from the private key. If you remember from earlier, the `-nodes` argument — which both documentations use — already disables passphrase-based encryption, so there is no point removing something that doesn't exist.
 
-Let's turn the certificate signing request into an actual certificate by using our Certificate Authority to sign it:
+Now, we turn the certificate signing request into an actual certificate by using our Certificate Authority to sign it:
 ```bash
 openssl x509 -req -days 365000 -set_serial 1 -CA ca_cert.pem -CAkey ca_key.pem -in "server_req.pem" -out "server_cert.pem" -extfile /etc/ssl/openssl.cnf -extensions usr_cert
 ```
@@ -96,16 +88,14 @@ openssl x509 -req -days 365000 -set_serial 1 -CA ca_cert.pem -CAkey ca_key.pem -
 New thingies to learn!
 1. `openssl x509` begins a command related to X.509 certificates. You may be wondering — we already did a bunch of things with X.509 certificates, why have we not seen this command yet? Anyway,
 2. `-req` means we are turning a certificate request into a certificate. Very different from `req`.
-3. `-set_serial` specifies a serial number for the certificate. This number should be **unique for our CA**. This server certificate uses serial number `1`, the next certificate we make with the same CA will use serial number `2`, etc.
-4. `-CA` is a path to the CA certificate.
-5. `-CAkey` is a path to the CA key, and also the fourth f\*\*\*ing way to capitalize arguments in the `openssl` command.
+3. `-set_serial` specifies a serial number for the certificate. This number should be **unique for your CA**. This server certificate uses serial number `1`, the next certificate I make with the same CA will use serial number `2`, etc.
+4. `-CA` is the file name of the CA certificate.
+5. `-CAkey` is the file name of the CA (private) key, and also the fourth f\*\*\*ing way to capitalize arguments in the `openssl` command.
 6. `-in` is the file name of the certificate signing request.
-7. `-extfile` is a path to a file containing X.509 v3 extensions. We use the default OpenSSL configuration file.
+7. `-extfile` is the path to a file containing X.509 v3 extensions. We are using the default OpenSSL configuration file.
 8. `-extensions usr_cert` then uses a particular set of X.509 v3 extensions that the default configuration file intends to be used when a CA signs a certificate request.
 
-The last two arguments, `-extfile` and `-extensions`, are what's needed to generate a version 3 certificate. Omitting them would generate a version 1 certificate, which works fine if your database server and client use OpenSSL, but may not work with a different SSL library.
-
-At the time of writing, both official documentations only show how to generate version 1 certificates; [MariaDB documentation](https://mariadb.com/kb/en/certificate-creation-with-openssl/) does explain the problem with version 1 certificates, promises to update the documentation soon, and then links to an unresolved [2-year-old issue](https://jira.mariadb.org/browse/MDEV-25701) about updating the documentation.
+The last two arguments, `-extfile` and `-extensions`, are what's needed to generate a version 3 certificate. Omitting them would generate a version 1 certificate, which works fine if your database server and client use OpenSSL, but may not work with a different SSL library. At the time of writing, both official documentations only show how to generate version 1 certificates; [MariaDB documentation](https://mariadb.com/kb/en/certificate-creation-with-openssl/) does explain the problem with version 1 certificates, promises to update the documentation soon, and then links to an unresolved [2-year-old issue](https://jira.mariadb.org/browse/MDEV-25701) about updating the documentation.
 
 Finally, this command just removes the certificate signing request.
 ```bash
@@ -114,19 +104,17 @@ rm "server_req.pem"
 
 ## Client Certificates
 
-Client certificates are optional. We can not use them at all, use the same key and certificate everywhere, or generate a new key and certificate for each client (PHP application).
+Client certificates are optional. We can skip them entirely, use the same key and certificate everywhere, or generate a new key and certificate for each client (PHP application) that connects to the database server.
 
 The process for generating a client key and certificate is the same as for the server, we just need to change a few parts:
 1. Change file names, substituting `server_` for `client_` (for example).
 2. Increase the serial number to `2`.
-3. While you technically don't need to use a different `CN` than the one in the server certificate — as in, it will not throw errors — if someone steals your client key, they will be able to impersonate your database server by using the client key and certificate in place of the server key and certificate. By changing the `CN` to something different from your server hostname, attempting to impersonate your database server would fail, because as explained earlier, the clients check that the server certificate's `CN` field matches the server hostname.
+3. While technically it's unnecessary to use a different `CN` than the one used in the server certificate — as in, it will not throw errors — if someone steals your client key, they will be able to impersonate your database server by using the client key and certificate in place of the server key and certificate. By changing the `CN` to something different from your server hostname, attempting to impersonate your database server would fail, because as explained earlier, the clients check that the server certificate's `CN` field matches the server hostname.
 
 Here, have a convenient snippet with all three commands. Don't forget to change the `-subj`.
 ```bash
 openssl req -newkey ed25519 -nodes -subj "/C=US/O=organization/OU=organizational_unit/CN=client_name" -keyout "client_key.pem" -out "client_req.pem"
-
 openssl x509 -req -days 365000 -set_serial 2 -CA ca_cert.pem -CAkey ca_key.pem -in "client_req.pem" -out "client_cert.pem" -extfile /etc/ssl/openssl.cnf -extensions usr_cert
-
 rm "client_req.pem"
 ```
 
@@ -146,12 +134,12 @@ openssl x509 -text -noout -in client_cert.pem
 
 At this point, you should have files containing the key and certificate for the CA, server, and any number of clients you desire.
 ```
-ca_cert.pem
 ca_key.pem
-client_cert.pem
-client_key.pem
-server_cert.pem
+ca_cert.pem
 server_key.pem
+server_cert.pem
+client_key.pem
+client_cert.pem
 ```
 
 If you do, hooray! Make sure the files have the correct ownership and mode, pat yourself on the back, and get ready to drop into the next circle of hell.
@@ -184,21 +172,11 @@ ssl_key  = /certs/server_key.pem
 
 Restart the database server and check the logs.
 
-MySQL helpfully tells us when SSL is active:
-```
-[Server] Channel mysql_main configured to support TLS.
-```
+MySQL helpfully tells us when SSL is active: `[Server] Channel mysql_main configured to support TLS.`. It also warns us when the CA certificate is self-signed: `[Server] CA certificate ca.pem is self signed.`. Wait, `ca.pem` is **not** what we named our CA certificate file! It turns out that MySQL generates its own self-signed certificates if we don't configure your own. MySQL also silently ignores files in its configuration folders if it doesn't like them, for example files whose extension is not `.cnf`. If you see log files referring to `ca.pem` instead of the path to `ca_cert.pem` you configured, it means your configuration was not read.
 
-MySQL also warns us when the CA certificate is self-signed:
-```
-[Server] CA certificate ca.pem is self signed.
-```
+On the other hand, MariaDB seems to only log errors. We will see some if, for example, we are using Docker Compose, and we forgot that `docker compose restart` does not mount newly specified volumes, so the database server could not find any of the key and certificate files in `/certs`. Just a hypothetical.
 
-Wait, `ca.pem` is not what we named our CA certificate file! It turns out that MySQL generates its own self-signed certificates if we don't configure your own. MySQL also silently ignores files in its configuration folders if it doesn't like them, for example files whose extension is not `.cnf`. If you see log files referring to `ca.pem` instead of the path to `ca_cert.pem` you configured, it means your configuration was not read.
-
-On the other hand, MariaDB seems to only log errors when it comes to SSL configuration. We will see some if, for example, we are using Docker Compose, and we forgot that `docker compose restart` does not mount newly specified volumes, so the database server could not find any of the key and certificate files in `/certs`. Just a hypothetical.
-
-At this point, it's *possible* to connect with SSL, but it's not *required*. The good news is that's exactly what we (I) wanted, because SSL requirements can be set individually per database user, so we can set up a test user to make sure this all works. Or we could appropriate an existing user used by a service nobody will notice temporarily disappearing because something was misconfigured. Again, just a hypothetical.
+At this point, it is *possible* to connect with SSL, but not *required*. The good news is that's exactly what we (I) wanted, because SSL requirements can be set individually per database user. We can set up a test user to make sure this all works, or just use an existing user used by a service nobody will notice temporarily disappearing because something was misconfigured. Again, just a hypothetical.
 
 Before we can start requiring SSL, we need to update places that connect to our database server.
 
@@ -206,9 +184,9 @@ Before we can start requiring SSL, we need to update places that connect to our
 
 Alright, this is where a lot of the online advice gets really bad. So, here's the deal.
 
-We know that a client downloads the server certificate and checks whether it was signed by a trusted CA. How does the client know a CA is trusted? Operating systems come pre-installed with CA certificates that are trusted by the vendor of the operating system. These CAs tend to be commercial, so if you misunderstood my earlier comment to be an encouragement and splurged money on certificates from a commercial CA, it might just work out-of-the-box. However, I have no money (unless you give me some, [wink wink nudge nudge](https://ko-fi.com/chylex)), so I haven't actually tested the hypothesis that things will be easier for you if you pay for a certificate.
+We know that a client downloads the server certificate and checks whether it was signed by a trusted CA. How does the client know a CA is trusted? Operating systems come pre-installed with CA certificates that are trusted by the vendor of the operating system. These CAs tend to be commercial, so if you misunderstood my earlier comment to be an encouragement and splurged money on certificates from a commercial CA, it might just work out-of-the-box. However, because I have no money (unless you give me some, [hint hint nudge nudge](https://ko-fi.com/chylex)), I have not actually tested the hypothesis that things will be easier for you if you pay for a certificate, so you're on your own there.
 
-Any CA we made up in the course of this tutorial will certainly not be trusted by any operating system vendor. You could use a ~~magical incantation~~ command to install our self-signed CA certificate onto the entire server. Do not. Instead, both MySQLi and PDO let us set a path to the CA certificate file before the connection is created. The provided certificate will become trusted in the context of our database connection, and will be used to verify the signature of the server certificate.
+Any CA we made up in the course of this tutorial will certainly not be trusted by any operating system vendor. You could use a ~~magical incantation~~ command that installs our self-signed CA certificate onto the entire server. Do not. Instead, both MySQLi and PDO let us set a path to the CA certificate file before the connection is created. The provided certificate will become trusted in the context of our database connection, and will be used to verify the signature of the server certificate.
 
 Let's look at some examples. We will assume a folder structure with an `app` folder that is the root of your PHP application, and a `secrets` folder next to it where we can safely store secrets without any way for visitors to access them:
 - app/
@@ -218,7 +196,7 @@ Let's look at some examples. We will assume a folder structure with an `app` fol
 
 While there is no harm in putting your CA certificate somewhere your visitors could access it, there is no reason to expose them either. Besides, we might want to put *actual secrets* there later.
 
-All examples use paths relative to the PHP script file. If we have full control over the PHP server, we can place secrets into the `/certs` folder like in the example configuration for the database server. In my case, I self-host my database server, but some of my websites are on managed web hosting where this isn't possible.
+All examples use paths relative to the PHP script file. If we have full control over the PHP server, we can place secrets into the `/certs` folder like in the example configuration for the database server. In my case, I self-host my database server, but some of my websites are managed by web hosting companies where this is not possible.
 
 ### MySQLi
 
@@ -236,12 +214,12 @@ $db->real_connect(DB_HOSTNAME, DB_USERNAME, DB_PASSWORD, DB_DATABASE);
 
 The `mysqli_init` function, unlike the `mysqli` constructor, lets us configure the connection before it is established.
 
-The `ssl_set` function has a bunch of optional parameters. If we just want to get SSL working and be done with it, we only need to set the third one to the path to the CA certificate file.
+The `ssl_set` function has a bunch of optional parameters. If we just want to get SSL working and be done with it, we only need to set the third one (`$ca_certificate`) to the path to the CA certificate file.
 
 The `real_connect` function establishes a connection to the server. There is an optional [flags argument](https://www.php.net/manual/en/mysqli.real-connect.php) which has an interesting option. This is what the documentation says:
 - `MYSQLI_CLIENT_SSL`: Use SSL (encryption)
 
-It looks like you need `MYSQLI_CLIENT_SSL`, but the documentation page on [mysqli constants](https://www.php.net/manual/en/mysqli.constants.php) expands the description with:
+It looks like you need `MYSQLI_CLIENT_SSL`, but a *different* documentation page on [mysqli constants](https://www.php.net/manual/en/mysqli.constants.php) expands the description with:
 - `MYSQL_CLIENT_SSL`: Use SSL (encrypted protocol). This option should not be set by application programs; it is set internally in the MySQL client library
 
 The end goal is to configure the *database server* to require SSL for your `DB_USERNAME`, so we will be sure SSL is active even when we don't specify the `MYSQLI_CLIENT_SSL` flag as half of the documentation suggests.
@@ -297,11 +275,9 @@ foreach ($db->query('SHOW STATUS LIKE \'Ssl_%\'', PDO::FETCH_ASSOC)->fetchAll()
 
 ## Use Client Key & Certificate
 
-For most people, just getting SSL to work at all is enough. However, if we wanted to strengthen security even more, we could use a client key and certificate.
+For most people, just getting SSL to work at all is enough. However, if we wanted to strengthen security even more, we could use a client key and certificate. Similarly to how the client can verify the server's identity using the server certificate, the server is able to verify the client's identity using the client certificate. Assuming our client key and certificate has been generated, we will need to put the `client_key.pem` and `client_cert.pem` files somewhere our PHP script can access them — for example, into the `secrets` folder, next to the `ca_cert.pem` file. The rest is easy — we just add a few additional parameters or options in the functions we are already calling.
 
-Similarly to how the client can verify the server's identity using the server certificate, the server is able to verify the client's identity using the client certificate. Assuming our client key and certificate has been generated, we will need to put the `client_key.pem` and `client_cert.pem` files somewhere our PHP script can access them — for example, into the `secrets` folder, next to the `ca_cert.pem` file. The rest is easy — we just add a few additional parameters or options in the functions we are already calling.
-
-### MySQLi
+## MySQLi
 
 **Before:**
 ```php
@@ -357,9 +333,9 @@ Finally, we could not only require a specific "subject" for the client certifica
 ALTER USER 'my_user'@'%' REQUIRE SUBJECT '/C=US/O=organization/OU=organizational_unit/CN=client_name' AND ISSUER '/C=US/O=organization/OU=organizational_unit/CN=common_name'
 ```
 
-Actually, I lied — there's even more possibilities. We could, for example, require the client to use a specific cipher. [MariaDB documentation](https://mariadb.com/kb/en/securing-connections-for-client-and-server/#requiring-tls-for-specific-user-accounts-from-specific-hosts) covers this. However, the defaults — especially with TLSv1.3 — should be fine.
+Actually, I lied — there's even more possibilities. We could, for example, require the client to use a specific cipher. The [MariaDB documentation](https://mariadb.com/kb/en/securing-connections-for-client-and-server/#requiring-tls-for-specific-user-accounts-from-specific-hosts) covers this. However, the defaults — especially with TLSv1.3 — should be fine.
 
-## Do Not Disable Server Certificate Verification
+## Do not Disable Server Certificate Verification
 
 Using the `MYSQLI_CLIENT_SSL_DONT_VERIFY_SERVER_CERT` flag or setting the `PDO::MYSQL_ATTR_SSL_VERIFY_SERVER_CERT` flag to `false` is often recommended by online tutorials or stackoverflow answers if you "run into problems", as a way to "fix those problems".
 
@@ -373,7 +349,7 @@ If anyone has a legitimate reason to disable server certificate verification, do
 
 When we enable SSL, we lose some performance because the client and server have to do some additional work. Out of curiosity, I measured how long it takes to establish a connection to the database server with various compression algorithms — including RSA with various key sizes, in case you were curious — or cannot use Ed25519 for some reason, and are stuck with RSA. My web server is on a shared web hosting, and my database server is self-hosted. I took 200 samples for every configuration, and used [Statistics Kingdom](https://www.statskingdom.com) to make a box plot:
 
-![Box plot showing the performance of No SSL, Ed25519, and RSA with 2048-bit, 3072-bit, and 4096-bit key sizes.]({{ '/assets/img/ultimate-guide-to-mysql-ssl/performance.png' | relative_url }})
+![Box plot showing the performance of No SSL, Ed25519, and RSA with 2048-bit, 3072-bit, and 4096-bit key sizes.]({{ '/assets/img/mysql-ssl-guide/performance.png' | relative_url }})
 
 The same plot in table form, ordered by median time:
 
@@ -393,4 +369,4 @@ Note that I did not measure the performance impact of encrypting and decrypting
 
 # 5. Wow, Security
 
-I hope this has been helpful. If you noticed any problems with the post, don't hesitate to post a comment. If this post saved you some frustration (although probably not time, considering its length), you can share it and/or support me on [Ko-fi](https://ko-fi.com/chylex).
+I hope this has been helpful. If you noticed any problems with the post, don't hesitate to post a comment. If this post saved you some frustration (probably not time considering its length), you can share it and/or support me on [Ko-fi](https://ko-fi.com/chylex).

assets/css/style.scss

@@ -62,10 +62,6 @@
     margin-top: 0.2rem;
   }
   
-  pre code {
-    white-space: pre-wrap;
-  }
-  
   .page-breadcrumbs {
     margin: -0.75rem 0 -0.25rem;
     font-size: 1.05rem;