I am currently using the activemq-cpp c++ client to connect to the backend server. When using the TCP protocol, it is possible to communicate. I am using the example above at https://activemq.apache.org/components/cms/example. But now I need to use the SSL protocol. My code is as follows:
brokerURI ="failover:(ssl://xxxx:61617)";
auto connectionFactory = new ActiveMQConnectionFactory(brokerURI);
connectionFactory->setUsername(username);
connectionFactory->setPassword(password);
connection = connectionFactory->createConnection();
connection->start();
I got stuck in the start function and didn't throw any exceptions. I don't know why. Could give me a simple c++ ssl code connection demo for me to learn? Thank you.
The [example][1] documents the SSL configuration that you need to do, which is to tell the library where the key store, and trust store (and password) live.
// SSL:
// =========================
// To use SSL you need to specify the location of the trusted Root CA or the
// certificate for the broker you want to connect to. Using the Root CA allows
// you to use failover with multiple servers all using certificates signed by
// the trusted root. If using client authentication you also need to specify
// the location of the client Certificate.
//
// System::setProperty( "decaf.net.ssl.keyStore", "<path>/client.pem" );
// System::setProperty( "decaf.net.ssl.keyStorePassword", "password" );
// System::setProperty( "decaf.net.ssl.trustStore", "<path>/rootCA.pem" );
//
// The you just specify the ssl transport in the URI, for example:
//
// ssl://localhost:61617
//
Related
The google.golang.org/grpc/credentials library has the following method.
// NewClientTLSFromCert constructs TLS credentials from the provided root
// certificate authority certificate(s) to validate server connections. If
// certificates to establish the identity of the client need to be included in
// the credentials (eg: for mTLS), use NewTLS instead, where a complete
// tls.Config can be specified.
// serverNameOverride is for testing only. If set to a non empty string,
// it will override the virtual host name of authority (e.g. :authority header
// field) in requests.
func NewClientTLSFromCert(cp *x509.CertPool, serverNameOverride string) TransportCredentials {
return NewTLS(&tls.Config{ServerName: serverNameOverride, RootCAs: cp})
}
I am confused about how it can generate TLS credentials from a public key (the certificate here).
How will this work? If I generate credentials from a public cert, why would it be accepted on the server side whose TLS cert has been signed with the private key of the TLS CA?
What exactly happens here and how is the connection secured over here?
Transport "credentials" in gRPC are fully responsible for the handshake with the client/server. That means they include configuration other than just "credentials" like private keys and other secrets. For TLS here, it includes the root trust certificates to use when verifying the server's certificate. You can think of it as just "TLS configuration."
When I check the definition of "WebhookClientConfig" of API of Kubernetes I found comments like this:
// `caBundle` is a PEM encoded CA bundle which will be used to validate the webhook's server certificate.
// If unspecified, system trust roots on the apiserver are used.
// +optional
CABundle []byte `json:"caBundle,omitempty" protobuf:"bytes,2,opt,name=caBundle"`
in WebhookClientConfig
I wonder to know, what's exactly the "system trust roots "?
and I'm afraid the internal signer for CSR API of Kubernetes is not one of them.
It is a good practice to use secure network connections. A Webhook-endpoint in Kubernetes is typically an endpoint in a private network. A custom private CABundle can be used to generate the TLS certificate to achieve a secure connection within the cluster. See e.g. contacting the webhook.
Webhooks can either be called via a URL or a service reference, and can optionally include a custom CA bundle to use to verify the TLS connection.
This CABundle is optional. See also service reference for how to connect.
If the webhook is running within the cluster, then you should use service instead of url. The service namespace and name are required. The port is optional and defaults to 443. The path is optional and defaults to "/".
Here is an example of a mutating webhook configured to call a service on port "1234" at the subpath "/my-path", and to verify the TLS connection against the ServerName my-service-name.my-service-namespace.svc using a custom CA bundle
I'm following https://getakka.net/articles/remoting/security.html documentation to implement TLS Secured communication using an Akka.Net cluster.
I have generated a self-signed certificate using IIS and imported the certoficate TheCertifcate.pfx to Local Computer/Trusted Root Certification Authorities. The certificate is listed there now.
I need to know how to use the certificate path
remote {
dot-netty.tcp {
hostname = "localhost"
port = XXXX
enable-ssl = true
log-transport = true
ssl {
suppress-validation = true
certificate {
# valid ssl certificate must be installed on both hosts
path = "C:\\Workspace\\CertficateUtils\\TheCertificate.pfx"
password = "thepassword"
}
}
}
}
What am I supposed to use in path?
Short answer The path will be just like above.
Long answer The path is the physical folder path where you save the self-signed certificate. In my case "C:\\Workspace\\CertficateUtils\\TheCertificate.pfx". You need to import this certificate to Local Computer/ Trusted Root Certification Authorities though.
But the above configuration is NOT ENOUGH to make an Akka.NET Actor System communicate with SSL encryption.
We need to specify the transport protocol as ssl where we specify actor node addresses.
That is in the hocon configurations or in code where we use any node adress like
"akka.tcp://lighthouse#127.0.0.1:port", "akka.tcp://RemoteSystem#127.0.0.1:port"
need to be updated to
"akka.ssl.tcp://lighthouse#127.0.0.1:port", "akka.ssl.tcp://RemoteSystem#127.0.0.1:port"
where akka.ssl.tcp is the transport protocol.
I have a remote server which may or may not be running using a valid SSL cert (using self-signed SSL cert).
We are making connection to remote server, which may fail if remote server is using self-signed SSL cert. So, we want to be able to download/view the remote server cert if our SSL handshake fails.
If I use Apache HTTP Client then I couldn't find a method which could allow me to view remote server certificate (you can do it with HttpsURLConnection but we are trying to avoid using it see this example).
I also looked into Spring RestTemplate, and it didn't provide any option either - I searched on Google and didn't find anything around Spring or Apache HTTP Client.
This should give you pretty much a complete control over the process of trust verification.
SSLContext sslContext = SSLContextBuilder.create()
.loadTrustMaterial((chain, authType) -> {
for (X509Certificate cert: chain) {
System.out.println(cert.getSubjectDN());
}
// Let the standard trust managers decide
// whether or not the cert chain is trusted
return false;
})
.build();
CloseableHttpClient client = HttpClientBuilder.create()
.setSSLContext(sslContext)
.build();
I am trying to use websocket to connect to a TLS server using react-native. Below is my code (running on windows + android ):
var ws = new WebSocket('wss://hub.fingi-staging.com:20020',{
rejectUnauthorized: false
});
ws.onopen = () => {
// connection opened
ws.send('something'); // send a message
};
ws.onmessage = (e) => {
// a message was received
console.log('message : ' + e.data);
};
ws.onerror = (e) => {
// an error occurred
console.log('error:'+e.message);
};
ws.onclose = (e) => {
// connection closed
console.log('close:'+e.code, e.reason);
};
However, it fails with : error:java.security.cert.CertPathValidatorException: Trust anchor for certification path not found. This is because the server uses a self signed certificate.
Is there any way to fix this?
Replying a bit late, but hopefully this can point other people in the right direction.
I believe the error you are getting suggests you are missing the certificate chain file, which is used to verify if the CA used to sign your server's certificate is valid, i.e if the chain of trust is valid.
This, however, usually fails (is troublesome, at least) if you are working with self signed certificates. You can take a look here if you need some help generating some self-signed certificates and the appropriate certificate chain. Also, see if you need to specify the trusted CA's by having the client use that file as a parameter when connecting.
I have been struggling with setting up a secure websocket server using a self sign certificate (for development purposes, in production a proper certificate/CA must be used) but haven't had much success and reverted back to using non-TLS websocket server.
If anyone else happens to be struggling with implementing secure websocket connections in React-Native, here is what I found tonight: React-Native wants to use port 443 when working with secure websocket connections.
Let's take the original poster above's code. He has:
var ws = new WebSocket('wss://hub.fingi-staging.com:20020',{
rejectUnauthorized: false
});
What I've found that works for me is:
var ws = new WebSocket('wss://hub.fingi-staging.com');
And then on your WebSocket server, make sure you are serving everything up on port 443, and not port 20020 (or whatever port you happened to be using previously). For example, my Python websocket server was previously using port 8765. However, in React-Native you need to be using port 443 for secure websocket connections or things simply aren't going to work.