I'm running latest gen Chrome (27) and preparing a demo that requires using a self-signed cert to support HTTPS on a local IIS website. The cert has been created with the correct common name for the website (good little guide here) and then added to the trusted root certs on the local machine.

In IE, everything is good with no warnings, broken padlocks or red address bar so it's clearly installed in the Windows cert store. However in Chrome I'm getting the classic big red crosses through the padlock icon and HTTPS scheme in the address bar. Inspecting the cert advises that the identity can't be verified.

For various reasons I need to use Chrome for this demo, is there any way to get it behaving as you'd expect to see with a genuine cert? I know Google does some funky things with certs, is this doable?

  • 2
    Troy Hi! Your question was voted to be closed as off-topic and reading it, I have to agree. Your best bet would probably be official sources first, or alternatively asking our resident security guys and gals in the DMZ chat room. Main problem with this question is that it's too localized. I've seen similar questions lately regarding certificate errors in Chrome, and appears to be some temporary hiccup on Google's part that might be resolved with future updates. Have you searched through their open issues?
    – TildalWave
    Jun 15, 2013 at 11:53

2 Answers 2


So it turns out that Chrome won't trust names that aren't fully qualified. I was working with a host name of "foo" which was fine in IE once the cert was in the list of trusted roots. I created a new cert for "foo.com", repeated exactly the same process and now Chrome is happy.

  • 1
    Chrome seems to be fine with alternate names that don't have multiple parts, so it's possible to set up a trusted localhost certificate by using a dummy domain name (i.e. localhost.com) as the common name and "localhost" as one of the alternate names.
    – Brilliand
    Sep 5, 2014 at 17:48
  • @Brilliand could you explain how you did that? I don't know what you mean by setting common names and alternate names. Where did you do that? Feb 9, 2015 at 4:53
  • When setting up an SSL certificate that covers multiple domains, you have to set one of those domains as the "common name"; the rest are "alternate names". Chrome only requires the "common name" to be fully qualified. I no longer remember the details of how to do it, but I currently have a certificate set up on localhost with "localhost.com", "localhost", and my computer name set up as its three domain names, and Chrome accepts it fine.
    – Brilliand
    Feb 9, 2015 at 15:59

Have you tried exporting the certificate and adding it directly to the trusted certificates for your browser? I'm not sure how it works on Windows but on a linux machine you can import the certificate manually into your trusted certs[1].

Also, if you're having trouble with Chrome 27 perhaps you can snag a slightly older version and test with that. Sub-optimal to be sure, but perhaps doable. Google has been bringing the hammer down on self-signed certificates so it wouldn't surprise me that they've locked this up too. That being said; I have yet to personally run into any problems using self signed certificates after they are locally imported.

Best of luck.

1) http://webcache.googleusercontent.com/search?q=cache:CR48ZkEOzTsJ:ayozone.org/2013/05/27/add-a-trusted-self-signed-ssl-certificate-to-chrome/+&cd=1&hl=en&ct=clnk&gl=us

  • 1
    Yes, I did try manually importing back in but without success which makes sense because the cert was there already from the above mentioned process anyway! If the current status quo with Chrome is to always warn on self-signed certs then that's what I need to run with, others need to repro this demo so running in an old version of Chrome won't cut it.
    – Troy Hunt
    Jun 15, 2013 at 4:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.