I try to understand, how the HTTPS connection works for the SAP-Shine sample.
https://github.com/SAP-samples/hana-shine-xsa/blob/master/core-node/server.js
For me it looks so different to the standard express logic, where we create a HTTPS server, like this sample:
var key = fs.readFileSync(__dirname + '/../certs/selfsigned.key');
var cert = fs.readFileSync(__dirname + '/../certs/selfsigned.crt');
var options = {
key: key,
cert: cert
};
var server = https.createServer(options, app);
In opposite of this known sample above, SHINE is using the following procedure:
https.globalAgent.options.ca = xsenv.loadCertificates();
The npm xsenv-documentation says, that
"this code loads the trusted CA certificates so they are used for all subsequent outgoing HTTPS connections:"
Does it really mean, that we have only after putting the CA certificate to the globalAgent a running outgoing HTTPS connection?
Really, if I would know, I would like to check it for myself. But I only found hints for checking https connection for incoming requests, and rather not for outgoing connections.
Sorry, if my question sounds stupid, but I try to understand!
Please, let me know if I missed something in the configuration for a properly working outgoing HTTPS connection.
Related
I configured nodemailer to send to hostgator (as I learned how to here: https://stackoverflow.com/a/56291143/954986):
const transporter = nodemailer.createTransport(smtpTransport({
name: "hostgator",
host: "mail.mysite.com",
port: 465,
secure: true,
auth: {
user: "test#mysite.com",
pass: $password,
}
}));
However, when sending messages I'm getting: Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match certificate's altnames: Host: mail.mysite.com. is not in the cert's altnames: DNS:*.hostgator.com, DNS:hostgator.com
It only works when I add tls: { rejectUnauthorized: false}, which I would like to avoid.
The weird thing is that when I use any online SSL checker to look up "mail.mysite.com" it shows that SSL is configured correctly, and my site domain shows up in the certificate.
It seems like somehow hostgator is serving a different certificate for my supplied host? Any idea what might be happening, or how I can dig deeper into this?
Interesting update:
I did some more digging, and found the domain "cloud64.hostgator.com". I used this as the transportor host instead of mail.mysite.com, and it works with TLS enabled! And the email even sends faster.
I want to understand this though. Is this a stable host I can continue using? Is there some sort of redirect happening at the SMTP layer? What's going on?
From what I see you are connecting to:
In the first case, where you are getting *.hostgator.com TSL certificate, which is not valid for your domain thus your TSL validation fails.
In second scenario you are using cloud64.hostgator.com which probably has some generic MX record so your domain will work. Which is kind of weird, but I can imagine hacking it up somehow.
It seems to me you have incorrect DNS MX record(s) set for your domain. You have to correctly add the MX record(s) so the certificate will be matched to your domain when connecting via TLS SMTP.
For hostgator you can setup MX records like this.
Of course, if you want you can also read RFC974 - the mail routing with domain system and the RFC8314 - on TLS security which gives you details how it should work.
Note: What version of TLS will be supported depends on the negotiation between server and client. They will both agree on the highest common denominator. The latest is TLSv1.3.
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
//
Currently, I have a ngnix server (on port 5001) behind which a gRPC server is running, nginx having TLS enabled. All gRPC clients need to send the request to nginx port which forwards to gRPC server running. Initially for testing had gRPC request using usePlaintext() and it all worked fine, but the end goal is to use TLS. The requirement here is (as this are internal applications), gRPC channel request need not pass certificate but do a "skip certificate" when creating the channel.
After Googling around, I found examples on TLS but all of them does take .cert, .key file. Below is snippet which i tried and it failed at the server end couldn't validate the certificate
(java code)
ManagedChannel channel = NettyChannelBuilder.forAddress(<server IP address>, 5001).sslContext(GrpcSslContexts.forClient().trustManager
(new File(<.cert file>).build())
.build();
Doing some more research, i see Golang has InsecureSkipVerify() using which i can skip ceritifcate check (pls correct me if i am wrong)
tc := credentials.NewTLS(&tls.Config{
InsecureSkipVerify: true,
})
Now how do I accomplish the same in java?
TLS with disabled certificate checking is of questionable usefulness because it can be trivially MITMed and so is not "supported" by gRPC. I highly recommend providing the client with proper root certificates to verify the server.
That said, you can go around gRPC's API to do this by passing Netty's InsecureTrustManagerFactory to SslContextBuilder.trustManager(TrustManagerFactory):
NettyChannelBuilder.forAddress("<server IP address>", 5001)
.sslContext(GrpcSslContexts.forClient()
.trustManager(InsecureTrustManagerFactory.INSTANCE)
.build())
.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.
I use resty.http module. But the data is used. For usual http or https without verification all works.
local http = require("resty.http").new()
local res, err = http:request_uri(url, {
method = method,
headers = headers,
body = body,
ssl_verify = false
})
But if I do not use ssl_verify it wouldn't work with the error:
lua ssl certificate verify error: (20: unable to get local issuer
certificate),
I found using Google that lua_ssl_trusted_certificate can help. But I don't know how it can help. I have tested such command: lua_ssl_trusted_certificate /etc/ssl/certs/GlobalSign_Root_CA.pem; but it did not help to me.
How to verify https in a proper way?
In your nginx.conf you need to configure
lua_ssl_verify_depth 2;
lua_ssl_trusted_certificate /pathto-ca-certs.pem;
In my case my server calls out to only one external HTTPS endpoint. So I exported the certificate with the full chain (via borwser ceritificate export in Firefox) and imported into a PEM file. This is the .pem file that I supplied above.
I use lua-resty-http to make the calls to https and it works fine. You can use tools like wireshark/fiddler to monitor the outgoing connections to see if the requests are being made the way you want.