Has anyone else seen this error with the latest version of Chrome?
This server could not prove that it is jss.myserver.com; its security certificate is from [missing_subjectAltName]. This may be caused by a misconfiguration or an attacker intercepting your connection.
More annoying than anything. Back to Safari for a bit i suppose.
Yeah, Chrome version 57 first annoyed us by stopping support of SHA1 certificates. So we went and renewed many of our certs issued by our internal CA. Now version 58 is complaining that something else is not to its liking. This page kinda explained it for me https://textslashplain.com/2017/03/10/chrome-deprecates-subject-cn-matching/ But I'm still not sure exactly how to fix this. I've found workarounds that change registry entries on Windows PCs and plist settings on Macs, but by Google's own admission, those workarounds aren't permanent.
analog_kid: you are saying that Windows 2016 CA doesn't have the ability to create a cert that will satisfy Chrome 58? It worked in Chrome 58 but as AVmcclint stated, Chrome 58 requires much more. At this point, i'm performing SHA256 with 2046 bit encryption when generating my certs. BTW: Firefox new version doesn't work either.
Does anyone know how to setup Windows 2016 CA to satisfy the new standards? What's missing? Any help would be much appreciated.
Contacted Support about this a week ago as well, received a boilerplate response about "self-signed certs not being valid". I suppose deploying self-signed certificates in an intranet setting may be perceived as insecure, but it's still preferable to unencrypted exchanges, and the fix to this issues in particular is to generate the proper SANs in the CA to be compliant with current standards, not to sideline people to buy a third-party cert.
As of version 58+, Google Chrome now requires a Subject Alternative Name in issued SSL certificates. As of JSS 9.97.1488392992, the certificates generated by the JSS do not carry this feature and return a "Not Secure" warning when Google Chrome of an affected version (currently in Beta) is being used with the JSS certificate installed in the Trusted Root Certificate Authority under Windows or the system Keychain under OS X. I realize Chrome v58 is currently still in Beta, but Google has already mentioned this to be part of the feature set of the final release: https://groups.google.com/a/chromium.org/forum/m/#!topic/security-dev/IGT2fLJrAeo
JAMF Support Reply:
This is something that has been in place prior to Google Chrome 58, and before JSS 9.97. The JSS Built In CA is a non-valid CA, and will always display non-secure when going to it in any browser. This is because the JSS is not a validated CA vendor, as we are not GoDaddy / Digicert. If we wish to have a naturally trusted and valid certificate we need to use a 3rd Party SSL certificate, as the JSS Root CA is not naturally trusted by all devices.
Any word on if updating the SSL to something from Verisign or GoDaddy will affect the MDM profile being signed by the JSS Built-In Signing Certificate? If it's just the web page, I'm fine, but I had a bad experience with some incorrect documentation and had to recall all devices to deal with a new APN push cert at one point. It's made me wary.