I am trying to setup a remote VPN bridge to a partner router and get this error in connection: Local SSL handshake failed: Server certificate verification failed: self signed certificate in certificate chain.
I have added the cert to the local Solace router as well as added the names to the trusted names list but still not working.
What am I missing here?
This means that you have not installed the public cert of the root issuer of the remote Solace broker server cert.
In general, the trust chain of a SSL cert needs to be established. For example, if the entire of the server cert is like this:
Root > Root > Intermediate1 > Intermediate2 > Server
where > denotes "issue", and the server cert installed on the remote server (in this case a Solace broker) only has this:
Intermediate2 > Server
i.e., it contains the public certs of Intermediate2 AND Server.
Then, the client (in this case the local Solace broker) needs to be able to verify the rest of the chain:
Root
Intermediate1
This is typically known as ca-bundle in most environments. "CA" stands for Certificate Authority. Unlike other OS or browsers, Solace broker does not have any defaults installed. You'll have to install those certs / certificate authorities as per steps done in https://docs.solace.com/Configuring-and-Managing/Managing-Certificate-Authorities.htm.
Related
Does Azure IoT Edge works with Zscaler proxy AND SSL inspection
Indeed, we need to check header information from IoT Edge for security reason which require to decrypt .
IoT Edge run in CentOS or Ubuntu ESX VM and Zscaler certificat can be uploaded in the OS file system
regards
You will need the Zscaler root certificate added to list of root certificates that are trusted by OpenSSL in both the edgeAgent and edgeHub modules. Without that the TLS negotiation will fail with not trusting the certificate chain from any server that they attempt to negotiation a TLS connection with. I have done this. It will work.
I'm trying to run neo4j community on a vps via a docker image managed with plesk.
I am however having issues configuring the SSL certificate so I can connect to it securely from nodejs.
Currently, the error I'm getting is quite straightforward in node:
Neo4jError: Failed to connect to server.
Please ensure that your database is listening on the correct host and port and that you have
compatible encryption settings both on Neo4j server and driver. Note that the default encryption
setting has changed in Neo4j 4.0. Caused by: Server certificate is not trusted. If you trust the
database you are connecting to, use TRUST_CUSTOM_CA_SIGNED_CERTIFICATES and add the signing
certificate, or the server certificate, to the list of certificates trusted by this driver using
`neo4j.driver(.., { trustedCertificates:['path/to/certificate.crt']}). This is a security measure
to protect against man-in-the-middle attacks. If you are just trying Neo4j out and are not
concerned about encryption, simply disable it using `encrypted="ENCRYPTION_OFF"` in the driver
options. Socket responded with: DEPTH_ZERO_SELF_SIGNED_CERT
I've mapped the volumes as follows:
/certificates to the letsencrypt live folder for the domain db.example.com
Then I'm trying to connect to it via: bolt://db.example.com:32771
When i check via browser, the certificate being served is self-signed. I have try to add this certificate to the trusted certificates in windows but it didn't do anything at all.
Also added the path to the trusted certificates when instantiating the driver:
this._driver = neo4j.driver(process.env.Neo4jUri, token, {
encrypted: true,
trustedCertificates: ['ssl/neo4j.crt'],
});
I've also tried to copy the files within that certificate folder so that the appropriate files are named as mentioned in this article.
I'm trying to enroll an intermediate certificate authority with its root certificate authority, I'm using TLS and the CAs run in separated docker containers using the fabric-ca images. If I send the CSR trough the docker network there are no problems, but if I try to send it trough my local network I have this problem: x509: cannot validate certificate for "HOST_IP" because it doesn't contain any IP SANs. I read that the reason for my problem, is that the TLS certificate(s) don't contain IP SANs (IP subject alternative names), this is a field in the TLS certificate that basically says: "The certificate was issued to a host that its IP is: <1.2.3.4>". So, if that is the problem, how I could add this field to my certificate? and if not, what is the problem and how I could resolve it? Thanks and regards!
You can follow the explanation given here with a similar IP SANS issue. There is also detailed explanation of IP SANS issue in HLF mailing List. Also make sure when you are using Fabric CA Client, to generate the certificates, use the server's hostname to request the same. for e.g. fabric-ca-client enroll -d --enrollment.profile tls -c <client configuration file> -u https://admin:adminpw#<server hostname>:7054 --csr.hosts $PEER_HOST. If IP address is given in URL TLS handshake will fail with bad TLS certificate error on the server side and 'certificate does not contain IP SANS' error on the client side as the ca-cert.pem used to perform the handshake with the server contains hostname and not the IP address.
I am running into a strange error in my iOS client when attempting to connect to an f5 BigIP server via 2-way SSL (HTTPS) - the client is able to verify the server via its certificate only when the server is not requiring a client certificate during the SSL negotiation. The certificate for the Root CA that signed the server and my client certificates is already in my trusted anchor certs list.
Here are the steps in each test that I have attempted, and their SSL negotiation outcomes:
Server does NOT require client cert, client verifies server cert (1-way ssl: client -> server)
Client verifies server certificate (pass)
Client provides its cert to server (unchecked - not required by server)
Connection established, server allows client access
Server requires client cert, client verifies server cert (2-way SSL: client <-> server)
Client verifies server cert (FAIL!!)
Nothing else happens
Server requires client cert, client accepts any server as trusted (1-way SSL: client <- server)
Client does NOT verify server cert (setAllowsAnyHTTPSCertificate:YES - done for testing purposes only)
Client provides its cert to server (pass)
Connection established, server allows client access
Between cases 1 and 2, only the server is changed to require client certs (thereby enabling 2-way SSL), while the client verifies the server cert in both cases. Between cases 2 and 3, the client is changed to accept all server certs while the server requires a client certificate in both cases.
So it appears that I am only able to achieve 1-way SSL in either direction but not 2-way SSL. This is strange because as the initial step where the client verifies the server should happen before the server asks for a client certificate, and therefore produce the same result each time. The error I get from test case 2 is as follows:
The certificate for this server is invalid. You might be connecting to
a server that is pretending to be “server.myexample.com” which could
put your confidential information at risk. Error occurred while
fetching https://server.myexample.com/service: Error
Domain=NSURLErrorDomain Code=-1202 "The certificate for this server is
invalid. You might be connecting to a server that is pretending to be
“server.myexample.com” which could put your confidential information
at risk.
I get additional messages with the same info but specifying the errors: NSErrorFailingURLStringKey, NSErrorFailingURLKey, NSUnderlyingError, and NSURLErrorFailingURLPeerTrustErrorKey.
I don't believe I need a different server certificate for 2-way vs 1-way SSL, or do I?
Thanks in advance!
The problem was that I had the client request in an iRule on the f5 server. I removed this part of the iRule and added the request into the client SSL profile. This appears to work with the iOS client, meaning there is probably something strange with the iOS code since all browsers I have tested work either way I make the request (either iRule or client SSL profile). The iOS app only works with making the request in the client SSL profile.
I was using iOS to connect to a server using a certificate whose CN (commonname) and FQDN (fully qualified domain name) is server.myexample.com. The server certificate was signed by my own Root CA (whose certificate I added to my anchor certs via SecTrustSetAnchorCertificates and verified via the method described here using NSURLAuthenticationChallenge).
With my iOS client, I was attempting to connect my REST service located at: server.myexample.com/Path1/service1, but I kept receiving the following error:
The certificate for this server is invalid. You might be connecting to a server
that is pretending to be “server.myexample.com” which could put your confidential
information at risk.
Error occurred while fetching https://server.myexample.com/Path1/service1: Error
Domain=NSURLErrorDomain Code=-1202 "The certificate for this server is invalid.
You might be connecting to a server that is pretending to be “server.myexample.com”
which could put your confidential information at risk."
I get additional messages with the same info but specifying the errors: NSErrorFailingURLStringKey and NSURLErrorFailingURLPeerTrustErrorKey.
I found that I could also call the service with server.myexample.com/service1 and removed Path1 from my request URL, and the server certificate verification worked correctly. Why is this? I was under the impression that the server only needed 1 certificate, meaning any services it hosts would also be using that same certificate. Maybe you need a separate server certificate per path? I was not aware the paths after the server ip address/domain needed to have their own certificate.
To summarize:
iOS client app with Root CA certificate in the anchor certs
Server server1's certificate signed by Root CA has a CN of server.myexample.com and whose FQDN is https://server.myexample.com.
Server server.myexample.com hosts service1 which can be accessed by web browser via:
https://server.myexample.com/service1 (passes iOS client's authentication of server)
https://server.myexample.com/Path1/service1 (FAILS iOS client's authentication of server)
CA and server certificates were created via OpenSSL
Thanks in advance!