I'm creating an API using node js and express. As we are moving towards production, I decided to encrypt the api using ssl, (simply adding the require 'https' option and creating the requires key and cert files using openssl).
I want to continue working on the API using postman (chrome plugin), so to enable me to do this, I visited the API using Chrome, saved the cert for the API to disk and then imported that cert file (cer format) to the "personal" certificate store in Chrome. So far, so simple.
I was then able to start using the API over ssl as expected. Great.
Now, where it is starting to get a bit odd is that if I want to then remove that certificate from my personal certificate store in chrome, I was expecting to be able to just open up the settings - > htttps - > manage certificates and then to be able to remove the certificate, however the certificate is not visible in the list of certs. It's clearly been imported and is working, it's just not showing in the list. The machine in question is running win 10, so I also checked the certificate management console for the machine and I searched for the cert and cannot find it anywhere.
I think that this should be really simple, so where is that cert that I imported (and which is clearly imported and working) so that I can remove it?
Thanks!
So, I finally found the solution to this. From the command line start "certmgr" and from there I can see the installed certificate and remove it. Not sure why it doesn't show up when viewed from within Chrome?!
Related
For the last few months we've has a client site working fine over HTTPS and HTTP, however as of a week or two ago we've had intermittent reports of it failing in Google Chrome.
As of last week I also got the issue, which is Chrome claiming ERR_EMPTY_RESPONSE to all requests sent through HTTPS.
This isn't replicated in any other browsers and the Security tab of the inspector declares the certificate valid and all page resources secure.
Anyone got some suggestions? I'm at a loss as to what to do, it feels like it might be a browser bug itself...
[Originally provided by a user called #daFlame, but it then got deleted within a few hours?]
The issue is caused by Chrome struggling with the cipher suites cPanel uses by default. CPanel are aware of the issue, and I've reported a ticket to Chrome.
CPanel's work around can be found here, but I'll provide a summary:
Go to WHM >> Service Configuration >> Apache Configuration >> Global Configuration
Then find the value SSL Cipher Suite and change it from the default to:
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS`
Once Apache is rebuilt, the errors stop.
I'm working with X509 certificates with my website. And I have created client certificates for testing.
The issue is that even though a single certificate is installed, chrome shows the certificate selection prompt. We have an option under IE to disable the same but I couldn't find any such option under Chrome.
I have searched but haven't found a satisfactory answer.
The closest I could get to solving the issue was with this link. This is for Chromium however I have read somewhere that Chrome uses a similar approach for this policy.
Sadly the Windows registry does not contain such a value :-
Software\Policies\Chrome
Any help with this deeply appreciated.
I moved recently my app to a scalable gear, I was using a custom domain with a startcom certificate and it worked fine.
Now Android devices mark the certificate as invalid, I was googling and the problem occurs if you don't configure the ssl chain properly. I have configured it right but I did it one more time, however the problem remains.
According to this ssl checker https://cryptoreport.websecurity.symantec.com/checker/ the chain is not sended and Android continue showing https://refly.xyz as invalid.
It's very possible that you have not combined your ssl certificate & chain certificate correctly. You need to combine them into the same file (ssl certificate first i believe) and then upload that as your certificate, and your key file. Don't upload anything into the chain form field.
I have an app on a custom domain on Google App Engine and I need to capture JSON packages.
I am using http://www.hurl.it/ to test and the url is like: https://subdomain.website.net.au/folder/
This give a server error however if I remove the S and just use HTTP the request works fine. What does Google need in order for this to work?
Update:
Using Curl and running the following command:
curl --verbose --data "#json.txt" --header "Content-Type:application/json" "https://subdomain.website.net.au/folder/"
I get the error: "unable to get local issuer certificate"
When I download the cert file from http://curl.haxx.se/ca/cacert.pem and run:
curl --verbose --cacert "cacert.pem" --data "#json.txt" --header "Content-Type:application/json" "https://subdomain.website.net.au/folder/"
It works fine and as expected. Does this mean the issue is with hurl.it? if so what is the issue exactly, I have a customer trying to send me data and it is not working either.
Update2:
The issue ended up being that the client did not support SNI so I had to use a VIP instead. This costs money, is an older method but more compatible.
There is an article on how to setup SSL for custom domains on developers.google.com.
Basically you need two things:
An SNI or Virtual IP Certificate
Your domain has to be a payed Google Apps domain to install the certificate
Your certificate, your Google Apps Domain and using the certificate with App Engine will cost you. If you can use the YOURAPPID.appspot.com domain instead you get SSL for free. If you need your custom domain i recommend the above website.
After Updating your Question:
It looks like the Certificate Authority (CA) is unknown or untrusted to the client. This can be fixed by using a commercial certificate from thawte or verisign. Or, you can add the CA certificate to the certificate store of your operating system or client application.
In other words: Install the CA cert as trusted root certificate in your operation system or app. That should do.
Oh and your assumption is right. hurl.it does not know the CA and thus rejects your certificate as invalid or unknown issuer.
Update 2:
Craig, your GeoTrust cert should be fine. Please try the following:
Please verify if you can visit this or any other page hosted by your app with a normal web browser. It should not complain about the certificate. If it does and you need to add an exception rule for the certificate then something is still wrong configuration wise.
I haven't done this in a while but last time i used an SSL certificate i concatenated the actual certificate and the CA somehow, i'm sure there are tutorials for this. Because the CA.cert isn't found it makes sense to provide it in this manner.
From developers.google.com:
'A certificate file can contain at most five certificates; this number includes chained and intermediate certificates.'
See also wikipedia
Since it does work with curl when you supply the CA manually that is a temporary solution for your customer to upload data.
Note that not all applications use the system store for certificates. Firefox for example has its own certificate store and it completely ignores all changes you do in the root certificate store of the operating system (at least under windows that is the case)
Once you have verified that the website works with HTTPS (see 1) you can create a simple form in that app containing a textarea in which you can paste your JSON data and send it to your app using jquery or something. While this is not ideal it is an excellent test to verify that your app and SSL setup works and the issue is somewhere else.
If upload is all you need at the moment you could always package curl and the CA.cert together and add a small batch file that makes the appropriate call.
This is all the information i can give you without having a look at your actual setup. My advice is to fiddle around with clients and certificates because that's definetly where this issue is. It has nothing to do with the JSON data.
I'm having a strange problem with a separately hosted subdomain I have. I'm running an application on Engine Yard, let's call it mysite.com. I have a wildcard SSL certificate installed there which covers all the subdomains (things like api.mysite.com). We recently decided to migrate our blog to be hosted independently (right now it lives on wordpress.com). Because I can't run the blog alongside our Rails app with ease on Engine Yard, I decided to grab some cheap hosting space from Dreamhost to host our Wordpress blog there. I set up the server there to fully host our subdomain (let's call it blog.mysite.com), and updated the DNS A record on Hover (our DNS provider) to point blog.mysite.com to the Dreamhost server. So here's the issue:
If I go to blog.mysite.com via Firefox or Safari on my Mac I see the basic Wordpress install which I set up. However, if I try to view things with Chrome I get the following error:
This webpage is not available
Error 118 (net::ERR_CONNECTION_TIMED_OUT): The operation timed out.
This happens on all Macs running Chrome I could get my hands on. I tried both clearing the cache and flushing the DNS but nothing. The weirdest part is Chrome keeps looking for https://blog.mysite.com instead of http://blog.mysite.com. There is no SSL cert installed on the subdomain for the blog on Dreamhost because it's not necessary.
Has anyone ever come across this before? And in case anyone wants to try the actual address is http://blog.frestyl.com.
sounds like you have a 301 permanent redirect that Chrome registered http://blog.frestyl.com -> https://blog.frestyl.com. Besides clearing the cache I'm not sure what else can be done.