Disabling TLSv1.0

I think you edit Tomcat's server.xml and remove older TLS protocols from your 8443 connector by editing the sslEnabledProtocols key. That should prevent the server from allowing the client to negotiate SSL/TLS with older protocols. Be sure to make a backup of the file before modifying the config and be sure to restart Tomcat afterwards.

<Connector
URIEncoding="UTF-8"
clientAuth="false"
sslProtocol="TLS"
sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1"
....
port="8443"
</connector>

I understand how to remove older SSL variants; that isn't the issue (especially because they've been removed by default for a while now). The issue is that "TLSv1" is not permitted on new PCI DSS-compliant deployments. To be compliant, that key needs to look like this:

sslEnabledProtocols="TLSv1.2,TLSv1.1"

However, doing so breaks communication with the jamf binary. The JSS web interface is fine, which indicates to me that it's likely the binary itself that's having an issue.

If no one else has found a solution, or if no one else reading this has had to set up a JSS in a PCI environment, then I'll just open a case. I figured it was worth a shot here first.

If the jamf binary can no longer connect after you disable TLSv1 then it sounds like the binary requires that. I'll see if I can re-create the issue on my end in the next day or two.

In the meantime, you may want to reach out to support about this.

Did you happen to get confirmation from support that the jamf binary still requires TLSv1?

I finally got around to testing and sure enough, once I remove TLSv1 the jamf binary on my Mac can no longer communicate.

However, the website still loaded and Chrome shows it's using TLS 1.2.

2015-07-09 18:10:40.985 jamf[39305:3334743] CFNetwork SSLHandshake failed (-9824)
2015-07-09 18:10:41.207 jamf[39305:3334743] CFNetwork SSLHandshake failed (-9824)
2015-07-09 18:10:41.440 jamf[39305:3334743] CFNetwork SSLHandshake failed (-9824)
2015-07-09 18:10:41.508 jamf[39305:3334743] NSURLConnection/CFURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9824)
Waiting 5 seconds to try again...

I also just logged a ticket with support to see what they say. I'm on 9.72 which is the latest and greatest.

@bvrooman just curious whether 9.73, which came out just after @matt.jamison posted, fixes this issue?

The release notes for 9.73 doesn't mention it:

Casper Suite Release Notes | Version 9.73

Wanted to check here before reaching out to JAMF support.

Thanks,
Don

Just got off the phone with JAMF, they've acknowledged the issue (TLS 1.0 required).

Keep an eye on release notes for: D-009291

Thanks,
Don

FWIW, Apple has a KB on this error in regard to servers (DPs): https://developer.apple.com/library/prerelease/ios/technotes/App-Transport-Security-Technote/

"All connections using the NSURLConnection, CFURL, or NSURLSession APIs use App Transport Security default behavior in apps built for iOS 9.0 or later, and OS X v10.11 or later. Connections that do not follow the requirements will fail. For more information on various the connection methods, see NSURLConnection Class Reference, CFURL Reference, or NSURLSession Class Reference.

These are the App Transport Security requirements:

The server must support at least Transport Layer Security (TLS) protocol version 1.2.
Connection ciphers are limited to those that provide forward secrecy (see the list of ciphers below.)
Certificates must be signed using a SHA256 or greater signature hash algorithm, with either a 2048-bit or greater RSA key or a 256-bit or greater Elliptic-Curve (ECC) key.
Invalid certificates result in a hard failure and no connection."

...

In OS X v10.11 and later /usr/bin/nscurl can help diagnose connection issues that are due to App Transport Security.

Actually we have the same issue here on a Red Hat based JSS ...

2015-10-08 15:27:52.074 jamf[2146:14829] NSURLConnection/CFURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9813)
    The network connection was interrupted while downloading the package from https://jss.our.domain/JSSShare/Packages/TextWrangler50Build3766v2.pkg.zip. Attempting to reconnect...

Any news about it?

We are still using 9.73, should we upgrade to 9.80 and 9.81 to fix this issue?

Or is D-009291 still open?

PS: All clients are still on 10.10.5 and it worked until Tuesday this week without any problem … Also "jamf policy verbose" shows no more details. A workaround right now is to force the distribution point to AFP/SMB (we use SMB) but of course we would prefer to go on using https SharePoints for the distribution.

Firefox, Safari and Chrome can access the https-Share with capserinstall and it's using TLS 1.0, so the jamf binary should work fine normally but it doesn't.

I was able to disable TLSv1 without any side effects.

I reverse that statement. I began having a problem where my Windows clients were unable to checkin or enroll. Disabling TLSv1 broke all functionality for Windows clients. I'm working with my JAMF support to find a solution.

@psd_martinb Did you resolve this issue?

Has anyone else had issues with disabling TLSv1.0 on a Mac Server (OS X 10.11.6 / Server 5.2)?

@cwaldrip Negative, I had to turn TLSv1 back on for Windows clients to work. Found it to be an issue with the .NET 3.5 stack the jamf agent uses on Windows.

Thanks. If Windows clients (unmanaged I assume) is the only gotcha' then I should be okay. Checking some other sources for feedback as well (Slack MacAdmins group).

Is there a solution to the windows issue? We run JSS on windows, and turned TLS 1.0 off. Now the jamf binary on mac clients says:

The SSL Certificate for https://jss.example.com:8443/ must be trusted for the jamf binary to connect to it. Error enrolling computer: unable to establish trust with the JSS – Connection failure: ‘The Internet connection appears to be offline.’

Anyone get any progress on this, we need to disable 1.0 in our environment as well as when we do it breaks, bad. Thankful for VM snapshots!

Are you running Jamf Pro 10.5.0?

Jamf Pro Release Notes, Version 10.5.0, TLS 1.0 and TLS 1.1 No Longer Enabled