If you’re using a Self-Signed certificate for your HTTPS server, a deprecation coming to Chrome may affect your workflow.
Chrome 58 will require [why?] that certificates specify the hostname(s) to which they apply in the SubjectAltName field; values in the Subject field will be ignored. This follows a similar change in Firefox 48. If impacted, you’ll see something like this blocking page as you load your HTTPS site:
NET::ERR_CERT_COMMON_NAME_INVALID is an unfortunate error code, insofar as all common names are now ignored. Chrome is working to improve the debuggability of this experience, via:
- Issue 703616 for adding a Security Panel warning
- Issue 703614 for updating the Certificate Error page logic
Update: Both of these have landed. Chrome now shows [missing_subjectAltName] in the details on the Certificate Error page, and a Subject Alternative Name Missing warning in the Security panel of the Developer tools.
Notably, Windows’ ancient makecert.exe utility cannot set the SubjectAltName field in certificates, which means that if you’re using it to generate your self-signed certificates, you need to stop. Instead, users of modern Windows can use the New-SelfSignedCertificate command in PowerShell.
New-SelfSignedCertificate -DnsName "www.example.com", "example.com" -CertStoreLocation "cert:\CurrentUser\My"
Using openssl for self-signed certificate generation? See https://stackoverflow.com/a/43860138.
This new restriction may also impact users of very old versions of Fiddler (or FiddlerCore), or users who have configured Fiddler to use MakeCert for whatever reason. Fortunately, Fiddler offers a number of different certificate generators, so you just need to make a small configuration change. To switch away from MakeCert, click Tools > Fiddler Options > HTTPS and click the “Certificates generated by MakeCert engine” link. Change the dropdown to CertEnroll and click OK. Click Actions > Reset All Certificates and restart Fiddler.
If you’re building an application atop FiddlerCore, you’ll need to make sure you’re not using makecert; see the end of this post for help.
-Eric Lawrence
PS: There was also a EnableCommonNameFallbackForLocalAnchors policy but it was removed in Chrome 66.
PS: There’s now official documentation on this topic.
text/plain 
I’m using IIS to generate self-signed certificates. How can i set the SubjectAltName field in certificates, with IIS?
Which version of IIS? Have you confirmed that it’s not setting the SAN already?
iis 7.5, i can set only this 6 properties see screen https://www.digicert.com/images/support-images/iis10/ssl-certificate-renewal-iis10-create-csr-3.png
This is indeed a limitation in IIS. Thanks for passing it along, I’ve reached out to Microsoft.
i requested certificate with standalone ca and this article helped me https://technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx
problem solved.
Generate certificates through the MMC Snap in – you will have to specify a DNS alternative name (aka SAN)
How to Request a Certificate With a Custom Subject Alternative Name
https://technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx
iis 7.5, i can set only this 6 properties see screen https://www.digicert.com/images/support-images/iis10/ssl-certificate-renewal-iis10-create-csr-3.png
Why the hell did they do this ? Massive PITA. A SAN doesn’t make you more secure. This is dumb.
The reasoning is pretty well explained in the Intent-To-Remove. Subject CN matching has been deprecated for a long time and has both security issues (e.g. poorly-specified interaction with Name Constraints), and compatibility problems.