I am using a SIM7070G from SIMCOM.
I am currently trying to implement TLS protection over a MQTT communication.
I do create the file that I need that contain the CA certificate of mosquitto and I check that it does exist with a AT+CFSGFIS command but when I want to convert it with the AT+CSSLCFG="CONVERT",2,CA.crt command I got a CME ERROR: operation not allowed.
The configuration I use is :
TLS1.2
ignore RTC time
cypher suite 1 : QAPI_NET_TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
cypher suite 2 : QAPI_NET_TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
I have no clue why it doesn't work and did some research but I didn't find anywhere such an error. I checked that I didn't miswrite the commands but it seems that I didn't.
Related
when trying to load a q instance with TLS support with 'q -E 1 -p 65000' on linux I get
failed to load TLS certificates
This command works fine in several other boxes. I suspect either something wrong with this specific certificate generation or missing root certificates (possibly being on different paths for this box?). Is there any source of additional logging or debugging info I could use to pinpoint the exact problem? Thanks,
filimon
I am struggling with this issue for a few days, I am trying to connect my db from Robo 3t and Studio 3t, but i got same error with both programs:
Note: I can access by ssh from my terminal, it means that the certificate is fine, the EC2 endpoint is fine, port etc... then the problem should be in another place, right?
SSH Tunnel error: I/O error: Not ASN.1 data
Stacktrace:
|/ SSH Tunnel error: I/O error: Not ASN.1 data
|___/ I/O error: Not ASN.1 data
But I as i said before, I can connect by ssh without any issue:
ssh -i "cert.pem" ec2-muyser#ec2-54-244-36-226.us-west-2.compute.amazonaws.com
I checked all the steps described in the AWS article below, an I also disabled TLS in the cluster param, as suggested in point 5, but I still having the issue.
https://aws.amazon.com/es/premiumsupport/knowledge-center/documentdb-cannot-connect/
I just edit the post to add a few screenshot from my Robo 3t config:
Regards.
I verified the same steps. I am able to connect successfully .
Looks like you are on macOS and you didn't select Self-signed Certificate as recommended in documentation -
https://docs.aws.amazon.com/documentdb/latest/developerguide/robo3t.html
These are two additional settings which you require to do on macOS.
i) If you are on Linux/macOS client machine, you might have to change the permissions of your private key using the following command:
chmod 400 /fullPathToYourPemFile/.pem
ii) if you are on macOS Catalina or above, choose Self-signed Certificate as the Authentication Method because the macOS does not accept certificates with validity greater than 825 days.
I am using kafka version 2.12-2.2.1 in windows operating system. I have implemented tls on my local windows systems using the process of signed certificates.
The kafka is running fine and there is one command to check if certificates are installed on kafka.
openssl s_client -debug -connect localhost:9093 -tls1
But when I try to connect to localhost:9093 and using producer or consumer it is throwing me an error saying :
connection to node -1 failed due to authentication
I have tried everything, I am stuck even the documentation provided is not giving any hints to solve this error.
Note: One more addition how can I see the list of topics and describe the topic if exits using ssl in kafka because that command is also not working.
Along with that I have tried every answer on SO but still no success.
The documentation I have followed Installing ssl on kafka
I have two servers with a very similar installation. One on Debian 8.7, the other on Debian 8.8.
On the first server, when I try to subscribe to a MQTT topic over SSL:
mosquitto_sub -h localhost -t test -p 8883 --cafile /etc/mosquitto/certs/selfsigned.pem -d
I get this clear message which seems to come from OpenSSL (I already know the reason of the error, it is not the goal of my question) :
Client mosqsub/9647-CIEYY2T7 sending CONNECT
OpenSSL Error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Error: Protocol error
On the other server, for the exact same command, I get only this obscure message without the OpenSSL explanation:
Unable to connect (8).
I have two questions:
Why am I getting "Unable to connect (8)" on the second server?
How can I make OpenSSL more verbose ?
See here for the answer (where I've been told to go post the question on SO) :
https://security.stackexchange.com/questions/159177/how-to-make-openssl-errors-more-verbose-for-mqtt-client
And for the rules nazis trying to close this useful question/answer :
if your question generally covers (...) software tools commonly used
by programmers (...) then you’re in the right place to ask your
question!
source : https://stackoverflow.com/help/on-topic
And yes, mosquitto_sub and mosquitto_pub are tools commonly used by programmers, because if u are trying to setup a SSL MQTT connection directly with java code and bouncy castle without testing the exchange with simpler tools, you are probably doing it wrong.
I am attempting to make a secure call between two virtual machines using pjsua program from pjsip installation. I start the program on each node via :
pjsua-x86_64-unknown-linux-gnu --use-tls
I then enter m to make call and submit : sip:xxx.xxx.xx.x:5061;transport=TLS
On the receiving side I see :
Handshake failed in accepting xxx.xxx.xx.x:58392: no shared cipher
On the dialing side I am seeing :
Failed to send Request msg INVITE/cseq=17559 (tdta0x1ab89e0)! err=495040 (sslv3 alert handshake failure)
Can anyone help me to understand why this is happening?
Looks like there is a mismatch between the cipher configuration of the server(receiving side in your case) and client (dialing side in your case).
The error no shared cipher (alert 40) says that there is not at least any one of the cipher used by client available at the server side
You need to look into the call for SSL_CTX_set_cipher_list (If you are using OpenSSL) API on both the ends.
Try to configure the common cihpers on both client and server machines.
Some times you may get the same error (no chared cipher) for unavailability of the cipher which is used by public certificates. better verify the first step then verify your certificate algorithm.
I too had faced the similar problem for my client server configuration.
here is a reference:
"no shared cipher" error with python and OpenSSL