MySQL报错写私钥权限不够导致连接失败，远程帮忙修复方案分享

开始）

前段时间，我帮一个朋友处理了一个他服务器上MySQL数据库连接不上的问题，他是在自己的云服务器上部署的应用，本来运行得好好的，突然有一天应用就报错了，完全连不上数据库，因为他自己不太熟悉服务器运维,所以就远程联系我帮忙看看。

我首先让他把应用报错的完整日志发给我，在错误信息里，我看到了类似“Can't connect to MySQL server on 'xxx.xxx.xxx.xxx'”这样的提示，但往下翻，更关键的一条错误信息是“SSL connection error: error:8000000D:system library::Permission denied”，后面还跟着一个文件路径，指向了服务器上的一个文件，文件名像是“xxx-key.pem”。

看到这个错误，我心里大概有数了，这个错误通常和SSL加密连接有关，MySQL为了安全，支持使用SSL证书对客户端和服务器之间的通信进行加密，那些“.pem”文件就是SSL证书和密钥文件，错误信息里的“Permission denied”（权限不足）非常关键，它告诉我，不是证书文件不存在或者配置错误，而是MySQL服务进程没有被允许去“读”这个密钥文件。

为了确认问题，我让朋友登录到他的服务器上，他使用的是Linux系统，我让他检查了一下MySQL的配置文件，MySQL的主配置文件通常是“/etc/my.cnf”或者“/etc/mysql/my.cnf”，我让他找到文件中关于SSL设置的部分,一般会有类似这样的几行：

[mysqld]
ssl-ca=/path/to/ca.pem
ssl-cert=/path/to/server-cert.pem
ssl-key=/path/to/server-key.pem

朋友确认了，配置里确实有这些行，而且文件路径是正确的，这说明SSL配置本身是开启的,方向没错。

就是排查权限问题的核心步骤了，我让他使用“ls -l”命令，详细列出那个报错信息里提到的“server-key.pem”文件的权限信息，命令执行后,返回的信息大概是这样的：

-rw------- 1 root root 1675 May 10 10:00 /path/to/server-key.pem

这里就需要解释一下“-rw-------”这串字符了，在Linux中，这代表了文件的权限，第一个字符“-”表示这是一个普通文件，后面的九位字符每三位一组，分别代表文件所有者（owner）、所属组（group）和其他用户（others）的权限。“r”表示读权限，“w”表示写权限，“x”表示执行权限。

-rw-------”的意思就是：文件所有者（root）有读和写的权限（rw-），而所属组（root组）和其他任何用户都没有任何权限（---）。

问题就出在这里！MySQL服务在运行时，并不是直接用“root”这个超级用户身份运行的，出于安全考虑，通常会创建一个专门的、权限更低的系统用户来运行MySQL，比如叫“mysql”用户，这个私钥文件“server-key.pem”只有root用户能读，而实际需要读取它的mysql用户没有任何权限，所以当MySQL服务启动，尝试加载这个密钥文件来建立SSL连接时，就被系统拒绝了，于是就报出了“Permission denied”的错误。

找到了问题的根因，解决方法就非常明确了：我们需要修改这个私钥文件的权限，让运行MySQL的“mysql”用户能够读取它。

我给了朋友两个解决方案,让他选择一个操作：

更改文件的所有者

这个方案是把私钥文件的所有者直接从root改为mysql用户，这样，由于mysql用户成了文件的主人，它就自然拥有了读取的权限,我让他执行的命令是：

sudo chown mysql:mysql /path/to/server-key.pem

这个命令中，“chown”是修改文件所有者的命令，“mysql:mysql”表示将所有者改为mysql用户，所属组也改为mysql组。“/path/to/server-key.pem”需要替换成实际的密钥文件路径。

更改文件的权限，让其他用户也可读

如果不想改变文件的所有者，也可以放宽文件的读取权限,我让他执行的命令是：

sudo chmod 644 /path/to/server-key.pem

“chmod”是修改文件权限的命令。“644”是一组数字代码，它对应的权限是：文件所有者有读写权限（6），文件所属组和其他用户只有读权限（4），这样，mysql用户即使不是文件所有者，也能以“其他用户”的身份读取这个文件了。

关于安全性的提醒

我特意跟朋友强调了一下，私钥文件是一个非常敏感的文件，就像一把钥匙，方案二（chmod 644）虽然简单，但意味着任何能登录到服务器上的用户（只要他们有权限访问这个目录）都可能读到这个文件，这会带来一定的安全风险，相比之下，方案一（chown mysql:mysql）并配合保持文件权限为600（即只有所有者有读写权限）是更安全的选择,我建议他采用方案一。

朋友选择了方案一，他执行了“sudo chown mysql:mysql /path/to/server-key.pem”命令后，为了确保万无一失，我又让他检查了一下现在文件的权限,确认所有者已经变成了mysql。

最后一步，就是重启MySQL服务，让新的权限设置生效，我让他执行了重启命令（根据系统不同，可能是sudo systemctl restart mysql 或 sudo service mysql restart）。

服务重启成功后，他立刻让他的应用程序再次尝试连接数据库，这次，连接成功了！应用恢复正常。

通过这次远程排障，我们总结出的核心经验就是：当MySQL配置了SSL连接后，一定要确保MySQL进程运行时所使用的系统用户（通常是mysql）对SSL证书文件（尤其是私钥文件server-key.pem）拥有正确的读取权限，很多时候，配置文件写对了，但权限没给对，就会导致这种“Permission denied”的错误，这是一个非常典型的、容易被忽略的细节。 结束）