多种不同的 MySQL 的 SSL 配置 已翻译 100%

在这篇博客的帖子里，我将会描述不同的使用MySQL数据库的SSL配置方法。

SSL给了你什么?

你可以通过互联网使用 MySQL 复制特性（replication） 或者通过互联网连接到MySQL。

还有可能是你通过企业网去连接，这样会有很多人访问。如果你使用一个自带设备（BYOD）网络，这就更是一个问题了。

SSL在这里通过加密网络防止有针对性的监听。在与正确的服务器进行交互时，可以有效应对中间人攻击（man-in-the-middle attacks）。

你还可以使用SSL客户端证书，让它同密码一起作为身份识别的二要素。

SSL不是唯一的选择， 你可以使用SSH和许多MySQL GUI客户端，类似MySQL Workbench提供的那个产品。 但是SSH的python脚本，或者mysqldump，不是那么易用。

需要注意的事情：

使用SSL在绝大多数情况下要比不使用SSL要好，所以没有太多可能出现问题的地方。

但是以下几点需要注意：

对安全性的错误估计

你认为你在SSL的保护之下，但是你可能忘记设置一些选项从而导致程序可以接受非SSL的连接，所以要确保设置必须使用SSL作为连接方式。可以使用Wireshark或者其它类似的工具来检测你的流量是否都真的被加密处理。

没有及时更新证书

你应该通过一些方法在证书即将过期的时候通知自己。可以是nagios检查，可以是日历里面的小贴士，可以来自于证书签发机构的email。如果证书过期，将会导致你的客户端无法正常获得响应。

性能

如果性能很重要，就应该做基准测试，来看看没有SSL的情况下有什么影响。在 OpenSSL 和 YaSSL 下尝试不同的密码，并看哪个的执行效果最佳。

使用流量监测的工具

如果你在使用像 VividCortex，pt-query-digest 基于 pcap 的工具，那么你应该确保在部署完SSL后，这些工具还能用，可以提供密钥来实现。然后使用一个非 Diffie-Hellman (DH) 的密码，或者使用其他的源，如 performance_schema、slow query log，这还要看你的应用程序支持哪种，也可能会包含一些负载均衡的设置。

MySQL 中的 SSL 和浏览器中的 SSL 有什么不同

浏览器默认有一个 CA 的信任列表，但 MySQL 默认是没有的。这就是他们最大的不同。MySQL 和OpenVPN 使用SSL非常相似。

MySQL server 和 Web server 都开启了 SSL，同时也都需要有客户端证书，这是他们相同的地方。

有一些细微的协议支持差别，比如：MySQL 只支持 TLS v1.0，默认不支持主机名验证，所以你的证书可能是给db1.example.com的，也可能是给db2.example的，浏览器则可能会用OCSP、CRL's 或 CRLsets 来验证证书是否有效。 MySQL 5.6以后就只支持CRL验证。

配置 1: Server/Client 的内部 CA

最基本的安装和我创建 mysslgen 的位置。

首先在服务器上创建一个PKCS#1格式的密钥，若PKCS#8不行。然后创建一个可以用CA部署的CSR(Certificate Signing Request证书签名请求) 。最后结果是一个CA证书服务器和一个服务器的密钥。笔者习惯用PEM格式的证书

服务器配置：

• SSL证书服务器和密钥 (ssl-certandssl-key)

• SSL CA 证书 (ssl-ca)

客户端配置:

• SSL CA 证书(ssl-ca)

要求账户用SSL验证，那你的GRANT语句应该用REQUIRE SSL选项。

配置 2: Server/Client 的内部 CA 和 客户端证书

首先得在服务器上开启SSL，然后给客户端创建证书。

然后在客户端指定客户端证书和密钥 ssl-cert和ssl-key.

现在必须要用 REQUIRE X509来要求一个有效的证书。如果这个CA不只用在MySQL server上，那就不起作用了，因为其他人也有可能拿到有效的证书， 

可以用 REQUIRE SUBJECT '/CN=myclient.example.com'来限制证书的使用。

在此设置证书是你的CA给颁发的，你颁发的证书你就能有很多可控的，结果就是你颁发的证书都是被信任的。

配置 3: Server/Client 与公共 CA

方案 3与方案 2相似。但公共的CA会指定多个的证书，同样也会吊销这些证书。

你应该了解 --ssl-verify-server-cert ，以确保服务器有一个带主机名的证书。否则，有人可能会用一个不带主机名的有效证书来发起中间人攻击（Man-in-the-MiddleAttack，简称“MITM攻击”）。

也应该使用 REQUIRE X509 字段，要求每个用户 SUBJECT 、ISSUER（可选）字段。

配置 4: Server/Client 和多个公共 CA's

这个方案用起来显得轻而易举。

可以使用证书包 （一个文件多个证书），并用 ssl ca 命令指定此文件。

在Ubuntu系统上，这个证书由 /etc/ssl/certs/ca-certificates.crt 下的 ca-certificates 包提供

其他选项，用“指定assl-capath”来代替“使用ssl-ca”，这样就可以设置到/etc/ssl/certs里。如果想用CA的默认目录，那就得运行OpenSSL 中的c_rehash 程序来生成正确的符号连接（只在OpenSSL下可用）。

配置 5: Replication（复制）

设置 CHANGE MASTER TO 命令中MASTER_SSL_* 就可实现。

如果开启了主机名验证，就确保用了 MASTER_SSL_VERIFY_SERVER_CERT。

只有这样才能真正确保 replication 用户的SSL连接是要求的SSL连接。如果SSL允许了，SHOW SLAVE STATUS就会显示输出,而不是不可用。

每台服务器一个CA还是集中式CA?

可以每服务器用一个CA然后指定一个客户端证书，但是每个服务器的客户端都需要不同的证书来连接，也就是说你会发放很多CA证书。

所以你可能就会想要使用一个CA，而不是每个服务器一个CA。

出错了怎么办？

如果其中一个私有密钥（客户端，服务器或CA）损坏，有以下几种办法处理：

1. 什么也不做，只要等到证书过期。这只适用于短暂的证书（如证书有效期是7天）。这样做容易让你受到攻击，你也可能会有其他缓解风险的方法。问题是，每7天就得重启MySQL，而且还需要一些自动分配证书的机制。

2. 重新创建所有证书和密钥(包括 CA)。这只适用于CA、服务器和用户数量较少的情况。

3. 用CRL（Certificate Revocation list证书吊销列表）。 这样做只在你的证书有正确序列号的情况下管用。此外，你要是有多个CA的话，就必须每个CA都捆绑CRL，并在c_rehash创建的符号连接的目录中指定 ssl-crl，指定ssl-crl路径(仅OpenSSL)。如果使用CRL，那MySQL 的版本要是5.6或更高，然后更新CRL，也更新所有客户端。

注意: 如果密钥泄露了，就必须重新创建私有密钥，仅用以前的CSR（证书签名请求）是不够的。