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.
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.
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.
new-selfsignedcertificate -CertStoreLocation cert:\LocalMachine\My -FriendlyName "IIS Express Development Certificate" -DnsName localhost
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.
IIS Express expects all SSL\TLS for local debugging to be in the port range of 44300 – 44399.
After the above steps you should be able to open your application on localhost without certificate errors in Chrome and Postman.
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.
Information about the PowerShell new-selfsignedcertificate