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.
Related
I generated a self-signed PKCS-12 certificate with keytool(java sdk) for the API which is built in java Spring. Then, I imported the same certificate in Chrome certificates, but I don't understand why when I run my application is not using the certificate. It seems to generate a localhost certificate of its own. This is my vue.config.js:
let fs = require('fs')
module.exports = {
devServer: {
host: "localhost",
port: "8081",
https: {
ca: fs.readFileSync('C:\\Projects\\LicentiaUtilities\\books.p12')
},
}
}
Is the PKCS12 format not supported? Should I convert into something else?
Your certificate won't work on localhost, all certificates work only with domain names.
There is no way to issue SSL certificate for an IP address or localhost; you have to have an actual name which you create the certificate for. In order to get such a name, you need a DNS. Since you don't have access to the internal DNS of that local network, you will have to use a public DNS server for this.
If you will publish your app, I'll recommend you nginx, it's super easy to add ssl cert, and make a reverse-proxy to your NodeJS instance.
I have a Mosca MQTT broker running on a node instance and I would like to encrypt all the incoming communications with SSL/TLS (MQTTs protocol) but without the client having to link any certificate to the connexion (I guess it has to do with self-signed certificates) just as https works. I want all my clients to connect just with credentials specifying the MQTTs protocol and the communication can be encrypted. I was using Amazon MQ just before and that's how it works so I want the same.
I can't figure how to configure properly Mosca to do so, I don't know what kind of certificate I must use.
I added the secure field in the configuration as shown here
For the certificate I tried to create a self signed certificate as shown here
I also tried with certbot certificates (Let's Encrypt) registered for my domain name : mq.xxx.com .
I'm running everything on a ec2 (ubuntu 18) and my network and firewall are open for 1883 and 8883. My key and cert are at the root of my project where the deamon is running with good rights and ownership. I know my instance access them correctly.
new mosca.Server({
port: 1883,
secure: {
keyPath: "./privkey.pem",
certPath: "./cert.pem"
},
backend: {
type: 'redis',
redis: require('redis'),
host: "localhost",
port: 6379,
db: 0,
return_buffers: true,
},
persistence: {
factory: mosca.persistence.Redis
}
});
My server is running and working with simple mqtt on port 1883 but when I try to connect with ssl/tls with a client on port 8883 specifying that the server uses self-signed certificates (I tried with MQTT.fx) it fails saying : "unable to find valid certification path to requested target".
I can't make my head around this issue, I think somehow the client cannot "accept" or "verify" the certificate provided. Maybe I'm providing the wrong key or certificate to Mosca but there is only one of each resulting openssl or certbot. Maybe I created wrong but I follow many tutorials on the very same subject such as this one
What kind of certificate do I need to do ?
Is there something more to do with them ?
Thank you.
If you are using a self created certificate then the client will need a copy of certificate that signed the broker's certificate. This certificate will be added to the list of trusted sources so it can prove the broker is who it claims to be.
If you do not want to / can not distribute a certificate then you will need to use a certificate for your broker that is issued by CA (Certificate Authority) whoes signing certificate you already have (bundled into the OS/client that you are using).
The Lets Encrypt signing certificates should be bundled into most OSes by now but they are also cross signed by IdenTrust again who's certs should be bundled with most OSes. If you are having problems with the Lets Encrypt certs then I suggest you ask a new question with the exact details of how you configured mosca with those certs and more details of how you are configuring MQTT.fx and the errors you receive.
Configure Apache and F5 loadbalancer.
From Apache layer we generate CSR and get the trusted cer as:
1) .cer
2) .p7b
Then I convert the .cer and .p7b file to .crt file and configure in our apache as keyfile, certificate and chain.
We are facing some issue while configuring the SSL between F5 and Apache. Our flow is:
Client(SSL) -> F5 (SSL drops ) -> (recreate ssl to apache layer) -> Apache webserver.
1) create CSR from apache web layer, get sign as trusted from the company (not external)
2) configure in ssl.conf and ciphersuite
Now initiate a request using openssl it is throwing:
depth = 1
DC = net
DC = racb
CN = XXXXXX
CA 1 verify error:num=20:unable to get local issuer certificate read from 0x1b9c8d0 [0x1ca04f3] (5 bytes => 5 (0x5))
In order to verify it I modified the /etc/hosts entry as xxx.xxx.xxx.net as 127.0.0.1 and move the chain certificate to /etc/pki/ca-trust/source/anchor and update-ca-trust extract and run the openssl which is return with error code=0 and waiting in SSL session.
What mistake we are doing in F5 no idea.
Can someone throw the lights?
If you're setting up a bridging config, you need both an SSL Client Profile (typically you take your Apache key/cert/chain) and an SSL Server Profile, and both are chosen on the Virtual Server configuration.
For the Client Profile you first need to import the private key, the certificate(s) and of course you have to see on the Certificates screen that the private key matches the certificate.
Usually for the Server Profile, if we know that we can trust the backend server, instead of setting up something with certificates of your own, we just choose the unsecure-compatible profile and it will work in almost all cases.
If there is no need to setup SNI, it's enough to make it work.
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 create an HTTPS-tunnel on my machine. My intention is having all requests to https://localhost:8888/<something> (the port where Fiddler is listening to) be directed to https://myserver.net/<something>. I am using the following script as per Fiddler doc:
static function OnBeforeRequest(oSession: Session) {
// <Fiddler 2 preexisting code>
// HTTPS redirect -----------------------
if (oSession.HTTPMethodIs("CONNECT") &&
(oSession.PathAndQuery == "localhost:8888"))
{
oSession.PathAndQuery = "myserver.net:443";
}
if (oSession.HostnameIs("localhost"))
oSession.hostname = "myserver.net";
// --------------------------------------
// <Fiddler 2 preexisting code>
}
Also in Fiddler settings I checked the decryption check and installed certificates as you can see in the image below:
I restart Fiddler, it prompts me to install its fake certificates, I agree. I can see the certificate in my Windows Certificate System Repository when using certmgr. It is a self-signed certificate.
So What I do is opening a browser and type: https://localhost:8888/mypage.html, and what I get is an error. Internet Explorer reports this:
Error: Mismatched Address. The security certificate presented by this
website was issued for a different website's address. This problem
might indicate an attempt to fool you or intercept any data...
When I get certificate info (basically the certificate presented by the contacted host is being rejected, the same certificate can be displayed), I can see that the rejected certificate was issued by Fiddler and the subject is myserver.net.
So the certificate is ok because it is certifying myserver.net, I see that the problem is that probably my browser was expecting a certificate whose subject is localhost. Is it true?
How to handle this situation?
Assumption
I can understand that the problem is a certificate being issued for a website which I did not ask for. So the solution would be using a certificate certifying localhost:8888?
A certificate is valid if it is directly or indirectly (via intermediate certificates) signed by a trusted CA and if the hostname matches the certificate. If the last condition would not be enforced anybody with a valid certificate from a trusted CA could incorporate any other site.
To make use of fiddler and not run into this problem you should configure your browser to use fiddler as a web proxy and then use the real URL inside the browser instead of ip:port of fiddler.