Well, I'm working with Openwisp and when I tried to register a device (router), I got this error.
Error
This is the configuration on the router
Config
Any idea what I might be doing wrong?
CURLE_PEER_FAILED_VERIFICATION (60)
The remote server's SSL certificate or SSH md5 fingerprint was deemed
not OK. This error code has been unified with CURLE_SSL_CACERT since
7.62.0. Its previous value was 51.
If you're in development/testing mode, you can disable SSL verification in openwisp-config by modifying /etc/config/openwisp and setting verify_ssl to 0.
In production you will have to make sure the SSL certificate of the server is valid.
Related
I am creating a Linked Service to connect to BigQuery with Service Account authentication and p12 file has already been placed in IR VM directory.
Receiving following error:
ERROR [HY000] [Microsoft][DriverSupport] (1160) Cannot enable SSL for the connection when connecting to a server that has not enabled SSL. If the server has SSL enabled, please check if it has been configured to use a SSL protocol version that is lower than what is allowed for the connection. The minimum SSL protocol version allowed for the connection is: TLS 1.2.
But when i place p12 file in another IR VM, linked service is working correctly.
Tried to check TLS version in both VM's and everything looks same.
Please suggest ways to check SSL and TLS version in VM's and how to resolve this issue.
Based on the error message it seems the issue might be w.r.t SSL certificate so 1st step would be to compare the SSL/TLS across both the servers
In case if they are same, would suggest to monitor the traffic across both the server when trying to access GCP Big Query.
You might get the exact cause of failure which can be like :
Firewall blockage
some missing set up like Big query need Google_base set up as a signature
etc.
You could create a PowerShell script that checks the TLS & SSL registry entries mentioned in the following documentation:
https://learn.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings
Even if after enabling TLS/SSL settings the same issue arises then please try re-installing IR in the VM
Verified AZ pg require_secure_transport = "on"
Without any ssl and no SET PGSSLMODE=require, following command in Windows' cmd succeeded:
pg_restore --format=custom -d "port=5432 host=mypg.postgres.database.azure.com user=myuser dbname=mydb" my.dump
Checking AZ's Log Analytics workspace shows
connection authorized: user=myuser database=mydb
application_name=pg_restore SSL enabled (protocol=TLSv1.3,
cipher=TLS_AES_256_GCM_SHA384, bits=256, compression=off)
So how does this SSL/Secure established or it's enabled but operation isn't on SSL channel?
pg_restore is based on libpq, and follows its conventions in this area. An unset sslmode has the default behavior of 'prefer'. It first attempts to set up an SSL connection, then tries without SSL only if that first attempt fails. So 'prefer' is identical to 'require' provided the first attempt does succeed. If you want to prove that your servers setting require_secure_transport = "on" is doing something, you should try setting sslmode=disable on the client. Then you should see a failure driven by that mismatch between client and server.
In your comment you mention sslcert and sslkey. Those are used only for client certificate authentication. This is optional, unusual, and as far as I know is not even supported by Azure's hosted PostgreSQL. SSL is generally done only with a server certificate, not with a client certificate (for example, pretty much all of the web over https uses server certs only, it isn't just PostgreSQL).
By what is unusual about libpq (in the world of SSL) is that by default, the server's cert does not need to be verified. By default, the cert is just used as a way to negotiate Diffie-Hellman-like key exchange that protects you from eavesdropping but not from impersonation. If you want to verify that the server you connect to is the right one, you would need to set sslmode=verify-full, as well as configure sslrootcert. This is all controlled by the client. While the server can insist that the client use SSL, it has no way to insist that the client actually verify the server's certificate.
I am trying to split up my Network traffic into two streams using Mitmproxy.
I therefore have one incoming proxy that accepts traffic from my IPhone and I am using two secondary Proxies to which the Traffic is forwarded. I start the three instances like this:
mitmproxy --mode upstream 127.0.0.1:8083 -s mitmRoot.py --ssl-insecure
mitmproxy --listen-port 8083 --ssl-insecure
mitmproxy --listen-port 8082 --ssl-insecure
I am using the following, very simple Python script to route the traffic:
class mitmRoot:
def request(self, flow: mitmproxy.http.HTTPFlow):
if "github.com" in str(flow.request.url):
flow.live.change_upstream_proxy_server(("localhost", 8082))
addons = [
mitmRoot()
]
Now everything works perfectly fine if I am using only one proxy without any upstream Proxy. I have installed the certificate on the Phone and I can open any website in the browser
However if I add the two upstream proxies I see start seeing certification errors,
mostly for IPhone related stuff:
clientdisconnect
clientconnect
Certificate verification error for gateway.icloud.com: self signed certificate in certificate chain (errno: 19, depth: 1)
Ignoring server verification error, continuing with connection
Client Handshake failed. The client may not trust the proxy's certificate for gateway.icloud.com.
Interestingly I can still establish connections to websites except the ones where I am switching the upstream server. So in this example I am not able to open github.com.
The input proxy now throws cert errors for github.com as well, while the upstream proxy that should be getting the traffic (the one on port 8082) does not see any traffic at all I also see some clientconnect/ clientdisconnect messages in the stream:
https://github.com/
clientconnect
clientconnect
Certificate verification error for github.com: self signed certificate in certificate chain (errno: 19, depth: 1)
Ignoring server verification error, continuing with connection
Certificate verification error for keyvalueservice.icloud.com: self signed certificate in certificate chain (errno: 19, depth: 1)
Ignoring server verification error, continuing with connection
Client Handshake failed. The client may not trust the proxy's certificate for keyvalueservice.icloud.com
I have tried different configuration options, for "--set add_upstream_certs_to_client=true" but so far I am not able to set this up right.
It seems like there is some kind of configuration issue but I don't yet see why it is happening.
Thank You for your help!
So I set up a mail server on my VPS with cyberpanel and I can send emails manually through rainloop. I also have a program based on the lettre crate for Rust which runs perfectly fine on my own devices and correctly sends emails out through code. However when I try to run the program on my VPS, I get the following messages in my syslog.
globalfun postfix/smtps/smtpd[24656]: connect from localhost[::1]
globalfun postfix/smtps/smtpd[24656]: SSL_accept error from localhost[::1]: -1
globalfun postfix/smtps/smtpd[24656]: warning TLS library problem: error 14094418:SSL routines:ssl3_resl3_read_bytes: tlsv1 alert unknown ca:../ssl/rec/layer_s3.c:1543:SSL alert number 48:
globalfun postfix/smtps/smtpd[24656]: lost connection after CONNECT from localhost[::1]
globalfun postfix/smtps/smtpd[24656]: disconnect from localhost[::1] commands=0/0
I don't really understand why I can't send out emails through my program but it seems to have something to do with SSL. For reference, I have two servers on the same domain - one for my website which has an SSL installed through Let's Encrypt and another for the mail server which doesn't have SSL on it. That said, I don't think that's the issue as I can send emails through the mail server manually completely fine. Does anyone have any ideas as to what's wrong? Thanks in advance.
globalfun postfix/smtps/smtpd[24656]: warning TLS library problem: error 14094418:SSL routines:ssl3_resl3_read_bytes: tlsv1 alert unknown ca:../ssl/rec/layer_s3.c:1543:SSL alert number 48:
Your client refuses to connect to your mail server since it does not trust the CA which issued the mail servers certificate. It notifies the server about this problem by sending a unknown ca TLS alert.
There can be various reasons for this. Typically it is either the use of a CA which is not trusted by the client which need to be fixed at the client (trust this CA) or at the server (use a certificate from a CA trusted by the client). Or the root CA is actually trusted but the server is not sending the intermediate certificates needed by the client to build the trust chain to this trusted root CA. This need to be fixed at the server.
I have encountered the below error while executing the pub.client:soapHTTP service that is available in WmPublic.
java.io.IOException: said.security.ssl.SSLException: Peer sent alert: Alert Fatal: handshake failure
On further investigation, I found that TLSv1.2 is being used by the partner server and I believe wM 6.5 only supports TLS v1.0. This might be a TLS version issue.
I am using webMethods 6.5.
Trusted Certificates > CA Certificate Directory is unspecified and watt.security.cert.wmChainVerifier.trustByDefault is set as TRUE for my server. Therefore, all CAs should be trusted.
Is there any way to make this work as upgrading wM is not an option, unfortunately?
I found this page (link PFB) where there is a section called TLS/SSL Handshake Issues & Debugging. There my handshake issue is mentioned and as a solution, it said:
handshake failed as Integration Server using Entrust IAIK connects to a TLS 1.2 enabled server. In this case, change from IAIK to JSSE option and set "watt.net.jsse.client.enabledProtocols=TLSv1.2"
I tried the above way but it did not work and yes, I restarted the server after changing the configuration.
Moreover, it also stated that
For outbound SSL connection (i.e. Integration Server is acting as SSL client), the following watt properties control the protocol version and ciphersuites:
IAIK:watt.net.ssl.client.handshake.minVersion,watt.net.ssl.client.handshake.maxVersion, watt.net.ssl.client.strongcipheronly,watt.net.ssl.client.cipherSuiteList
JSSE:watt.net.jsse.client.enabledProtocols,watt.net.jsse.client.enabledCipherSuiteList.
But I don't have any of those parameters configured in server.cnf and even if I had to I don't know what values I should configure them with. I'd like some help with those if it'll help with the situation.
https://techcommunity.softwareag.com/pwiki/-/wiki/Main/Debugging%20TLS%20SSL%20connections%20in%20Integration%20Server
try to set in extended settings
watt.net.ssl.client.useJSSE=true
i dont know the old version but it could be that the useJsse parameter that normally is set on the .http and .soapClient service is just taken from the default properties