9
votes

We have a osx server configured with SSL cert and enabled Xcode. Everything worked fine before updating OSX Server to 3.2.1 and Xcode 6.0.1.

The problem we have is that when the integration is finished, and we click on the install button on the device, it tries to download but fails silently. The device logs prints:

Sep 22 13:32:29 somePhone itunesstored[84] : Could not load download manifest with underlying error: Error Domain=NSURLErrorDomain Code=-1001 "Cannot connect to buildserver.com" UserInfo=0x14f74dfe0 {NSUnderlyingError=0x14f6e8330 "The request timed out.", NSErrorFailingURLStringKey=https://buildserver.com:20343/api/integrations/fc9e3c6ed7d80506e9e8e37b0d06a905/87785234-f589-4230-9c0c-055f656b28a6/install_manifest.plist, NSErrorFailingURLKey=https://buildserver.com:20343/api/integrations/fc9e3c6ed7d80506e9e8e37b0d06a905/87785234-f589-4230-9c0c-055f656b28a6/install_manifest.plist, _kCFStreamErrorDomainKey=1, _kCFStreamErrorCodeKey=60, NSLocalizedDescription=Cannot connect to buildserver.com}

When I check the port 20343 the valid ssl cert from OSX Server is switched out with a cert signed by: Xcode Server Root Certificate Authority, it seem to be selfsigned.

In older versions of osx server the port 20343 did not exists, since the plist file was served under the same port as the rest of the site. Information on the server listening on port 20343.

sudo lsof -i | grep "20343"
Password:
node         65          _xcsd   15u  IPv4 0x73c2c4b0fa77e271      0t0    TCP *:20343 (LISTEN)
node      29118          _xcsd   16u  IPv4 0x73c2c4b0fa77e271      0t0    TCP *:20343 (LISTEN)
node      29120          _xcsd   16u  IPv4 0x73c2c4b0fa77e271      0t0    TCP *:20343 (LISTEN)
node      29121          _xcsd   16u  IPv4 0x73c2c4b0fa77e271      0t0    TCP *:20343 (LISTEN)
node      29122          _xcsd   16u  IPv4 0x73c2c4b0fa77e271      0t0    TCP *:20343 (LISTEN)
node      29123          _xcsd   16u  IPv4 0x73c2c4b0fa77e271      0t0    TCP *:20343 (LISTEN)
node      29124          _xcsd   16u  IPv4 0x73c2c4b0fa77e271      0t0    TCP *:20343 (LISTEN)
node      29125          _xcsd   16u  IPv4 0x73c2c4b0fa77e271      0t0    TCP *:20343 (LISTEN)
node      32397          _xcsd   17u  IPv4 0x73c2c4b0fa77e271      0t0    TCP *:20343 (LISTEN)

This seem to be a bug on the osx server and xcode bots. Do anyone have a solution for how we can download the ipa files on our devices?

3
Did you make any progress on this? I'm running into the same issue.Stefan Arentz
Same here. Hinderberg, @St3fan, did either of you figure it out yet?Arclite
@Arclite See my answer below :-)Stefan Arentz

3 Answers

4
votes

Same issue here.

Initially the out-of-the-box Xcode Server solution worked and any device could install .ipa generated by the Xcode bot. After one or two days it suddenly got broken and none of the devices could download anymore, just displaying:

Cannot connect to www.example.com

Tracing log on my iPhone I could also see the device trying to connect to https://www.example.com:20343/api/integrations. This Xcode webservice is apparently using a self-signed Xcode Server Root Authority certificate (instead of the certificate selected in the OS X Server management application) and since any client need to access this webservice requests are incorrectly signed.

A post on the Apple Developer Forums guided me to the Xcode Server Apache configuration located here (thank you Paul Verity):

/Library/Developer/XcodeServer/CurrentXcodeSymlink/Contents/Developer/usr/share/httpd_xcs.conf

or in OS X Server 4.1.5:

/Library/Developer/XcodeServer/CurrentXcodeSymlink/Contents/Developer/usr/share/xcs/httpd_xcs.conf

Containing a section that exposes the webservice through the regular Xcode Server website:

<IfModule mod_proxy.c>
    ProxyPass /xcode/api https://127.0.0.1:20343/api retry=0 timeout=30
    ProxyPassReverse /xcode/api https://127.0.0.1:20343/api
    ProxyPass /xcode/socketio http://127.0.0.1:20300 retry=0 timeout=30
    ProxyPassReverse /xcode/socketio http://127.0.0.1:20300
</IfModule>

Interestingly /xcode/api/ requests are signed using the correct certificate and thus are accepted by any client. (You can test it by accessing your Xcode server by adding /xcode/api/integrations after your server's URL. This is just a JSON webservice. If your server's certificate is signed by a valid authority it will be accepted without any problems.)

This leads to my two step solution (Assuming your server is behind a router/firewall):

1. Redirect Public TCP ports 20300, 20343 to private TCP port 443 in your firewall/router This way, the webservice requests are forwarded to the Xcode Server that is using the correct certificate that is automatically accepted by the device. Xcode also uses ports 20344 & 20345, but leave those for other connections. Note: these changes can be overwritten if you have OS X server managing an Apple Router and re-toggle XCode under "Public Services".

2. Proxy /api and /socketio request to the local webservice The server does not known /api so add the following lines to the mod_proxy.c section in your httpd_xcs.conf:

ProxyPass /api https://127.0.0.1:20343/api retry=0 timeout=30
ProxyPassReverse /api https://127.0.0.1:20343/api
ProxyPass /socketio http://127.0.0.1:20300 retry=0 timeout=30
ProxyPassReverse /socketio http://127.0.0.1:20300

Final thoughts/notes:

I'm not sure if we should consider the webservice is using a self-signed certificate a bug. It might as well be an issue that Apple is providing an incorrect configuration file. Maybe stripping off the /xcode part at the ProxyPass lines instead of adding them would be sufficient.

1
votes

Had SSL certificate installed on OS X Server, got this problem after updating OS X. Fixed it by re-adding p12 certificate in Server app -> Certificates, then reboot. Certificate can be imported from Keychain app.

0
votes

I had this same problem on two different Xcode Server installations.

On the first installation, the Xcode Server was behind a firewall/proxy. So port 20343 could simply not be reached. I fixed that by proxying https://externalname.com:20343 to https://internal.ip.address.here:20343

This is the nginx config that I used for that:

server {
  listen 20343;
  server_name xcode.foo.com;

  access_log /var/log/nginx/xcode.access.log;
  error_log /var/log/nginx/xcode.error.log;

  ssl on;
  ssl_certificate /root/foo_com/foo_com.crt;
  ssl_certificate_key /root/foo_com/foo_com.key;

  ssl_session_timeout 5m;

  ssl_protocols SSLv3 TLSv1 TLSv1.1 TlSv1.2;
  ssl_ciphers ALL:!ADH:!aNULL:!PSK:!MD5:!AES:!EXPORT:+HIGH:!MEDIUM:!LOW:!SSLv2;
  ssl_prefer_server_ciphers on;
  ssl_session_cache shared:syncserver:4m;

  location / {
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Server $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_redirect off;
    proxy_read_timeout 120;
    proxy_connect_timeout 10;
    proxy_pass https://192.168.0.8:20343;
  }
}

On a second install, where my Xcode server was on a fully public IP, the problem was actually different: for some reason my device did not correctly accept the root certificate that Xcode Server uses for the Node.js server that runs on port 20343.

You can find my solution for that case here: Xcode bot install link request time out