We have a simple script which will run at 4 AM everyday to copy the latest backup of our production database and restore it on our staging database:
/usr/bin/trickle -s -d 30720 -u 30720 -t 10 -l 100 /usr/bin/scp -r root#$MARIADB_REMOTE_HOST:$MARIADB_REMOTE_HOME $MARIADB_DATA_DIR || RESPONSE=$? && true
The source ($MARIADB_REMOTE_HOST) is a bare-metal server and the destination is a VM ran by KVM (OpenNebula). Both of them running Ubuntu 18.04 .
Last week we changed our network switch which was connecting our bare-metals and after that the script will stuck at some point in the middle of the scp.
It doesn't follow any pattern and doesn't exit; It just stuck and when I move my terminal to another monitor, It start again (continue) and obviously It's not a solution !!!
I tried to run it with "-v" but it didn't help (The last line was printed by the script due to the SIGTERM that I've sent):
Sending file modes: C0640 561 delivery_category_equivalency.frm.qp
Sink: C0640 561 delivery_category_equivalency.frm.qp
Sending file modes: C0640 3817 order_config_prioritization.ibd.qp
Sink: C0640 3817 order_config_prioritization.ibd.qp
Sending file modes: C0640 482 item_service.frm.qp
Sink: C0640 482 item_service.frm.qp
Sending file modes: C0640 429 feedback_record.frm.qp
Sink: C0640 429 feedback_record.frm.qp
Sending file modes: C0640 381409 order_configs.ibd.qp
Sink: C0640 381409 order_configs.ibd.qp
Sending file modes: C0640 35810042703 terminals.ibd.qp
Sink: C0640 35810042703 terminals.ibd.qp
debug1: SSH2_MSG_KEXINIT received
debug1: SSH2_MSG_KEXINIT sent
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: rekeying in progress
debug1: rekeying in progress
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:ngRaDyCEeh6BBJFLMC7xq2Cl5h/ICky2/+Hbn/UpUzY
debug1: ssh_set_newkeys: rekeying out, input 49398838524 bytes 134202402 blocks, output 8768056 bytes 19126 blocks
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: ssh_set_newkeys: rekeying in, input 49398838536 bytes 134202403 blocks, output 8768056 bytes 0 blocks
debug1: rekey in after 134217728 blocks
debug1: SSH2_MSG_KEXINIT received
debug1: SSH2_MSG_KEXINIT sent
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: rekeying in progress
debug1: rekeying in progress
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:ngRaDyCEeh6BBJFLMC7xq2Cl5h/ICky2/+Hbn/UpUzY
debug1: ssh_set_newkeys: rekeying out, input 50472727740 bytes 134203417 blocks, output 8960060 bytes 19238 blocks
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: ssh_set_newkeys: rekeying in, input 50472727752 bytes 134203418 blocks, output 8960060 bytes 0 blocks
debug1: rekey in after 134217728 blocks
debug1: SSH2_MSG_KEXINIT received
debug1: SSH2_MSG_KEXINIT sent
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: rekeying in progress
debug1: rekeying in progress
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:ngRaDyCEeh6BBJFLMC7xq2Cl5h/ICky2/+Hbn/UpUzY
debug1: ssh_set_newkeys: rekeying out, input 51546616956 bytes 134203417 blocks, output 9149904 bytes 19022 blocks
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: ssh_set_newkeys: rekeying in, input 51546616968 bytes 134203418 blocks, output 9149904 bytes 0 blocks
debug1: rekey in after 134217728 blocks
debug1: SSH2_MSG_KEXINIT received
debug1: SSH2_MSG_KEXINIT sent
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: rekeying in progress
debug1: rekeying in progress
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:ngRaDyCEeh6BBJFLMC7xq2Cl5h/ICky2/+Hbn/UpUzY
debug1: ssh_set_newkeys: rekeying out, input 52620506172 bytes 134203417 blocks, output 9340548 bytes 19102 blocks
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: ssh_set_newkeys: rekeying in, input 52620506184 bytes 134203418 blocks, output 9340548 bytes 0 blocks
debug1: rekey in after 134217728 blocks
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 2 clearing O_NONBLOCK
Killed by signal 15.
Removing old MariaDB's files failed at "20210722-0055" with 1
It goes without saying that when it stuck, I don't see any traffic between these 2 servers when I inspect it via iftop or tcpdump.
I will appreciate it if you share your idea about how to address this issue.
Test your SCP with these options
scp -o ServerAliveInterval=15 -o ServerAliveCountMax=3 <yourServerIP>:~
In this example, every 15 seconds looking back for acks and if 3 acks in 45 seconds (15*3) not coming back close the session.
Related
Client 2 successfully maintains a wireguard connection.
Client 1 repeatedly creates/destroys keypairs.
Both profiles work fine on Client 2 (Android, mobile connection)
Both profiles don't work properly even though they did in the past, on Client 1 (Windows, cloud VM)
I've restarted the wg0 interface. Constant pings to the wireguard server do not show any issues from Client 1, I just can't load any pages I suspect because the keypairs constantly change. No other device is using Client 1's profile. One odd thing is how 2 keypairs seem to be created at the same time, which is likely the cause of them perpetually being destroyed.
How can I troubleshoot what is causing the keypair to need to be recreated so frequently?
2022-07-25 07:21:25.332: [TUN] [client1] Keypair 11 created for peer 1
2022-07-25 07:21:25.332: [TUN] [client1] Sending keepalive packet to peer 1 (:51820)
2022-07-25 07:21:25.518: [TUN] [client1] Receiving keepalive packet from peer 1 (:51820)
2022-07-25 07:21:41.666: [TUN] [client1] Receiving handshake initiation from peer 1 (:51820)
2022-07-25 07:21:41.666: [TUN] [client1] Sending handshake response to peer 1 (:51820)
2022-07-25 07:21:41.667: [TUN] [client1] Keypair 10 destroyed for peer 1
2022-07-25 07:21:41.667: [TUN] [client1] Keypair 12 created for peer 1
2022-07-25 07:21:41.882: [TUN] [client1] Receiving keepalive packet from peer 1 (:51820)
2022-07-25 07:22:28.060: [TUN] [client1] Receiving keepalive packet from peer 1 (:51820)
2022-07-25 07:22:52.214: [TUN] [client1] Retrying handshake with peer 1 (:51820) because we stopped hearing back after 15 seconds
2022-07-25 07:22:52.214: [TUN] [client1] Sending handshake initiation to peer 1 (:51820)
2022-07-25 07:22:52.385: [TUN] [client1] Receiving handshake response from peer 1 (:51820)
2022-07-25 07:22:52.385: [TUN] [client1] Keypair 11 destroyed for peer 1
2022-07-25 07:22:52.385: [TUN] [client1] Keypair 13 created for peer 1
2022-07-25 07:22:52.385: [TUN] [client1] Sending keepalive packet to peer 1 (:51820)
2022-07-25 07:22:52.571: [TUN] [client1] Receiving keepalive packet from peer 1 (:51820)
I've stumbled upon this exact issue (or very similar?) so here is what worked for me:
if the client is unable to finish the handshake - I'd suggest to try to regenerate the keys - as suggested here:
https://serverfault.com/questions/1040165/wireguard-not-completing-handshake
this however did not solve my issue..
1st verify if reported WAN IP address in wireguard server log matches the one of the client. Mine was off in the last octet - which is very strange.
Since my client is hosted on ISP network that shares one public IP address for many hose holds - it's possible that UDP packets were ending up on some other wireguard instance (?speculation) - unable to tell exactly as I have almost no visibility into ISP internal networking.
2nd if the WAN IP of client (you can verify like curl -s ipinfo.io/ip or by typing "what is my IP" into google) does not match - you may want to change client wg0.conf to listen on a different port than ListenPort = 51820 - I've adjusted it like so:
root#wg-client2:~# cat /etc/wireguard/wg0.conf
[Interface]
PrivateKey = ###MODERATED###
Address = ###MODERATED###/24
ListenPort = 51810
this client conf change does not need any server conf change.
I did wg-quick down wg0 && wg-quick up wg0 on both server and client and the comm was then established. (possible that only client needs to be restarted).
to check for wireguard kern. logs:
echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control
dmesg -wT | grep wireguard
to dump all clients on server: wg show all dump
good article on wireguard logging: https://www.procustodibus.com/blog/2021/03/wireguard-logs/
Never came back with an update, but the issue turned out to be packets being fragmented somewhere in the path of the host. I believe on their end since it worked for years then suddenly stopped. I reduced the MTU in the wireguard config and the problem was resolved.
Just in case someone else runs into similar...
I'm trying to connect to a SQL Server 2008 R2 (Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64)) from Xubuntu 22.04 and .NET 6.0:
var sqlConnection = new SqlConnection("Server=server;Database=MyDb;User Id=MyUser;Password=MyPassword;ENCRYPT=false;TrustServerCertificate=true");
When trying to use the connection I get this error:
System.Data.SqlClient.SqlException : A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 35 - An internal exception was caught)
---- System.Security.Authentication.AuthenticationException : Authentication failed, see inner exception.
-------- Interop+OpenSsl+SslException : SSL Handshake failed with OpenSSL error - SSL_ERROR_SSL.
------------ Interop+Crypto+OpenSslCryptographicException : error:0A000102:SSL routines::unsupported protocol
As you can see from the connection string I already tried Encrypt=false and TrustServerCertificate=true.
I also tried the solution from https://stackoverflow.com/a/72137669/90800:
sed -i 's/openssl_conf = openssl_init/#openssl_conf = openssl_init/g' /etc/ssl/openssl.cnf
I also tried this one:
MinProtocol=TLSv1 CipherString=DEFAULT#SECLEVEL=1 dotnet run
Update:
It works without modifications from a Windows client.
Update:
I changed /etc/ssl/openssl.cnf from this:
[system_default_sect]
CipherString = DEFAULT:#SECLEVEL=2
to this:
[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT#SECLEVEL=1
Now the error is:
System.Data.SqlClient.SqlException
A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 31 - Encryption(ssl/tls) handshake failed)
This
[system_default_sect]
CipherString = DEFAULT#SECLEVEL=1
Causes this:
Interop+OpenSsl+SslException
SSL Handshake failed with OpenSSL error - SSL_ERROR_SSL.
at Interop.OpenSsl.DoSslHandshake(SafeSslHandle context, ReadOnlySpan`1 input, Byte[]& sendBuf, Int32& sendCount)
at System.Net.Security.SslStreamPal.HandshakeInternal(SafeFreeCredentials credential, SafeDeleteSslContext& context, ReadOnlySpan`1 inputBuffer, Byte[]& outputBuffer, SslAuthenticationOptions sslAuthenticationOptions)
Interop+Crypto+OpenSslCryptographicException
error:0A0C0103:SSL routines::internal error
Exception doesn't have a stacktrace
Update:
There must be an option that works because from the same machine I can connect to the database using DataGrip with the jTds driver.
Update:
[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT#SECLEVEL=1
Result:
Interop+OpenSsl+SslException
SSL Handshake failed with OpenSSL error - SSL_ERROR_SSL.
at Interop.OpenSsl.DoSslHandshake(SafeSslHandle context, ReadOnlySpan`1 input, Byte[]& sendBuf, Int32& sendCount)
at System.Net.Security.SslStreamPal.HandshakeInternal(SafeFreeCredentials credential, SafeDeleteSslContext& context, ReadOnlySpan`1 inputBuffer, Byte[]& outputBuffer, SslAuthenticationOptions sslAuthenticationOptions)
Interop+Crypto+OpenSslCryptographicException
error:0A000102:SSL routines::unsupported protocol
Exception doesn't have a stacktrace
Update (from https://github.com/dotnet/SqlClient/issues/567):
openssl s_client -tls1 -connect server:1433
CONNECTED(00000003)
Update:
These changes have been made to the registry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
"Enabled"=dword:ffffffff
"DisabledByDefault"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"Enabled"=dword:ffffffff
"DisabledByDefault"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"Enabled"=dword:ffffffff
"DisabledByDefault"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"Enabled"=dword:ffffffff
"DisabledByDefault"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"Enabled"=dword:ffffffff
"DisabledByDefault"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"Enabled"=dword:ffffffff
"DisabledByDefault"=dword:00000000
Update:
I also installed the root CA certificate like this:
sudo apt-get install -y ca-certificates
sudo cp local-ca.crt /usr/local/share/ca-certificates
sudo update-ca-certificates
Update:
More openssl output:
SSL_connect:before SSL initialization
>>> TLS 1.0, RecordHeader [length 0005]
16 03 01 00 74
>>> TLS 1.1, Handshake [length 0074], ClientHello
write to 0x55971383cef0 [0x55971384e1b0] (121 bytes => 121 (0x79))
SSL_connect:SSLv3/TLS write client hello
read from 0x55971383cef0 [0x559713844f93] (5 bytes => -1)
SSL_connect:error in SSLv3/TLS write client hello
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 121 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1658171132
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
read from 0x55971383cef0 [0x559713798600] (8192 bytes => 0)
You need to update your SQL Server machine to use TLS 1.2. Both Windows and SQL Server must be updated, or it will not work.
For Windows itself, you are on Windows Server 2008 R2, which needs this update at a minimum, really you should update to the latest build. Ensure you set the relevant registry settings also.
For SQL Server, you need to get this update at a minimum. You must also be on the SP4 update before you do this.
I strongly recommend you move to newer versions of Windows and SQL Server. Both versions that you have are heavily out-of-date and not receiving the latest security fixes, some of which are very serious.
When I start my apache flink 1.10 taskmanager service in kubernetes(v1.15.2) cluster,it shows logs like this:
2020-05-01 08:34:55,847 INFO org.apache.flink.runtime.taskexecutor.TaskExecutor - Could not resolve ResourceManager address akka.tcp://flink#flink-jobmanager:6123/user/resourcemanager, retrying in 10000 ms: Could not connect to rpc endpoint under address akka.tcp://flink#flink-jobmanager:6123/user/resourcemanager..
2020-05-01 08:34:55,847 WARN akka.remote.transport.netty.NettyTransport - Remote connection to [null] failed with java.net.NoRouteToHostException: No route to host
2020-05-01 08:34:55,848 WARN akka.remote.ReliableDeliverySupervisor - Association with remote system [akka.tcp://flink#flink-jobmanager:6123] has failed, address is now gated for [50] ms. Reason: [Association failed with [akka.tcp://flink#flink-jobmanager:6123]] Caused by: [java.net.NoRouteToHostException: No route to host]
2020-05-01 08:35:08,874 WARN akka.remote.transport.netty.NettyTransport - Remote connection to [null] failed with java.net.NoRouteToHostException: No route to host
2020-05-01 08:35:08,877 WARN akka.remote.ReliableDeliverySupervisor - Association with remote system [akka.tcp://flink#flink-jobmanager:6123] has failed, address is now gated for [50] ms. Reason: [Association failed with [akka.tcp://flink#flink-jobmanager:6123]] Caused by: [java.net.NoRouteToHostException: No route to host]
2020-05-01 08:35:08,878 INFO org.apache.flink.runtime.taskexecutor.TaskExecutor - Could not resolve ResourceManager address akka.tcp://flink#flink-jobmanager:6123/user/resourcemanager, retrying in 10000 ms: Could not connect to rpc endpoint under address akka.tcp://flink#flink-jobmanager:6123/user/resourcemanager..
2020-05-01 08:35:21,907 WARN akka.remote.transport.netty.NettyTransport - Remote connection to [null] failed with java.net.NoRouteToHostException: No route to host
and the taskmanager could not registered success, and I logged into taskmanager and find out I could success ping jobmanager liket this:
flink#flink-taskmanager-54d85f57c7-nl9cf:~$ ping flink-jobmanager
PING flink-jobmanager.dabai-fat.svc.cluster.local (10.254.58.171) 56(84) bytes of data.
64 bytes from flink-jobmanager.dabai-fat.svc.cluster.local (10.254.58.171): icmp_seq=1 ttl=64 time=0.045 ms
64 bytes from flink-jobmanager.dabai-fat.svc.cluster.local (10.254.58.171): icmp_seq=2 ttl=64 time=0.076 ms
64 bytes from flink-jobmanager.dabai-fat.svc.cluster.local (10.254.58.171): icmp_seq=3 ttl=64 time=0.079 ms
so why this would happen and what should I do to fix it?
Try to install nmap in your kubernetes taskmanger's pod container:
apt-get udpate
apt-get install nmap -y
then scan the jobmanager and make sure the pod's expose port 6123 is accessable(in my case ,I found could not access the port 6123 from current pod).
nmap -T4 <your-jobmanager's-pod-ip>
Hope this help.
I am generating an X509 certificate through code (using OpenSSL APIs) for my server application. I have just added support for TLSv1.3 by adding TLSv1.3 ciphers in the supported list in my code.
There is no change in certificate generation and assigning RSA pub + private key to the certificate.
I have upgraded curl & OpenSSL libraries on client to enable TLSv1.3 connection. Upgraded Curl version: 7.63.0 & OpenSSL version: 1.1.1
I am seeing below error:
* TCP_NODELAY set
* Connected to <domain> (<ip-address>) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: myCA.pem
CApath: none
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [6 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [1781 bytes data]
* TLSv1.3 (OUT), TLS alert, decrypt error (563):
} [2 bytes data]
* error:0407008A:rsa routines:RSA_padding_check_PKCS1_type_1:invalid padding
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
* Closing connection 0
curl: (35) error:0407008A:rsa routines:RSA_padding_check_PKCS1_type_1:invalid padding
Same error comes even with TLSv1.2 (using same upgraded client).
What am I missing here? Please help.
I know this is an old one, but I just had the same issue because I copied a PEM file from Windows with CRLF included instead of LF.
Use cat -v cert.pem to check for it.
I was issuing a self-signed certificate by a self-created CA to use it for web development on localhost and was getting the same error. I tried to create a working SSL certificate multiple times, but always had this error error:0407008A:rsa routines:RSA_padding_check_PKCS1_type_1:invalid padding, and I had multiple certificate authorities with the same CN registered in my operating system's trust source (/etc/ca-certificates/trust-source on manjaro).
How I solved the problem: I deleted all these "duplicates" and ran update-ca-trust to regenerate the list of CAs trusted by my system. Then imported my self-created CA once, generated an SSL certificate against it and used the crt and key in my web server - finally no error:0407008A:rsa routines:RSA_padding_check_PKCS1_type_1:invalid padding when CURLing into it!
I found this thread when searching this invalid padding error. It seems as if there are multiple causes. In my case, I was signing the leaf certificate with its own private key instead of the CA certificate's private key.
curl: (35) error:0407008A:rsa routines:RSA_padding_check_PKCS1_type_1:invalid padding
to avoid you can use the option -k
it works the same as we use postman and in the settings, turn off the SSL certificate verification option
Please find a sample curl and how to use -k option below
curl --location --request POST 'https://sample.ap-south-1.elb.amazonaws.com/v1/messages' --header 'Content-Type: application/json' --header 'Authorization: Bearer xxxxx' --data-raw '{
"to": "91xxx",
"type": "image",
"recipient_type": "individual",
"image": {
"id": "56dxxxx",
"caption": "your-image-caption Saket jain how are you"
}
}' -k
I am using openssl on non-blocking tcp client. I am trying to establish 2 TLS connection, they are different sessions. The first is connected successfully. But there is a strange error for the second when connecting. Here is log for the second connection.
12:03:31.768 TLS: INFO: sess[0x4efdd3c] Handshake: start
12:03:31.768 TLS: INFO: sess[0x4efdd3c] Loop: before/connect initialization
12:03:31.768 TLS: INFO: sess[0x4efdd3c] Loop: SSLv3 write client hello A
12:03:31.768 TLS: INFO: sess[0x4efdd3c] Exit: error in SSLv3 read server hello A
12:03:31.768 TLS: INFO: SessConnect read blocked.
12:03:31.768 UTPT: INFO: tls conn[0x2000d] state read blocked.
12:03:31.768 UTPT: DEBUG: ConnProcTcpWr tls connecting.
12:03:31.782 UTPT: INFO: read tcp conn[0x2000d] of user[0x20008].
12:03:31.782 TLS: INFO: sess[0x4efdd3c] Loop: SSLv3 read server hello A
12:03:31.782 TLS: ERROR: verify error[18:self signed certificate] in depth[0].
12:03:31.782 TLS: INFO: issuer is </O=Self-signed certificate for kamailio/OU=cp/CN=cp.example.com/emailAddress=root#cp.example.com>
12:03:31.782 TLS: INFO: subject is </O=Self-signed certificate for kamailio/OU=cp/CN=cp.example.com/emailAddress=root#cp.example.com>
12:03:31.782 TLS: INFO: sess[0x4efdd3c] Loop: SSLv3 read server certificate A
12:03:31.782 TLS: INFO: sess[0x4efdd3c] Loop: SSLv3 read server done A
12:03:31.782 TLS: INFO: sess[0x4efdd3c] Loop: SSLv3 write client key exchange A
12:03:31.782 TLS: INFO: sess[0x4efdd3c] Loop: SSLv3 write change cipher spec A
12:03:31.782 TLS: INFO: sess[0x4efdd3c] Loop: SSLv3 write finished A
12:03:31.782 TLS: INFO: sess[0x4efdd3c] Loop: SSLv3 flush data
12:03:31.782 TLS: INFO: sess[0x4efdd3c] Exit: error in SSLv3 read finished A
12:03:31.782 TLS: INFO: SessConnect read blocked.
12:03:31.782 UTPT: INFO: tls conn[0x2000d] state read blocked.
12:03:31.782 UTPT: DEBUG: ConnProcTcpRd tls connecting.
12:03:31.814 UTPT: INFO: read tcp conn[0x2000d] of user[0x20008].
12:03:31.814 TLS: INFO: sess[0x4efdd3c] Write: SSLv3 read finished B
12:03:31.814 TLS: INFO: sess[0x4efdd3c] Exit: failed in SSLv3 read finished B
SSL fsm wants to read finished A, but failed on read finished B. Please help me to locate what would cause this happen.
Here is the error string when failed.
error:1408C095:SSL routines:SSL3_GET_FINISHED:digest check failed
I am not sure what does this mean.