When you connect to MySQL through an SSL connection why do you pass the server side certificates as the parameters? I would have thought that (like with HTTPS) you would have a client side key and then do all the SSL handshakey stuff from there. But when you connect to MySQL with SSL you use:
mysql --ssl-ca=ca-cert.pem --ssl-cert=client-cert.pem --ssl-key=client-key.pem
But the client key is coming from the server but I would have thought it came from the client?
It then leads onto the question about REQUIRE ISSUER (for example). Surely you only have a choice of using the same certificate the server issues so why would you ever need that parameter?
"If the client presents a certificate that is valid but has a different issuer"
How would the client ever present a certificate that was different?
Maybe I'm missing something obvious so apologies if this is a stupid question.
The key here is that the client certificates must be manually copied to the client and used in the connection process. I hope that helps anyone else who didn't find this!
Related
I work in an organization that is performing the config review of their RDS MySQL Instance.
The review requires me to check if the access to the database is granted only after a secure authentication.
Is there a way to check if this is violated in any way?
Thank You
Edit: Let us ignore the "secure" part... There must be authentication using the credentials always and for every user
Depending how "Secure authentication" defined.
Look at SELECT CURRENT_USER() and examine tables for anonymous users.
Is TLS based authentication required? If so examine that in the connection \s from mysql client. Attempt to connection without the TLS, or without the client cert, or with a different client certificate as tests of this.
I'd like to connect to a MySQL server (AWS RDS, if you must know) via SSL. I'm familiar with the basic mechanics involved.
All the methods I've seen so far involve running a SQL query to determine that the current connection uses SSL.
My concern is that this is a "chicken and egg" problem: I would need to send my credentials to the server potentially in plain text, so I can run a query on the server to determine that it was not plain text.
Is there a way to run the SHOW STATUS LIKE 'Ssl_cipher'; query without first authenticating?
This seems like a pretty basic requirement (I'd like to know that my password will be encrypted BEFORE sending it over the wire) but it seems difficult to find the required information.
I've read the following resources:
https://kb.berkeley.edu/page.php?id=23112
http://dev.mysql.com/doc/refman/5.1/en/ssl-options.html
http://dev.mysql.com/doc/refman/5.0/en/creating-ssl-certs.html
MySQL native authentication was never sending password over network without regard of SSL usage (it always sends result of function of password and salt returned from Server instead).
In recent versions it may be beneficial to send clear text password - but that may happen only if you explicitly provide option (on client) --enable-cleartext-plugin (or similar).
I am not able to connect to my remote server using Toad and get a Bad Handshake error.
Now I know that it is because the ssh public key has changed on the server but I cannot find where this is configured in Toad and how I can delete the key.
Would anybody know?
1) If you can connect to the server administrator's cpanel, add your ip to the mysql remote list, under mysql remote. Keep in mind, if you don't have a static ip this can suddenly stop working when your isp changes your ip
2) Check and make sure you have the correct address for the mysql server. In cpanel this is usually on the left hand side. Mine was listed as box999.bluehost.com (or something along those lines)
3) Make sure your anti-virus isn't blocking the connection.
4) Make sure your sql client has mysql libraries enabled.
I have successfully setup my MySQL server to support SSL connections I'm just wondering if I need to copy client certs to each other server I want to connect to it OR if I can get away with just specifying:
[client]
ssl-cipher = DHE-RSA-AES256-SHA:AES128-SHA
All I need to do is encrypt the traffic between servers (sitting in EC2) and the MySQL server elsewhere, so I don't think I need to send certs out left, right and centre... Or am I wrong?
If I can get away with doing this, what are the implications of not going the whole hog and specifying the client certs too? Is there any reasonable real-world risk to NOT specifying a full set of client certs to the mysql client program?
It appears that specification of JUST the ssl-cipher option is enough to secure the connection between a client and an SSL enabled MySQL Server (If anyone else out there knows any different please let me know).
Tests using TCPdump to monitor traffic show clear text commands being sent as expected when a user not requiring SSL connects to the server, but once the server is setup to accept SSL connections, if you connect with a user that requires SSL specifiying only ssl-cipher these plain text commands are encrypted within the packets i.e. they can't be seen.
I've got a trio of Windows servers (data1, data2 and datawitness) that aren't part of any domain and don't use AD. I'm trying to set up mirroring based on the instructions at http://alan328.com/SQL2005_Database_Mirroring_Tutorial.aspx. I've had success right up until the final set of instructions where I tell data1 to use datawitness as the witness server. That step fails with the following message:
alter database MyDatabase set witness = 'TCP://datawitness.somedomain.com:7024'
The ALTER DATABASE command could not be sent to the remote server instance 'TCP://datawitness.somedomain.com:7024'. The database mirroring configuration was not changed. Verify that the server is connected, and try again.
I've tested both port 7024 as well as 1433 using telnet and both servers can indeed connect with each other. I'm also able to add a connection to the witness server from SQL Server Manager on the primary server. I've used the Configuration Manager on both servers to enabled Named Pipes and verify that IP traffic is enabled and using port 1433 by default.
What else could it be? Do I need any additional ports open for this to work? (The firewall rules are very restrictive, but I know traffic on the previously mentioned ports is explicitly allowed)
Caveats that are worth mentioning here:
Each server is in a different network segment
The servers don't use AD and aren't part of a domain
There is no DNS server configured for these servers, so I'm using the HOSTS file to map domain names to IP addresses (verified using telnet, ping, etc).
The firewall rules are very restrictive and I don't have direct access to tweak them, though I can call in a change if needed
Data1 and Data2 are using SQL Server 2008, Datawitness is using SQL Express 2005. All of them use the default instance (i.e. none of them are named instances)
After combing through blogs and KB articles and forum posts and reinstalling and reconfiguring and rebooting and profiling, etc, etc, etc, I finally found the key to the puzzle - an entry in the event log on the witness server reported this error:
Database mirroring connection error 2 'DNS lookup failed with error: '11001(No such host is known.)'.' for 'TCP://ABC-WEB01:7024'.
I had used a hosts file to map mock domain names for all three servers in the form of datax.mydomain.com. However, it is now apparent that the witness was trying to comunicate back using the name of the primary server, which I did not have a hosts entry for. Simply adding another entry for ABC-WEB01 pointing to the primary web server did the trick. No errors and the mirroring is finally complete.
Hope this saves someone else a billion hours.
I'd like to add one more sub answer to this specific question, as my comment on Chris' answer shows, my mirror was showing up as disconnected (to the witness) Apperently you need to reboot (or in my case i just restarded the service) the witness server.
As soon as i did this the mirror showed the Witness connection as Connected!
See: http://www.bigresource.com/Tracker/Track-ms_sql-cBsxsUSH/