my connector complain about certificate RSA keysize when I try to connect SQL Server
Algorithm constraints check failed on keysize limits: RSA 1024 bit key used with certificate
It is strange that we tried couple servers with the same setup but only one got this error.
I have tried 1.6.3 and 1.9.5 both of them have the same error on certain servers.
I know it is set from java.security but it still doesn't work if I make the change like removing RSA keysize < 2048
Another question is why it only happens to certain server. As far as I know, all my servers use 1024 bit RSA for certificate and encrypt is not enabled for the connection either.
So apparently there is another config located at /etc/crypto-policies/back-ends/java.config
So here is what I end up doing
ARG STRIMZI_VERSION="0.28.0"
ARG KAFKA_VERSION="3.1.0"
ARG DEBEZIUM_VERSION="1.9.5.Final"
FROM quay.io/debezium/connect:${DEBEZIUM_VERSION} as connectors
FROM quay.io/strimzi/kafka:${STRIMZI_VERSION}-kafka-${KAFKA_VERSION}
USER root:root
ARG DEBEZIUM_CONNECTOR="sqlserver"
COPY --from=connectors /kafka/connect/debezium-connector-${DEBEZIUM_CONNECTOR}/ /opt/kafka/plugins/debezium-connector-${DEBEZIUM_CONNECTOR}/
RUN sed -i -e 's/RSA keySize < 2048,//g' /usr/lib/jvm/java-11-openjdk-11.0.14.0.9-2.el8_5.x86_64/conf/security/java.security \
& sed -i -e 's/, RSA keySize < 2048//g' /etc/crypto-policies/back-ends/java.config
USER 1001
Although it would be nice if someone can answer why debezium would check keysize on certain server only.
Related
I am trying to deploy the PostgreSQL with CA Signed SSL Certificate and Keys (With passphrase).
When I try to start pgsql service, it is expecting the PEM password but it will not work in the interactive way.
Do we have any non-interactive way to provide the SSL passphrase ? (Automatic restart or stop will not work otherwise)
I found this article How to enable SSL in PostgreSQL/PPAS referring to use pg_ctl start -w so that the service will ask for the SSL key passphrase.
I also found this article PostgreSQL with passphrase-protected SSL keys under systemd saying about the use of ssl_passphrase_command but which also in turn asking the PEM passphrase interactively.
Thanks
You can set the following PostgreSQL parameters:
ssl = on
ssl_cert_file = 'server.crt'
ssl_key_file = 'server.key'
ssl_passphrase_command = 'echo "mypassword"'
ssl_passphrase_command_supports_reload = on
Here, echo is an operating system command that just echos the argument. You will have to escape special characters like ' or " in the password.
I have a MariaDB server set up with self-signed certificates to connect using TLS. This works when I connect with the corresponding client
$ mysql -u xxxx -h xx.xx.xx.xx -p
\s shows:
mysql Ver 15.1 Distrib 10.1.37-MariaDB, for debian-linux-gnu (x86_64)
SSL: Cipher in use is DHE-RSA-AES256-SHA
The .my.cnf contains:
$ cat ~/.my.cnf
[client]
ssl-cert=/---path-deleted---/client-cert.pem
ssl-key=/---path-deleted---/client-key.pem
Problem: I don't manage to connect from a Perl script with these settings. Without SSL, the script works. As soon as I enable SSL in the script (and enforce it on the server), I get:
failed: SSL connection error: ASN: bad other signature confirmation
When I check the certificates with openssl, I get
$ openssl verify ca-cert.pem client-cert.pem server-cert.pem
error 18 at 0 depth lookup: self signed certificate
The certificates are indeed self-signed, and I want to keep it that way.
If I use "mariadb_ssl_verify_server_cert=0", I get
failed: SSL connection error: Enforcing SSL encryption is not supported without mariadb_ssl_verify_server_cert=1
What do I need to change to have a TLS-connection working from Perl?
I copy the lines of code I have in my connect sub for reference. A very similar code used to work on an older system with mysql (not mariadb), using just mysql_ssl=1 IIRC:
$self->{dsn} = "DBI:MariaDB:database=$database;host=$db_host;mariadb_ssl=1;".
"mariadb_ssl_verify_server_cert=1;".
"mariadb_ssl_ca_file=/---path---/ca-key.pem;".
"mariadb_ssl_client_key=/---path---/client-key.pem;".
"mariadb_ssl_client_cert=/---path---/client-cert.pem";
$self->{dbh} = DBI->connect($self->{dsn}, $db_user, $db_passwd,
{'RaiseError' => 1, 'PrintError' => 1, AutoCommit => 1});
I had a similar problem, albeit using DBI:mysql.
Issue was that I specified the IP address in the connection string rather than the servername, as specified in the SSL certificate CN. The mysql command line client didn't mind, but DBI:mysql does.
To get the CN of the certificate, I used openssl as per https://serverfault.com/a/931652/243186
I then needed to add an entry in my /etc/hosts file such that the CN matched the IP of the interface I was connecting to.
An alternate solution would have been for the MySQL server owner to have generated an SSL SAN cert specifying all possible servernames and IPs it could be connected to as.
I got a new Windows computer and installed putty on it. I exported the registry keys from the old computer and imported them to recover the Putty connections and avoid adding them manually.
I also copied the rsa public key .ppk to the new computer and selected it in the Auth section in putty, but I get the following error:
Unable to use key file "c:\path\to\id_rsa.ppk" (unable to open file)
I'm temped to regenerate the key pair again in the VPS server but I thought public keys could be used by any computer!
Am I missing something? Any help is appreciated.
Thanks!
Edit:
Plink output (plink -v username#hostname -i "c:\path\to\id_rsa.ppk") as requested by #Martin Prikryl:
We claim version: SSH-2.0-PuTTY_Release_0.70
Server version: SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.1
Using SSH protocol version 2
Doing ECDH key exchange with curve Curve25519 and hash SHA-256
Server also has ssh-ed25519/ecdsa-sha2-nistp256 host keys, but we don't know any of them
Host key fingerprint is:
ssh-rsa 2048 24:2a:c3:65:b9:9a:3e:5f:59:fc:dc:15:42:31:0b:a0
Initialised AES-256 SDCTR client->server encryption
Initialised HMAC-SHA-256 client->server MAC algorithm
Initialised AES-256 SDCTR server->client encryption
Initialised HMAC-SHA-256 server->client MAC algorithm
Reading key file "D:\path\to\id_rsa.ppk"
Using username "user".
Offered public key
Offer of public key accepted
Authenticating with public key "imported-openssh-key"
Sent public key signature
Access granted
Opening session as main channel
Opened main channel
Allocated pty (ospeed 38400bps, ispeed 38400bps)
Started a shell/command
Edit 2:
putty.exe -v username#hostname -i "c:\path\to\id_rsa.ppk" throws a timeout error.
It seems that you didn't "select" the key on the Connection > SSH > Auth page.
You have rather typed key name there only, without a path. So PuTTY cannot find it.
You need to use a full path to the key file, like C:\path\to\id_rsa.ppk.
Following this link:
You used Putty Private Key format (.ppk)
Convert your ppk to Openssh Key File (id_rsa)
And here is an explanation how to do it. Hope it helps.
I'm trying to set up a PostgreSQL db server with ssl. Or more specifically, I've successfully set up the server and ssl is working... as long as there are no intermediate certificates. It's not working if there is an intermediate cert.
Background / Setup:
I have a root CA.cert.
I used the CA to sign an intermediate.csr and create an intermediate.cert.
I used the intermediate.cert to sign a postgres.csr and create a postgres.cert.
The CA.cert, postgres.key and postgres.cert have been installed on the server.
The CA.cert has been set as a trusted certificate.
postgresql.conf has been modified to point to the above files.
I used the intermediate.cert to sign a client_0.csr and create a client_0.cert.
I used the CA.cert to sign a client_1.csr and create a client_1.cert.
I create a client chain.cert: cat client_0.cert intermediate.cert > chain.cert
Proper extensions have been used, both client certs have their common name set to the (username) of the db being connected to.
Fun, aka The Problem.
psql "sslmode=require hostname=(host) db=(db) sslcert=client_1.cert sslkey=client_1.key" -U (username): Great success!
psql "sslmode=require hostname=(host) db=(db) sslcert=client_0.cert sslkey=client_0.key" -U (username): alert unknown ca. This is expected, client_0.cert is not signed by CA.cert.
psql "sslmode=require hostname=(host) db=(db) sslcert=chain.cert sslkey=client_0.key" -U (username): alert unknown ca. Uh oh.
Confusion
Documentation for connecting to a postgresql instance with ssl enabled and intermediate certificates present:
In some cases, the client certificate might be signed by an
"intermediate" certificate authority, rather than one that is directly
trusted by the server. To use such a certificate, append the
certificate of the signing authority to the postgresql.crt file, then
its parent authority's certificate, and so on up to a certificate
authority, "root" or "intermediate", that is trusted by the server,
i.e. signed by a certificate in the server's root.crt file.
https://www.postgresql.org/docs/9.6/static/libpq-ssl.html
I have also tried cat-ing the full chain, client inter ca > chain , nothing doing.
Question
What have I done wrong here?
Thank you,
haproxy does not start anymore, it shows the error
bind <ip>:443' : unable to load SSL private key from PEM file ...
We did not change anything on the certificates or configuration. Since the last start we only made normal updates to the system.
To find the error, I generated a completely new certificate (self signed) but the error still exists.
This is the structure of the PEM file:
-----BEGIN CERTIFICATE-----
MIIDXjCCAkY...
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
MIIEpgIBAAKC....
-----END RSA PRIVATE KEY-----
I also tried to convert the private key with
openssl pkcs8 -topk8 -inform pem -in server.key -outform pem -nocrypt -out server_new.key
but haproxy still shows the same error.
I'm trying for hours now but I can not find the reason. Please help! Thank you!
Update:
The problem has something to do with file access. The PEM file was stored at /data/ssl/domainname/domainname.pem. File rights are ok. When I move the PEM file to /etc/haproxy then everything is ok.
The order in which the cert and key files appear in the pem is important. Use the following to create the pem file.
cat example.com.crt example.com.key > example.com.pem
The problem I was running into on CentOS was SELinux was getting in the way. To test if SELinux is the problem execute the following as root: setenforce 0, then try restarting the haproxy. If it works, there is an SELinux problem. (You can re-enable SELinux now and try to fix the underlying problem with the command setenforce 1).
Since I have the certificates in the folder /etc/haproxy/certificates, the following command worked to get the right permissions on the files restorecon -v -R /etc/haproxy (depending on your OS and SELinux config this may or may not work).
For me the problem was caused by this line in combined PEM file:
-----END CERTIFICATE----------BEGIN RSA PRIVATE KEY-----
After I split it I could start HaProxy and load it OK:
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
For the latest version of letsencrypt certbot,fullchain.pem and privkey.pem files will be generated for you in /etc/letsencrypt/live/example.com folder. They need to be combined in order to HAProxy to read it properly.
cat fullchain.pem privkey.pem > example.com.pem
In HAProxy configuraion /etc/haproxy/haproxy.cfg
bind *:443 ssl crt /etc/letsencrypt/live/example.com/example.com.pem
I also encountered this error. You might want to try to remove the passphrase from the private key before you begin ripping your hair out. It solved the problem for me. I think HAProxy is supposed to ask you for the password on restart, but it didn't in my case using 'sudo /etc/init.d/haproxy restart
To remove the password, try
'openssl rsa -in [PRIVATE_KEY_FILE] -out nopassphrase.key'
Is passphrase necesssary? There's a discussion in the link below.
https://security.stackexchange.com/questions/70495/ssl-certificate-is-passphrase-necessary-and-how-does-apache-know-it
Did you append your certificate's private key to the end of the file?
HAProxy requires a "full chain" - certificate, intermediate authority (if you have one), and then private key. E.g.:
cat cert.pem cert.key > /haproxy/certs/fullchain.pem
The problem for me was a strange character at the beginning of the key.
This character did not show up when I cated the file because the character was <feff> otherwise known as the UTF-8 BOM (Byte Order Mark). It only showed up when I opened the file in vim.
I wouldn't expect this to be very common, but hopefully it saves someone some headache.
Just for information, in my case I had space character in front of "-----BEGIN RSA PRIVATE KEY-----" sequence and that broke the pem file.
I'd like to add, for people which join here and have the same issue, that you have to keep your intermediate certificates in the chain as well...
So if you have a chain with some layers, don't only take the rootca but also the intermediate certificates into your pem file
SElinux was the problem for me as well. HAProxy reported it could not read the file due to permissions even though the permissions matched other pem files in the folder. Our process is automated which is likely why SELinux is involved. The solution that seems to work for me so far (leaving SELinux running) is:
#!/bin/sh
if [ "$2" == "add" ]; then
sudo touch /etc/haproxy/ssl/$1
sudo cat $1 > /etc/haproxy/ssl/$1
sudo chmod 644 /etc/haproxy/ssl/$1
fi
if [ "$2" == "delete" ]; then
sudo rm /etc/haproxy/ssl/$1
fi
echo "performed $2 on $1";