I have my MySQL instance configured to use TLS. I have verified this by intentionally using untrusted certificates and watching the clients fail to connect (with an appropriate error message) and then restarting the MySQL service with trusted certificates configured and having the clients connect successfully.
I wanted to do a final check using openssl's s_client but I can't get it to work. When I execute the command below, I get an error saying "SSL23_GET_SERVER_Hello:unknown protocol" followed by "no peer certificate available" followed by some more text. However, when I use the same command against a TLS-enabled Tomcat instance and against the Remote Desktop port, I am able to establish the connection and view the server's certificate. What am I doing wrong? Does MySQL do some extra pre-negotiation before the TLS handshake starts?
openssl s_client -showcerts -connect host:port
While MySQL may use TLS, it isn't the total outside layer. There is a small amount of preamble that occurs before TLS starts. The openssl command line isn't aware of this.
Use the mysql client with its TLS options to test the client certificate.
I marked the response from #danblack correct as he did answer the question. However, I want to provide more information in case it helps anyone else. The
small amount of preamble that occurs before TLS starts
that he refers to can be found on GitHub here.
Related
I have a server running Ovirt Node that I'm trying to manage remotely using libvirt. I have an SSH keypair installed and can ssh user#server -i ssh-privkey successfully. When I try to connect to qemu+ssh//user#host/system?keyfile=ssh-privkey, I get this error:
authentication failed: Failed to start SASL negotiation: -4 (SASL(-4): no mechanism available: No worthy mechs found)
That led me down the path of getting TLS keys and certificates installed on the client and the server mostly according to these instructions (the configuration is slightly different because I have only one host and am using Terraform to manage the certificates*). However, I still get the same error. When I look at the output of libvirt --listen --verbose on the server when a connection failed, the only useful output is this:
error : virNetSocketReadWire:1792 : End of file while reading data: Input/output error
I have checked every firewall between the client and the server and they should all be wide open. What else could be the cause of this error?
* The goal is ultimately to use Terraform to provision libvirt resources, however I get the same errors trying to connect with virsh and virt-manager.
UPDATE: It's easier to connect just via SSH; this question exists because I couldn't figure out how to turn off SASL. It turns out SASL is enabled for SSH connections due to vdsm setting auth_unix_rw="sasl" in /etc/libvirt/libvirtd.conf. Removing that config means I can just use my SSH private key as I intended. The TLS configuration was a wild goose chase that was further hindered by vdsm changing the configured location of all the PKI files.
You're likely missing a RPM package on your client host. First on the virtualization host check /etc/sasl2/libvirt.conf and see what 'mech_list' setting is uncommented.
Back on your client you'll need to install a 'cyrus-sasl-XXXX' RPM that provides the same mechanism that the server is set to use. For a modern libvirt install it will probably be using 'cyrus-sasl-scram' for plain username/password auth, but for older installs, it might still be using 'cyrus-sasl-md5'
Any help or hint would be greatly appreciated it!!
I have windows 11 Pro.
I installed openshift.
I did "crc setup" and I did "crc start":
INFO Adding crc-admin and crc-developer contexts to kubeconfig...
ERRO Cannot update kubeconfig: x509: certificate has expired or is not yet valid: current time 2022-05-24T00:01:26-04:00 is after 2022-01-13T22:29:55Z
Started the OpenShift cluster.
The server is accessible via web console at:
https://console-openshift-console.apps-crc.testing
I get the following error when I tried to login:
C:\Users\Albert Lam>oc login -u developer https://api.crc.testing:6443
The server uses a certificate signed by an unknown authority.
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
Use insecure connections? (y/n): n
error: The server uses a certificate signed by unknown authority. You may need to use the --certificate-authority flag to provide the path to a certificate file for the certificate authority, or --insecure-skip-tls-verify to bypass the certificate check and use insecure connections.
C:\Users\Albert Lam>oc login -u developer https://api.crc.testing:6443
The server uses a certificate signed by an unknown authority.
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
Use insecure connections? (y/n): y
I had the same problem and it was caused by an old certificate that was expired and had nothing to do (VMware one) with Openshift.
I've found the problem by viewing the certificate inside my chrome browser after navigating to https://console-openshift-console.apps-crc.testing.
The correct certificate should have *.apps-crc.testing as CN, but mine has another one.
I suggest you to find the wrong certificate and delete it if expired.
On windows, for VMware you can find it inside C:\ProgramData\VMware\SSL.
On Windows you can look for certificates by using the "manage certificates" app.
I have a MySLQ running on a CentOS server with SSL enabled and it require SSL in order to connect to the databases. I created the certificates and keys using OpenSSL, getting this files:
ca.pem
ca-key.pem
client-cert-pem
client-key-pem
server-cert.pem
server-key.pem
Setup MySQL with this:
ssl-ca=/etc/certs/ca.pem
ssl-cert=/etc/certs/server-cert.pem
ssl-key=/etc/certs/server-key.pem
bind-address=*
require_secure_transport=ON
I created a user that require X509 on the MySLQ by using:
CREATE USER 'user'#'%' IDENTIFIED BY '<password>' REQUIRE X509;
Testing with the MySQL client console and MySQL Workbench providing the client certs and it works fine. Also works on a Java App that writes/reads the databases by importing certifitates to the keytores/trustores.
However, I cannot set up Power Bi Desktop version to connect to the MySQL server. I imported the certificates to the Trusted Root Autenticathion Authorities and a PKCS12 keystore and trustore (used also by the Java App). This image shows the certificate. It is in Spanish, but it says it has also the key and it is verified by the ca.pem.
This is according to the documentation, but the documentation about this is very old and very limited. Some of the process and/or tools are out of date.
This are the sources I could find:
https://github.com/Microsoft/PowerBI-visuals/blob/master/tools/CreateCertificate.md#generate-certificate-manually
https://github.com/Microsoft/PowerBI-visuals/blob/master/tools/CertificateAddWindows.md
https://powerbi.microsoft.com/es-es/blog/ssl-security-error-with-data-source/
However there is not much more info about how to properly connect (or I cannot find it).
The message I get on Power Bi is "We were unable to authenticate you with the credentials provided. Try again."
I must add that disabling SSL allows me to connect to the databases using Power Bi, without any issue, it is the SSL what doesn't work as I don't know how to properly provide the certificates and I cannot find anything that decribes the process.
I am trying to establish a SSL-encrypted connection to a my MySQL Docker service running on a AWS VPC (setup up by the Docker for AWS cloud formation template). The elastic load balancer is configured to redirect port 3306. There is no problem to connect to the container (e.g. by using MySQLWorkbench, mysql-client, ..) as long as SSL is not turned on (adding AWS's own certificates (ACM) or my custom certificates to the ELB listener). In case SSL is enabled, the client starts hanging / freezing, without returning a proper error. I added the ca-certs from ACM, generated my own certificates (with and without additonal key / cert for the client) but nothing seems to resolve my problem.
Now I am well aware of the fact, that this setup is not that usual. I guess the standard way of doing this is to configure the MySQL-Server itself. AFAIK, in this case only the connection between client and ELB is encrypted, but I do not understand why this causes a problem?
I am grateful for answers!
In MySQL's client/server protocol, the server talks first. It advertises its capabilities (including whether it supports SSL). Then the client requests that the connection switch to SSL mode. Only then does SSL negotiation take place.
For this reason, it is not possible to offload SSL in front of MySQL.
Your connection hangs because the client is waiting for the initial packet from the server, while the ELB is waiting for the client to start negotiating SSL -- because unlike the MySQL client/server protocol, the client talks first on standard SSL negotiation.
You have to have a certificate on the MySQL Server, and not on the ELB, for this to work.
An AWS Network Load Balancer is a more appropriate solution for exposing MySQL, but you still need the SSL cert on the MySQL Server itself.
I am seasoned with Ubuntu, Apache and MySQL but new to the email server world and an looking for some troubleshooting tips with my server configuration.
I am running Ubuntu 14.04 with Postfix, Dovecot and MySQL as instructed in this tutorial: https://www.digitalocean.com/community/tutorials/how-to-configure-a-mail-server-using-postfix-dovecot-mysql-and-spamassassin
with the exception of spamassassin.
I then installed postfixadmin to provide a graphical means of configuring my virtual postfix users/domains.
Thereafter I installed Roundcube as instructed in this tutorial: http://www.unixmen.com/install-configure-roundcube-webmail-ubuntu/ with the exception of the version (I am using 1.1.4). Everything checks out; I can Telnet into my mail server with accounts created using postfixadmin and can verify the mailbox(es) exists. The server receives email from external domains and can send as well. However, when I attempt to login to a verified user account via-Roundcube it fails. I have tried and tried again to find what is missing and have hit a wall.
Any suggestions would be greatly appreciated.
Best Regards,
-Joe
To debug, I would double check that RC is configured correctly to communicate with dovecot: this is the piece of software that is going to handle the authentication. To verify the software settings, one could switch on the debugging of both RC and dovecot.
Check RC configuration files to make sure that it is set up to connect to the right server and port. These settings can be found either in 'config.inc.php' or in 'defaults.inc.php' under the 'config' directory of RC. Look for IMAP section and the following strings:
$config['default_host'] = 'tls://localhost';
$config['default_port'] = 143;
$config['imap_auth_type'] = null;
Pay special attention to the 'tls://' ('ssl://') prefixes -- these control the usage of encryption during negotiation with IMAP server (tls issues STARTTLS command while connecting on a standard port, and ssl expects connection to be encrypted from the very start and thus is generally used to connect to a dedicated 'encryped' port): for the purposes of debugging one might want to disable encryption altogether. I would propose to use the same hostname and port as were used for telnetting.
If these settings seem to be right, one can proceed to debugging of IMAP connection from RC to dovecot. To enable debugging, edit defaults.inc.php once again:
$config['debug_level'] = 1;
$config['log_driver'] = 'syslog';
$config['syslog_id'] = 'roundcube';
$config['syslog_facility'] = LOG_MAIL;
$config['log_logins'] = true;
$config['imap_debug'] = true;
This would direct debug information of RC IMAP negotiation with dovecot to /var/log/mail.log, where you most probably would be able to identify the problem.