LooUQ

101 N. Park Street, Suite 220

Traverse City, Michigan 49684 US

info@loouq.com

231.237.8860

Resources

Setup

Console

Answers

GitHub

Services

FAQ

IoT/M2M Bandwidth Estimator

Connect
  • Grey LinkedIn Icon
  • Grey Twitter Icon
  • GitHub-OctoIcon
  • Grey YouTube Icon

Copyright © 2019 LooUQ Incorporated.

Blog

Chrome 58 and IIS Express Certificates

June 6, 2017

 

Google released Chrome 58 back on April 27th, which for most Chrome users went completely unnoticed.  It had the typical solid collection of improvements and fixes, but it included one change that ASP.NET developers probably didn't see coming: the enforcement of RFC 2818 (published in 2000, first drafted in January 1998).  

 

 

What's the scoop on RFC 2818?
While RFC 2818 may have been published years ago, one practice it set to create has not been dutifully followed.  RFC 2818 describes “HTTP Over TLS” and among the topics discussed it cover policies about the use of certificates in the security processes implemented by TLS.  We are all familiar with the padlock symbol we see in our browsers next to the sites URL.  As developers we recognize that symbol tells us the browser trusts our web site's certificate.  The key change the RFC set in motion, which concerns us now, is the replacement of the commonName (CN field) with the subjectAlternativeName (SAN field) as the authoritative description of the web site’s name in its SSL\TLS certificate.


So What!
Well, if you develop web sites or web APIs (as LooUQ does) you will rely on certificates and almost certainly you will need to generate your own certificates to use in your development\debugging environments.  You may create and install the certificates manually, or you may have this done for you automatically with the installation of your development tools like Microsoft Visual Studio.  Here is the snag, that certificate you use for testing your software must now include a valid subjectAlternativeName for your test site.  That is if you are using Chrome in your testing\debugging efforts, starting April 28, 2017.  


Even if you primarily use browsers other than Chrome, you may be stuck with the release of Chrome 58.  LooUQ developed and maintains a RESTful API to our IoT cloud services.  One of the great tools out there for testing a web API is Postman.  Postman is a form based tool that does much of the same things as the well know CURL command line tool.  Nothing bad to say about CURL, but here at LooUQ Postman has been our companion whenever we are developing around a web API.  Well, Postman relies on the Chromium engine which is coupled to the Chrome release cycle. 


Bringing these points together…

  • RFC 2818 said stop using the CN field in certificates, use the SAN (subjectAlternativeName) field instead.

  • Chrome 58 released in April, began to only trust the SAN field (based on the RFC release 17 years ago).

  • If you use Postman, its underlying use of Google Chromium means it was affected by the Chrome 58 release.

  • If you use Microsoft Visual Studio for web site or web API development on ASP.NET you will likely use locally generated certificates for IIS express while debugging.  These are certificates are created using the Microsoft certutil.exe command line certificate utility.

If the above describes your environment, you are now stopped in your tracks, because certificates generated with certutil.exe use the CN field and do not complete the SAN field as mandated by Chrome (starting April 28th).  Postman, relying on Chrome technology, will treat Visual Studio\IIS Express certificates (certutil.exe generated) as invalid.  

 

The Workaround

If you rely on Chrome and/or Postman, as we do here at LooUQ, then the process below will allow you to keep going; albeit with extra manual steps.

 

For the workaround, we will be using Windows PowerShell.  So, if you don’t have it installed, that is a prerequisite for you to complete first.

 

  • Use the powershell applet: new-selfsignedcertificate to create your certificate as follows:

new-selfsignedcertificate -CertStoreLocation cert:\LocalMachine\My -FriendlyName "IIS Express Development Certificate" -DnsName localhost

 

  • Install it in your local machine Trusted Root Certificate Authorities by dragging from your Personal>Certificates to the Trusted Root Certification Authorities>Certificates folder inside CertMgr. 

  • Open the certificate (double-click on the certificate), go to the Details tab, scroll down to Thumbprint.  Copy the thumbprint value, paste it where you can remove the spaces (hint: notepad.exe) and keep it open so you can paste it into a command prompt later.

  • Register it with the local http.sys (IIS\IIS Express) as follows…

  • This process must be completed for each SSL\TLS port that you use in your development environment.

  • You need to remove any existing SSL\TLS certificate for the port (such as default one created by Visual Studio and IIS Express).

  • The example below follows the steps for port 44306.  

IIS Express expects all SSL\TLS for local debugging to be in the port range of 44300 – 44399.

  • netsh http delete sslcert ipport=0.0.0.0:44306

  • netsh http add sslcert ipport=0.0.0.0:44306 appid={214124cd-d05b-4309-9af9-9caa44b2b74a} certhash=46f7a5f17a68cbda3421ab632c4931bdf3eb3e8c

After the above steps you should be able to open your application on localhost without certificate errors in Chrome and Postman.

 

Notes

  • The appid in the certificate doesn’t appear to matter, so any valid GUID value is acceptable.

  • The thumbprint in the certificate is the value you use for certhash in the netsh add sslcert commmand above.

 

Resources

 

Information about the PowerShell new-selfsignedcertificate 

 


     

    Share on Twitter
    Please reload

    Featured Posts

    LooUQ 2018... Looking Ahead

    January 5, 2018

    1/2
    Please reload

    Archive
    Please reload

    Follow Me
    • Grey LinkedIn Icon
    • Grey Twitter Icon