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.
Related
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 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.
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'm struggling with the Meteor mupx ssl configuration as I can't reconcile it with the files provided by my ssl provider:
{
"ssl": {
"certificate": "./bundle.crt", // this is a bundle of certificates
"key": "./private.key", // this is the private key of the certificate
"port": 443 // 443 is the default value and it's the standard HTTPS port
}
According to my provider I have:
Signed Certificate (PEM Format) (Most web/mail servers)
Bundle Certificate (Intermediate)
Root Certificate (CA)
I've tried various combinations of these files without success. How do I build the bundle.crt from these files?
For future reference the solution was to concatenate all three in the order given above - but to ensure the begin and end file lines between the files were on separate lines. When you use the cat command they can end up on the same line.
I am working on yeoman based angular.js app.
We have set up the gruntfile to run over https.
It works fine on my workmates machine but not on mine.
In Chrome I get:
SSL connection error.
Unable to make a secure connection to the server.
This may be a problem with the server, or it may be requiring a client authentication certificate that you don't have.
In Firefox I get:
The connection was interrupted
The connection to localhost:9000 was interrupted while the page was loading.
The site could be temporarily unavailable or too busy. Try again in a few moments.
If you are unable to load any pages, check your computer's network connection.
If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the Web.
I have double checked we have the same npm modules installed.
Relevant parts of gruntfile are
connect: {
options: {
port: 9000,
hostname: 'localhost',
protocol: 'https',
key: grunt.file.read('server.key').toString(),
cert: grunt.file.read('server.crt').toString(),
ca: grunt.file.read('ca.crt').toString(),
passphrase: 'grunt',
},
livereload: {
options: {
protocol: 'https',
middleware: function (connect) {
return [
modRewrite([
'^/api/(.*) /api/index.php?$1 [L]',
'!\\.html|\\.js|\\.php|\\.css|\\.png$ /index.html [L]'
]),
lrSnippet,
phpGateway('app'),
mountFolder(connect, '.tmp'),
mountFolder(connect, yeomanConfig.app)
];
}
}
},
my workmate generated the certificate files, but that shouldn't matter as I have exact copies of those files.
The strangest part is that I can still run the site over http where on my workmates machine it won't run over http at all, only https.
Is there anything else anyone can think of as to why this would be?
Based on the error "This may be a problem with the server, or it may be requiring a client authentication certificate that you don't have" and the fact that it runs on your friend's computer but not yours leads me to believe that it's a problem with the SSL keys and certificate on your computer. You can generate your own using the tutorial here: http://www.akadia.com/services/ssh_test_certificate.html
key: grunt.file.read('server.key').toString(),
cert: grunt.file.read('server.crt').toString(),
ca: grunt.file.read('ca.crt').toString()
Make sure that the above files are in your base folder from which you are running grunt. The ca.crt file is also necessary for self-signing your own certificate using a certificate authority that you create using the tutorial above. Hope this helps!
I would first look for the log file and tail that as you're making the request. It might give you hints as to what is wrong