Ok, this one was just so frustrating I cannot keep it to myself. It costs so much time and nerves to realize that you were pointed in all but the right direction after all.
So here it goes. I have added a user to the MySQL database, I require the SSL connection (actually X509) and it all works on my development system (MacOSX 10.4). So I naively didn’t expect any problems on the test server running Ubuntu. I was wrong. And my mistake apparently has a name… But not all.
So what I see is that when I try to connect to the DB using either the Python/MySQLdb or giving the command line is the same:
_mysql_exceptions.OperationalError: (1045, "Access denied for user 'xxx'@'localhost' (using password: YES)")
or
ERROR 1045 (28000): Access denied for user 'xxx'@'localhost' (using password: YES)
Great. Now what?
I tried every single thing that made sense to me:
- Re-created the user, updated the privileges and even added
FLUSH PRIVILEGES
at the end (never needed it before). - Re-generated the certificate files
- Different DB
Ok, after all it boiled down to the following messages in the dmesg output:
[877463.513737] audit(1263600950.291:21): type=1503 operation="inode_permission" requested_mask="r::" denied_mask="r::" name="/xxx/xxx/certificates/server-cert.pem" pid=11840 profile="/usr/sbin/mysqld" namespace="default"
Bingo! MySQL cannot read the f…g certificate? Why-y-y-y-y? Apparently because the
apparmor
(now I know the enemy’s name!) does not allow it. And this is all because I have installed certificates to the ‘non-standard’ folder. Well, adding the following line to the
/etc/apparmor.d/usr.sbin.mysqld
/xxx/xxx/certificates/*.pem r,
and then issuing the following commands:
#apparmor_parser -r /etc/apparmor.d/usr.sbin.mysqld #sudo /etc/init.d/mysql restart
finally put everything on their places.
2 hours, a lot of frustration, but it seem to work now. I hope you spend less time finding this in Google :).
Have a nice weekend!