Mysql – Does MySQL or MariaDB have a master option to strictly require TLS for ALL connections, no matter what

mariadbMySQLSecurityssl

When setting up new MySQL or MariaDB servers, I am much more concerned about security than performance. The MySQL and MariaDB documentation use the words "allow" and "permit" around all the SSL options, where I would much rather see "require".

I am looking for something like, "mysqld –ssl-mode=REQUIRE" but that apparently doesn't work [anymore?] because the logs say that's a bad option. I am not looking to do this per-user, I'm looking to do it for the whole system, no matter what.

I should point out that all of my certificates are working fine, and I've verified that all of that works. It's just that now, I would like to REQUIRE it be used, always, by everyone, period, strictly, no exceptions, no, not even that one, yes really. Remote? Encrypt. Localhost? Encrypt. Root? Encrypt. Somebody else? Encrypt. In short: connected to anything at all for any reason? Encrypt.

Does anybody know of a master switch to require this all the time, period?

Again, I am not looking for per-user options– that's exactly what I'm hoping to avoid. This is for an embedded device that may be in service for an extended period of time, and the less branching logic, the better. "Always" tends to have fewer edge cases.

Thanks!

Best Answer

As of MySQL 5.7, it does not seem to be possible to force SSL from the server side, without specifying it for each user.

https://dev.mysql.com/doc/refman/5.7/en/encrypted-connection-options.html#option_general_ssl-mode

--ssl-mode=mode

This option is available only for client programs, not the server. It specifies the security state of the connection to the server. These option values are permitted:

BOO. You can only force SSL from the client side. Opposite of what you want to do. This is likely why you're getting "bad option" trying to use it as a server setting.

Also:

To require use of encrypted connections by a MySQL account, use CREATE USER to create the account with a REQUIRE SSL clause, or use ALTER USER for an existing account to add a REQUIRE SSL clause. Connection attempts by clients that use the account will be rejected unless MySQL supports encrypted connections and an encrypted connection can be established.

Enforcing users to Require SSL by routinely checking the users table for REQUIRE SSL seems hacky, but it might be your best option.

Related Solutions

SQL Server Report Manager 404 using HTTPS

The problem has to do with the certifcate being used with SSRS. If your certificate is created with hostname.whatever.com, you can only access the Report URLs through that path, https: //hostname.whatever.com/Reports. If you were to try https:// 10.xxx.xxx.xxx/Reports (where the IP is the one on the server) you will receive the 404 errors.

So the fix for my situation:
I found the friendly name used to generate the certifcate on the server was dorked up. I am in the process of getting that fixed to be the correct fully qualifed DNS name of the server in use. I found this out by installing SQL Server Report Server on a server that had the certificate created with the correct name of the server being used.

Once I have that certificate corrected and verify will simply mark this as the correct answer.

EDIT Well another problem came up in trying to change the certificate. The admins of the server removed the certificate before I could properly remove it from RSCM. So now it will not bind to the new certificate because it already sees one binded. There is really no clean, easy way of fixing this since you don't have access to IIS (SSRS uses HTTP.sys). So following this KB, you have to go into NETSH to remove the binding(s). Which you will note in that KB article the link to NETSH does not provide much info, so use this one. I had to use the two following commands to delete the bindings on Window Server 2008 R2: WARNING: I am on a single, standalone server. If you are in a server farm or have multiple instances of SSRS running, be very careful with which SSL binding you delete.


This is after getting to the "netsh http>" prompt:
delete sslcert ipport=0.0.0.0.:443
delete sslcert ipport=[::]:443

I did that and then went into RSCM and selected the new certificate that was installed on teh server. That is not the end though, for some reason it kept removing the binding and showing "unknown" in the link. I stopped SSRS and then opened up the rsreportserver.config file and found the old ("bad") binding still was showing in the config file. I removed that went back into RSCM and started the service and it seemed to fix it.

MS SQL Server – Using SSL Connection Over the Web

According to Books Online, the certificate used for encrypting connections must meet the following requirements:

The certificate must be issued for Server Authentication
The name (common name or CN) on the certificate must match the full-qualified domain name used by clients to connect.

If those two conditions are not met, the certificate will not show in the drop-down listing. Additionally, the service account for SQL Server must have read access to the private key of the certificate. Without that right, you will be able to select the certificate, but the service will not start.

Since this is a test system you intend to use as proof-of-concept, a self-signed certificate should be adequate. I am not sure what language you are using for your client application, but this link provides options available for connection strings in .Net. You should review at least the following two options.

Encrypt - Tells the client application to force encryption.
TrustServerCertificate - Tells the client application to skip validating the certificate chain. This is important with a self-signed certificate as the chain likely will not be trusted.

Best Answer

Related Solutions

SQL Server Report Manager 404 using HTTPS

MS SQL Server – Using SSL Connection Over the Web

Related Question