I tried to use AWS DMS to migrate MySQL innodb cluster on another cloud provide to AWS. I uploaded self signed CA.pem generated by MySQL it doesn't work.
AWSDatabaseMigrationService: CA Certificate validation error
DMS SSL mode doesn't have required option for MySQL. So I am stuck...
I am wondering what should I do in this case. There are two solutions I've thought of.
replace the CA and all server certificate so DMS can work with it. Not sure if there's any potential risk for this.
spin up another EC2 replication instance by myself. Then RDS can replicate the EC2 instance. (The reason I am not able to use auto positioning in RDS is none of the cluster node has all the binary log)
Most of the thread in AWS forum is not answered. I feel it's better to ask here.
Any suggestion or idea would be good. Thanks.
So I eventually went with the option #1, and it works.
One biggest problem I encountered was after importing our CA and server certificate to MySQL it can't be connect with --ssl-ca specified. However with only --ssl it is fine.
In MySQLWorkbench SSL connection error: error:00000001:lib(0):func(0):reason(1) error message was totally useless. On DMS it said Error 2026 (SSL connection error: unable to get issuer certificate) connecting to MySQL server.
It turns out the problem was on OSX and DMS it doesn't trust AddTrust External CA Root or it doesn't have that root certificate in their keystore. So I had to manually add the root certificate into CA bundle file.
To make it more concrete here's the chain.
company certificate -> COMODO RSA Domain Validation Secure Server CA -> COMODO RSA Certification Authority (which is NOT the root certificate in OSX Keychain) -> AddTrust External CA Root
I don't know why OSX & DMS couldn't verify the root certificate by default. It took me two days to figure out the problem. Hopefully this information will be helpful to others having trouble with COMODO issued certificate.
UPDATE (2018/11/07):
DMS turned out will have missing record or unmatched record if it only migrate data to the existing schema. I have turned off foreign key check but the situation still exists.
I ended up went to #2 route.
Related
I'm having issues connecting Domo to a MySQL database hosted with AWS RDS. Whenever I try to authenticate I get this error:
"Failed to authenticate. Verify the credentials and try again. Domo is ready, but the credentials you entered are invalid. Verify your account credentials and try again. Error setting up SQL connection. Could not create connection to database server. Attempted reconnect 3 times. Giving up."
Its not security group settings. Someone suggested on this post:
https://dojo.domo.com/t5/Data-Sources-and-Connectors/MySQL-connector-issues/td-p/15462
that I should enable SSL in AWS database but I'm not sure how to do that.
I'll assume you're using the MySQL connector, not the MySQL SSH connector.
It sounds like you need to whitelist Domo's IP addresses within your AWS RDS's security groups.
Aside from that, make sure you're populating the credentials in Domo with the right pieces of information. Hostname should be the server's public IP address.
This connector follows the same general process as described in AWS's documentation here, with the exception that steps 5 and 6 are optional since SSH is not required for this connector.
I set up a new MySQL instance on AWS RDS (Aurora). I added a user that requires SSL, and downloaded the combined ca bundle as described here and here: SSL Connection error, and I can connect via command line and confirm that the user is securely connected. I also turned off the SSL requirement for the user temporarily and was able to connect with MySQL Workbench with SSL turned off.
The problem is that both MySQL Workbench and my Rails app expect three separate files: SSL CA, SSL Cert, and SSL Key.
I'm sure there has to be an easy solution to it, but much Googling is not finding the answer, including this unanswered one on the AWS forums. I appreciate the help.
You don't need any other files. When it comes to the MySQL Workbench you need to provide "SSL CA File" and "Use SSL" ("Require" or "Require and Verify CA").
After that you can verify your connection by using the following command:
SHOW SESSION STATUS LIKE 'Ssl_cipher';
I have a MySQL database running and I created a new user called 'ssluser' with SSL REQUIRED. I'm having trouble with this user logging in from a client to a remote server.
I verified the firewall is not an issue. iptables are not reporting dropped packets.
I am able to connect from nonssluser to the remote server without an issue.
On the server my.cnf I have the CA, Cert, and Key file in place and MySQL WorkBench shows that SSL is enabled.
On the client, I have CA, Cert, and Key file in place as well.
For both certificates I used the FQDN as the common name. I'm not sure if that is the issue or not. Any ideas?
The connection is on a private network in the Digital Ocean datacenter NYC.
[1045] Access denied for user
is a MySQL thing - which means that you are connecting - SSL does not seem to be the problem.
This most likely means you are authenticating wrong (have the wrong password).
Check this to see if it helps if you are sure you have the right password.
To answer my question:
1 - The password was incorrect
and
2 - The application does not support SSL MySQL connections
I'm seeking to clear some information up for myself involving remote SSL connections to MYSQL. Particularly, once I have MYSQL setup to enable SSL and have a remote user that requires SSL.
This is how I connect (commandline), remotely, to MYSQL with a user that requires SSL:
mysql -uMyUserName -p -h192.168.5.5 --ssl-ca /path/to/ca.pem
My question is: Why do I have to provide the ca.pem file as the client?
These are the steps I took to install mysql on the server and setup remote access (Ubuntu):
Steps to Enable SSL for MYSQL
1) Obtain my Certificate Authority cert, Database cert, Database key
ca.pem (Certificate Authority cert)
dbcert.pem (Database cert)
dbkey.pem (Databse key)
2) Add the following lines to /etc/mysql/my.cnf under [mysqld]
ssl-ca=/path/to/ca.pem
ssl-cert=/path/to/dbcert.pem
ssl-key=/path/to/dbkey.pem
3) Restart mysql and confirm ssl enabled by logging in and typing following:
show variables like '%ssl%';
Configure Remote Connection Requiring SSL
1) Comment out the following lines in /etc/mysql/my.cnf
#bind-address
#skip-networking
2) Login to mysql and grant a user access to, in this case, every database
GRANT ALL PRIVILEGES ON . to 'USERNAME'#'%' IDENTIFIED BY 'PASSWORD' REQUIRE SSL
At this point, I have MYSQL setup to enable SSL && I have a remote user that will require SSL to login. I am able to login on a remote commandline, but i need to specify the --ssl-ca.
Why do I have to provide the ssl-ca from client? Is there a way to do this so that I don't have to?
I would really appreciate some insight here.
Thanks in advance.
Unlike your typical web browser, a commandline tool like mysql doesn't have a built-in list of certificate authorities. Browsers come with a built in list of certification authorities, and you implicitly trust them (whether you know it or not).
When you use mysql to log in to a MySQL server supporting encryption, that server will present you the public part of a certificate. To complete the secure handshake, your client needs to verify the server certificate is signed by a trusted certificate authority. Otherwise, it will have to say "hey, this looks like a well-formed certificate, but I never heard of the ca signing it."
For Hibernate / JDBC / TLS, a little bit of search-engine work turns up some useful suggestions. It's all about setting the right properties in your config.
http://razorsql.com/articles/mysql_ssl_jdbc.html
How can I configure Hibernate to use SSL to talk to the DB server?
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!