Chrome Cert Errors for JSS

al_platt
Contributor II

Hi,

Has anyone else seen this error with the latest version of Chrome?

QuotedText

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.

QuotedText

More annoying than anything. Back to Safari for a bit i suppose.

15 REPLIES 15

AVmcclint
Honored Contributor

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.

murph
New Contributor III

Yep seeing this after just about every page reload.

murph
New Contributor III

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

al_platt
Contributor II

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.

murph
New Contributor III

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

murph
New Contributor III

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

al_platt
Contributor II

@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.

mtruskowski
New Contributor III

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.

gabester
Contributor III

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

analog_kid
Contributor

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

bentoms
Release Candidate Programs Tester
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

lsavage
New Contributor

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.

CasperSally
Valued Contributor II

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

cornwella
New Contributor III

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.

RyanDahl
New Contributor II

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.