Mojave clients not working when a branch is used NSURLErrorDomain error -1100

Skip to first unread message

Vince Roche

May 29, 2019, 7:54:08 AM5/29/19
to reposado
I have been running Reposado and Margarita on High Sierra for about 3 years over http without any issues with over 200 clients ranging from 10.6.8 to 10.13.6.

To prepare for Mojave, I have updated the config, catalogs and client url to point to https. I use a prod and test branch and have been able to successfully serve updates to High Sierra clients over https using either the default catalog or the prod and test branch.

Mojave on the other hand has proven a little problematic. I can get Mojave to work when using the default catalogue

defaults write /Library/Preferences/ CatalogURL https://sasmac01:8090/content/catalogs/others/index-10.14-10.13-10.12-10.11-10.10-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog

However my issue is when trying to use a branch it reports the following error NSURLErrorDomain error -1100

I have added the SUDisableEVCheck setting as below onto the client

defaults write /Library/Preferences/ SUDisableEVCheck -bool YES

And created completely new branches but this has me stumped. I can see the branch catalog in a browser


so I know it is at least published but to no avail. I have also tried a repo_sync --recheck still with no luck.

Any help would be greatly appreciated

Matt Cahill

May 30, 2019, 2:30:55 AM5/30/19
to reposado
We were seeing something similar

2019-05-30 18:03:06+12 hostname softwareupdated[1045]: SUScan: Error encountered in scan: Error Domain=NSURLErrorDomain Code=-1100 "(null)" UserInfo={PKURLErrorResponseHeaders=<CFBasicHash 0x7fa0818e3d00 [0x7fff8cc878e0]>{type = immutable dict, count = 5,
entries =>
0 : Date = <CFString 0x7fa07fe3b360 [0x7fff8cc878e0]>{contents = "Thu, 30 May 2019 06:02:51 GMT"}
3 : Content-Length = 178
4 : Connection = <CFString 0x7fff8cd12618 [0x7fff8cc878e0]>{contents = "keep-alive"}
5 : Content-Type = text/html
6 : Server = <CFString 0x7fa081a2a280 [0x7fff8cc878e0]>{contents = "nginx/1.14.0 (Ubuntu)"}

Turns out we'd accidentally regressed a change we'd made to fix a similar problem. See greg's post below!topic/reposado/qUZBN0Ow8J4

There is a 041-59915 and a 041-59915::1 so in our case following the workaround fixed the issue.

hope this helps



Vince Roche

May 31, 2019, 2:48:34 AM5/31/19
to reposado

Thanks Matt, it worked a treat and kudos to Greg Neagle for posting the workaround.

Reply all
Reply to author
0 new messages