Errors when running SSL with grunt server - ssl

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

Related

Hostgator nodemailer ERR_TLS_CERT_ALTNAME_INVALID

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.

Amazon Pay Sandbox Error when trying to login on localhost - "Scheme not HTTPS"

I am trying to integrate Amazon Pay for a web shop. The login button is displayed correctly but as soon as I login with my sandbox account credentials to show the address widget I get the following error in my Chrome dev tools console: [Amazon.error] attempted redirect to http://myownvirtualhost.local/shop.html?... but scheme is not HTTPS.
So the error is obvious but how do I fix this? After login the redirect is supposed to happen on a HTTPS url but as already mentioned I am developing on my localhost with a configured virtual host. I also use the correct (EU) sandbox Widget.js file and set sandbox mode to true in my PHP configuration.
My code:
OffAmazonPayments.Button('amazonPayButton', 'MERCHANT-ID', {
type: 'PwA',
language: 'de-DE',
authorization: function() {
loginOptions = {scope: 'profile postal_code payments:widget payments:shipping_address', popup: true };
authRequest = amazon.Login.authorize(loginOptions, 'http://myownvirtualhost.local/shop.html?action=cart');
},
onError: function (error) {
console.log('auth request: ' + error.getErrorCode() + ': ' + error.getErrorMessage());
}
});
I didn't provide my merchant id as this is an example. So my redirect url has HTTP as scheme and this is the cause of the error. I am confused because after reading the registration chapter of the Amazon Pay Integration guide I thought SSL is not relevant on localhost.
From the integration guide:
Obtain an SSL certificate. Your server is required to have a valid SSL certificate issued by a trusted Certificate Authority. Note: When working in a "localhost" environment, an SSL certificate is not required. For more information, see SSL certification.
Any help is appreciated. Thanks in advance!
I suppose "localhost" is supposed to be taken literally as the default "http://localhost" domain.
If you would like to stick with your virtual host, there are two options:
Install a local SSL certificate for it (there is a lot of guides for this here on SO and out there in the internet)
Set the return URL to "https://myownvirtualhost.local" even without a certificate installed. Your browser will show an error. Modifying the address to "http://" will do the trick. This is not very elegant but should be good enough for development purposes.

How do I generate an SSL certificate for codeanywhere?

I want to have a server (webpack dev server) running in codeanywhere using https. How do I go about generating an SSL certificate so I can connect?
Chrome preferably however I will consider other browsers that could handle d3.js.
And the answer is: Run your service on port 3000. Codeanywhere will then auto configure a certificate for you.
To do this edit your webpack.config.js and ensure the following is in your dev server config:
devServer: {
host: '0.0.0.0',
port: 3000
}
If your container is running Apache you will need to stop it first (see http://www.learn4master.com/programming-language/shell/start-restart-and-stop-apache-on-linux the command depends on your host OS).

How do I have Apache2 httpd use the ubuntu's CA cert for outbound SSL connections from Apache?

Note this is not a question about having apache accept inbound SSL connections.
I have an apache module that needs to make outbound SSL connections. When it attempts to, it gets this error:
Failed to send events: The OpenSSL library reported an error: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1269:
This is indicating the SSL library that apache is using doesn't know about the (valid) certificate of the server that my module is trying to connect to.
The CA cert on my ubuntu system where this is running is fine, knows about this downstream cert, openssl s_client tells me everything is ok.
How do I tell Apache2 to use ubuntu's system CA cert to make outbound connections work?
update - I did an strace -e open httpd -X to see where it was trying to load certificates from. I see apache opening libssl.so, but then I don't see it even trying to open up the usual ssl.cnf or any certificates file.
snipped useless strace output
update2: As to how I'm creating the https request - I'm making the request from inside my custom apache module. My module .so is written in Rust, so the connection code looks basically like:
in mod_mine.so:
use hyper::Client;
use hyper_tls::HttpsConnector;
use tokio_core::reactor::Core;
let mut core = Core::new()?;
let handle = core.handle();
let client = Client::configure()
.connector(HttpsConnector::new(4, &handle)?)
.build(&handle);
//actually a POST, but this gets the same error
let request = client.get("https://saas.mycompany.io".parse()?);
let result = core.run(request)?;
... //process result
I found a solution that works, though I'm not sure it is optimal.
openSSL takes the environment variable SSL_CERT_FILE. I can set this in my apache module source code.
use std::env;
let cert_file = figure_out_cert_path(); //on ubuntu: /etc/ssl/certs/ca-certificates.crt
env::set_var("SSL_CERT_FILE", cert_file);

IIS7 - Two Way SSL - 403.7

I'm having some issues with two way SSL, hoping I can find some guidance. I've tried a lot of info I've found online, and while helpful I can't get past this issue..
First some background on what I have done and how I'm setup.
IIS Server Setup:
SSL Settings:
Auth Settings:
Mapping Config:
Mapped Certs:
Bindings:
Server Cert:
Server Trusted Root:
Cert Path:
OK. So for starters I'm trying to get this to work on the server itself. I've imported the server cert into my personal store:
With the same root authority:
So... That should cover it, Right?!
Nope. I get this error in IE when I hit the site locally??
You seem to use the same certificate for the server and the client. That's not how it works.
You need to have a client certificate in your personal store. IE can't find one doesn't send one to the server. IIS then complains about it with a 403.7 because IE didn't send a client certificate.
So you need to get a client (sometimes known as SMIME) certificate from your CA and install it into your personal store.
If you look at the details of your existing certificates it should show:
Enhanced Key Usage: Server Authentication (1.3.6.1.5.5.7.3.1)
what you need there is:
Enhanced Key Usage:
Client Authentication (1.3.6.1.5.5.7.3.2)
Secure Email (1.3.6.1.5.5.7.3.4)