11

I have an Owin self-host C# app that provides Web API services over 127.0.0.1:5555 (it only listens on localhost, no external connections).

These Web API services are called using Ajax from an AngularJS app. As an aside: the reason for the Owin app is that certain interaction with the hardware is needed, which is not possible from within a browser. Also, the AngularJS app is for internal use, so I have control over the browsers used.

The above works very well over HTTP, but the Angular JS app needs to use SSL, which does not work unless the Owin app also uses SSL (otherwise you get "Mixed content" errors).

I have bought an official cert for the AngularJS app, and I am using self-signed certs for the Owin localhost stuff.

The problem is that I get "NET::ERR_CERT_AUTHORITY_INVALID" (when testin from Chrome) and "net::ERR_INSECURE_RESPONSE" from the AngularJS app when talking to the Owin Web API.

Here is what I have done, in broad strokes:

I used a CentOS box to generate the cert for localhost and exported it to pkcs12 / pfx format. I also generated a CA cert and exported it the same way.

Using MMC I imported the localhost cert on the Windows 7 machine running the Angular & Owin app into Certificates (Local Computer) > Personal > Certificates.

I also imported the CA cert on the Windows 7 machine into Certificates (Local Computer) > Trusted Root Certification Auhorities > Certificates

Looking at the localhost cert, it says "Issued to: localhost", Issued by: "ca.acme.com", "You have a private key that correpsonds to this certificate", (under Certification Path) "This certificate is Ok"

The CA cert says "Issued to: ca.acme.com", Issued by: "ca.acme.com", "You have a private key that correpsonds to this certificate", (under Certification Path) "This certificate is Ok"

netsh http show sslcert

IP:port                 : 127.0.0.1:5555 
Certificate Hash        : 1234555555555555555555511155555555555555
Application ID          : {1234a123-1234-1234-1234-123412341234} 
Certificate Store Name  : (null) 
Verify Client Certificate Revocation    : Enabled
Verify Revocation Using Cached Client Certificate Only    : Disabled
Usage Check    : Enabled
Revocation Freshness Time : 0 
URL Retrieval Timeout   : 0 
Ctl Identifier          : (null) 
Ctl Store Name          : (null) 
DS Mapper Usage    : Disabled
Negotiate Client Certificate    : Disabled

What am I missing? How can I make Chrome, etc. trust the SSL cert for localhost?

Lars335
  • 1,542
  • 1
  • 16
  • 33
  • If this is only for your own testing: Call an HTTPS URL that uses that certificate directly, and add an exception in your browser. If you want it to work everywhere in user’s browsers on the web – then you need to get a certificate that is signed by a trusted CA. – CBroe Dec 22 '14 at 19:11
  • http://stackoverflow.com/questions/7580508/getting-chrome-to-accept-self-signed-localhost-certificate – epascarello Dec 22 '14 at 19:24
  • @CBroe It is not for testing. Also, this will be used on a large number of internal computers; could I get an official cert for localhost and use it on all of them somehow? Since this is all localhost traffic only (with no sensitive data) I really have no security concerns. – Lars335 Dec 22 '14 at 19:26
  • If its a Dev environment., then go with suggestion below by @Brad Parks... It saved my day...! Thanks Brad... – SSG Jan 29 '17 at 10:57

3 Answers3

7

I got this working (sufficiently for my current needs, at least).

I copied the localhost cert from "Certificates (Local Computer) > Personal > Certificates" to "Certificates (Current User) > Personal > Certificates". This got rid of the red cross-out of https in Chrome (and the "NET::ERR_CERT_AUTHORITY_INVALID" message) as well as the "net::ERR_INSECURE_RESPONSE" error in AngularJS.

Note that in my case, the localhost cert had to be in both the Local Computer store and in the Current User Store, otherwise the netsh command for binding it to port 5555 (for the Owin app) would fail:

netsh http add sslcert ipport=127.0.0.1:5555 certhash=1234555555555555555555511155555555555555 appid={1234a123-1234-1234-1234-123412341234}

SSL Certificate add failed, Error: 1312, A specified logon session does not exist. It may already have been terminated.

There is still no nice green padlock in Chrome (it now has a yellow little triangle on the pad lock, "The identity of this website has been verified by ca.acme.com but does not have public audit records"), but this does not seem to interfere with the Web API communication, so it should be fine.

If anybody knows of an easy way to make it all green and nice with no warnings, I am still interested, but it is not critical.

Lars335
  • 1,542
  • 1
  • 16
  • 33
0

On Linux I had to apt-gt install libnss3-tools

With libnss3-tools you get certutil

Now the key-command:

certutil -d sql:$HOME/.pki/nssdb -A -t "CP,CP," -n <your alias> -i <your crt-file to import>

This solve all my problems with Chrome on Raspberry / Linux

Mike Mitterer
  • 5,309
  • 2
  • 35
  • 51
-2

No; you will not be able to get a certificate for "localhost" professionally signed by any reputable SSL provider, because "localhost" is not under a domain name that belongs to you. (Indeed, it is not precisely under a domain name at all; it's a bare hostname.)

You might be able to create a real domain name (e.g, localhost.example.com) that resolves to 127.0.0.1 and get a certificate for that signed, but that's rather questionable. Some SSL providers might not sign it anyway. It's worth a try, though!

duskwuff -inactive-
  • 171,163
  • 27
  • 219
  • 269
  • 8
    The real question for most who will read this thread is, how do we make Chrome STFU about our self-signed certificate when testing on localhost? I've had to switch to firefox as of a month ago because the chrome experience is miserable – Amalgovinus Aug 05 '15 at 22:02
  • 4
    You can start chrome in a mode to ignore all SSL cert errors... It requires you use a command line option, but works great. Try this: `--ignore-certificate-errors` at the command line. More [details here](http://superuser.com/a/1036062/38941) – Brad Parks Feb 05 '16 at 14:21