Chrome Cert Errors for JSS

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.

Yep seeing this after just about every page reload.

Then Safari is instantly logging me back out if I try to use it.

Yeah lots of cert errors with various internal services but pretty much most can be fixed by re issuing through our internal CA.

The JSS one is different though. I'll reach out to Jamf and see if they have a workaround.

BTW, Safari is working fine here.

After clearing my Safari history it is now letting me in.

Support told me that we'll need to look at getting a publicly trusted 3rd party certificate.

@smurphyusd346 Really? I know that will fix it but seems extreme when they have a built in CA that they control.

I've opened a support ticket - surely not the only other person to do so. Will let you know what they say.

Support says it is not possible to do this currently with the built in CA. I created a feature request to have the Built-in CA include the SAN field on certs it generates.

This thread may be helpful if you need to ameliorate this before you can get all your certs updated to be greater than SHA1: https://www.jamf.com/jamf-nation/discussions/23483/how-to-set-google-chrome-policy-via-casper

I was also told by support we'd have to get a 3rd party cert generated to satisfy Chrome.

For these reasons (and more) since at least 1999 (when RFC 2459 was standardized) we have been on a slow path to moving away from the use of Common Names for domain names to using Subject Alternative Names.

From here

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.

Wonder if anyone at Jamf runs on the Chrome beta channel and would've seen this one coming weeks+ ago.

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.

Original ticket:

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.