I created the server.key and server.csr files using openssl req -nodes -newkey rsa:2048 -keyout server.key -out server.csr. I created a SSL certificate with startssl.com which gave me a certificate file. Then in my node.js application I read the key and certificate files:
var app = module.exports = express.createServer({
key: fs.readFileSync('server.key'),
cert: fs.readFileSync('server.cert')
});
But, now I get an empty response from my application, a "No data received" message. What could be causing this? I'm very new to SSL and how it all works, so any help with this is very much appreciated.
More info: I generated the two files, key and csr files, on my VPS server (production server), and now I'm trying to get them to work on my localhost (firstly, before I commit my code to production; I have to test that it works before making a git commit). So, it could be due to the fact that my localhost (development environment) is on a different domain from my VPS server (production environment). Could this be the case? If so, how can I make it to where the localhost and production environment use the same certificate?
Or, would you suggest I create another certificate for my development environment? The only problem I see with that, is that I wouldn't have a domain for my dev environment because it's done locally. I'd rather much use the same certificate (even if that means a broken lock icon or something on localhost) for the sake of simplicity.
I know this is an old question, but I encountered the same thing today. I would get the same result back from express (ERR_EMPTY_RESPONSE).
The fix? Be sure to specify https, and not http, in your test browser (e.g., https://localhost:8443).
If you previously used middleware to forward all http requests to https you wouldn't have seen this problem before. Also, expect your browser to complain about the certificate, but proceed through anyway (in chrome this takes several clicks).
You can troubleshoot errors by connecting to your application with curl --insecure --verbose. Generally you shouldn't use an SSL certificate on more than one host. You can make a self-signed one to test locally and use the startssl one in production. But in any case, the CN in the cert needs to match the hostname used to connect to the site to avoid annoying browser warnings. You can always make up a domain name for your machine like sam.local and put that in your /etc/hosts file and use that in your self-signed certificate as well as your browser address bar.
Related
I'm developping an intranet, to do so I'm using Node.JS without Express and until now I was using the http module with createServer but I noticed when I connect using localhost everything is fine, but when I connect to my server using the IP instead (from my machine or another device on the network) I get a warning in Chrome in the top-left corner saying that my site is not secured. I think this is because I'm using http instead of https but in order to use https.createServer I need to provide a SSL certificate, and I don't have one because I'm making an Intranet so it's not a website that need to be hella-secured since it will be deployed on a personal network only accessible from like 6 people.
I saw on tutorials that the options needs to look like :
options = {
pfx: fs.readFileSync("ssl/crt.pfx"),
passphrase: "password"
}
But I don't have any and I don't quite get how those work, I just want the message to disappear.
You can't create HTTPS server without a SSL certificate, but you can use tools to do so, like OpenSSL, but the certificate will appear invalid.
I actually found the answer to this question already, and just want to document my finding.
The problem has to do with using Node.js to access CouchDB through HTTPS. The CouchDB server has been configured with a SSL certificate generated by Let's Encrypt. The cert_file specified in local.ini contains both the server certificate and the issue's intermediate certificate. When I verified an URL through the browser, the connection was shown as valid. However, whenever I tried to fetch the same URL from Node, an UNABLE_TO_VERIFY_LEAF_SIGNATURE / unable to verify the first certificate error would be thrown.
I tried adding the root certificate to Node using the NODE_EXTRA_CA_CERTS environment variable. That failed. Then, I tried adding the intermediate certificate to NODE_EXTRA_CA_CERTS, and it worked. I could stop there, but somehow I knew that something was wrong.
After more digging, I finally found that even though the cert_file used by CouchDB includes both the server cert and the intermediate cert, unlike some other servers, CouchDB itself would only send back the server cert. In order to fix this problem the right way, I need to specify the intermediate cert as the cacert_file in the local.ini file as well. Once I did that, the error is gone.
I moved my website arvandkala.ir to https recently.
The problem is that some user (specially on mobile) get SSL pravicy Error
the user mobile clock is ok,
don't have a any mixing data on website.
firefox error code:
SEC_ERROR_UNKNOWN_ISSUER
the issuer is Certum and trusted by firefox.
TLDR: it's the chain cert
You need to get the correct chain cert from the CA and configure it in your server.
Normally a CA provides the correct chain cert (or sometimes certs plural) when you buy or obtain your server cert, and also makes all its chain certs (usually several) available on its website, but since I don't know Polish and don't know any customers of your CA certum.pl I can't address these approaches here. Nowadays a common alternative is for the cert itself to specify a way to obtain its parent cert, in the caIssuers attribute in the AuthorityInfoAccess extension. This can be seen with many tools, including (at least) desktop browsers, OpenSSL (x509 -noout -text -in $file), and Java keytool (-printcert -v -file $file), and your cert does have it, pointing to http://repository.certum.pl/dvcasha2.cer . Fetching that URL with a tool that does not interpret the content (i.e. not a browser, but things like curl wget perl python or javascript) does yield the correct cert, in DER format.
Configuring your server varies hugely depending on the server, which you didn't identify. Your server identifies in a response as Server: Apache/2.4.7 (Ubuntu) but this could be falsified because some people consider that a good way to confuse attackers (not very) or mistaken because some other terminator is in front. If true, although there are other possibilities I'll assume the common default mod_ssl. The documentation for Apache 2.4 mod_ssl is located on the Apache website under docs / 2.4 / modules / mod_ssl . As this page tells you for 2.4.8 up you can include the PEM-format chain cert with the server cert in the file specified by SSLCertificateFile, but below that you must put them both in a file specified by SSLCertificateChainFile instead. This config (certificate including chain, plus privatekey) can be per virtualhost, or if you don't need them to be different it can be global. On Ubuntu the usual practice (though not mandatory) is to put each virtualhost config in a separate file under /etc/apache2/sites-available and link it under (same)/sites-enabled.
Since the certficate obtained from the CA was in DER format you must first convert it to PEM format. This can be done directly by OpenSSL with openssl x509 -inform der -in $derfile -out $pemfile or by numerous other programs that can import DER format and then write out PEM format (including at least Windows, Firefox/NSS, and Java).
I have a NodeJS server on Amazon EC2.
I'm trying to set up SSL using certificates from "COMODO RSA Domain Validation Secure Server CA".
I got it working for all browsers except Firefox. Is this a common issure?
Please check that the server provides all intermediate certificates (trust chain). A common issue is to forget the intermediate certificates and then get errors on some browsers an no errors on others. This is caused by the browsers caching the intermediate certificates, e.g. if you've visited a site using the same intermediate certificates before, the browser will dutifully use these cached intermediates if the server forgot to server them. But, if the browser never visited such site before the intermediates are not cached and thus the verification will fail.
A good test is to use openssl s_client -connect your.https.server:443 and look at the chain of certificates it provides. Also, https://www.ssllabs.com/ssltest/analyze.html will point out such problems.
Does anyone know how to set up CouchDB to use a GoDaddy SSL certificate? It looks like it just can't get the intermediate certificate. I've checked it with curl and with SSL Checker and it says it can't get the intermediate cert. I've tried concatenating the cert file with the intermediate cert file just like I do with Apache (which works) and it still doesn't work. Any ideas?
Nevermind! Apparently erlang really stinks at SSL. I just set up stunnel and it works perfectly.