Posted on 06-21-2013 09:24 AM
Hi Folks,
When pushing out policies over https, I receive the following error:
Executing Policy com.apple.desktop.plist... Downloading https://xxx.xxx.domain.com:443/domain/Packages//com.apple.desktop.plist.dmg... Error: Package not successfully downloaded: 35
I have tried to troubleshoot the issue using curl and can see the same error being returned:
$ curl -vv https://xxx-xxx.xxx.domain.com/domain/Packages/com.apple.SetupAssistant.plist.dmg
About to connect() to xxx-xxx.xxx.domain.com port 443 (#0)
Trying xx.xx.xx.xx...
connected
Connected to xxx-xxx.managed.domain.com (xx.xx.xx.xx) port 443 (#0)
SSLv3, TLS handshake, Client hello (1):
error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)
* Closing connection #0
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)
However, when forcing curl to use SSLv2 I can recreate the error once again:
curl -vv --sslv2 https://xxx-xxx.managed.domain.com/domain/Packages/com.apple.SetupAssistant.plist.dmg
About to connect() to xxx-xxx.managed.domain.com port 443 (#0)
Trying xx.xx.xx.xx...
connected
Connected to xxx-xxx.managed.domain.com (xx.xx.xx.xx) port 443 (#0)
SSLv2, Client hello (1):
Unknown SSL protocol error in connection to xxx-xxx.managed.domain.com:443
* Closing connection #0
curl: (35) Unknown SSL protocol error in connection to xxx-xxx.managed.domain.com:443
Now if I force curl to use SSLv3 things appear to run as expected and I can verify things appear to be configured correctly:
curl -vv --sslv3 https://xxx-xxx.managed.domain.com/domain/Packages/com.apple.SetupAssistant.plist.dmg
About to connect() to xxx-xxx.managed.domain.com port 443 (#0)
Trying xx.xx.xx.xx...
connected
Connected to xxx-xxx.managed.domain.com (xx.xx.xx.xx) port 443 (#0)
SSLv3, TLS handshake, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS handshake, Server key exchange (12):
SSLv3, TLS handshake, Server finished (14):
SSLv3, TLS handshake, Client key exchange (16):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSL connection using DHE-RSA-AES256-SHA
Server certificate:
subject: C=GB; ST=London; L=Wandsworth Town; O=domain Ltd; OU=Managed IT; CN=xxx-xxx.managed.domain.com; emailAddress=ams@domain.com
start date: 2013-06-20 11:35:27 GMT
expire date: 2018-06-20 11:35:27 GMT
common name: xxx-xxx.managed.domain.com (matched)
issuer: CN=domain Ltd JSS Built-in Certificate Authority
SSL certificate verify ok.
> GET /domain/Packages/com.apple.SetupAssistant.plist.dmg HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5
> Host: xxx-xxx.managed.domain.com
> Accept: */*
>
< HTTP/1.1 401 Authorization Required
< Date: Fri, 21 Jun 2013 16:14:08 GMT
< Server: Apache/2.2.22 (Ubuntu)
< WWW-Authenticate: Basic realm="distribution"
< Vary: Accept-Encoding
< Content-Length: 497
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>401 Authorization Required</title>
</head><body>
<h1>Authorization Required</h1>
<p>This server could not verify that you
are authorized to access the document
requested. Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
<hr>
<address>Apache/2.2.22 (Ubuntu) Server at xxx-xxx.managed.domain.com Port 443</address>
</body></html>
Connection #0 to host xxx-xxx.managed.domain.com left intact
Closing connection #0
* SSLv3, TLS alert, Client hello (1):
Does the Casper Suite use sslv2 to curl down packages from the distribution point?
Any help would be appreciated.
--James.
Posted on 06-21-2013 02:05 PM
I've been attempting to debug something similar. The number you're getting with the original error is 35 which is a curl error. http://curl.haxx.se/libcurl/c/libcurl-errors.html
Error 35 means the handshake is failing. The verbose curl log you've posted looks suspiciously like your server is expecting a username and password and isn't giving the correct response.
Posted on 08-19-2013 07:50 AM
You've bumped up against a bug in OpenSSL 0.9.8 in its handling of warning-level alerts. In this case it appears to be hostname mismatch when using SNI extensions.
I've submitted a patch to OpenSSL that addresses this.
--mancha
1] [https://rt.openssl.org/Ticket/Display.html?id=3038&user=guest&pass=guest
2] [http://marc.info/?t=136760077700002&r=1&w=2
Posted on 07-26-2016 08:28 AM
@james_ridsdale Did you ever figure this out? I'm getting same error from cURL in an API script...
Posted on 07-26-2016 12:23 PM
@dfarnworth I did, but don't have a note of the fix as it's under a previous JN account. I'd consider patching this server though!
Posted on 08-01-2016 02:05 PM
Chiming in - I think I'm getting something similar - a curl 35 error when trying to PUT some data into a computer record via the API.
The command is called as part of a script that I was told used to work (not sure what changed - I just inherited this JSS), here it is:
/tmp/.eaxml is generated during the script, nothing wrong there. curl just won't connect. Gives the error curl: (35) Unknown SSL protocol error in connection to server.url:-9850
If I try to force SSL v3, I get curl: (35) SSL peer handshake failed, the server most likely requires a client certificate to connect
I can load the XML data for the computer record in a browser just fine, so it looks like curl is suspect. Version 7.43.0 running on OS X 10.11.5 if that helps. I hope it's just me being dumb.
Posted on 08-03-2016 12:41 PM
I've got a few more thoughts and info on what this is about, but on hols at moment so don't have my notes.
Watch this space for when I return...
Posted on 08-03-2016 02:03 PM
Solved - needed to update Tomcat's ciphers on the JSS with these: https://jamfnation.jamfsoftware.com/article.html?id=384
Regards,
Neil.
Posted on 08-10-2016 03:14 AM
Thanks @neil.martin83, that was what JAMF suggested to us. I am testing in dev environment currently.