Xcode Server 13.1/13.2b on 12.1 (21C5021h) Fails While Configuring SSL Certificates

https://feedbackassistant.apple.com/feedback/9704771 ( XCode 13 Server installation failed with libre ssl certificate error ) https://feedbackassistant.apple.com/feedback/9704765

Recent Similar Reports: None Resolution: Open

What about FB9732898 FB9785825 are them still with no recent similar reports and open too?

Same here with Xcode 13.2.1. FB9828542

Apple, you need to stop abandoning things before we all have access to a replacement.

Same problem here on multiple iMacs. Bought a new Mac mini M1, same thing. I'm completely blocked now. How are people setting up CI/CD with current versions of Xcode on macOS like this?

Same problem here... with iMac 4k and Xcode 13.2.1 (13C100) on macOS Monterey 12.1. What is going on? Any solution to solve it?

Same problem, even on macOS Monterey 12.2 beta 2 (21D5039d), Xcode 13.2.1 (13C100)

Not sure if this will resolve this particular issue, but the same error in a different context was resolved by switching the SSL backend in curl to Apple native Secure Transport by setting CURL_SSL_BACKEND=SecureTransport.

Same problem with a fresh Mac Mini Monterey and Xcode 13 installation, as well as an M1 Mac with the same configuration. Resetting Xcode Server did not work at all. Submitted a feedback to Apple.

2 months now. TWO months.

I was sent the feedback by Feedback Assistant.

Do you have reinstalled macOS?

I have solved this problem. This is a bug. The bug from macOS 12.

Why I am saying this?

I tried to wipe all the disks and reinstall macOS 12.2, then install Xcode, start Xcode Server, crash on the same error.

Finally, in retrospect, my M1 computer was upgraded from macOS 11, and when it was activated on macOS 11, due to misoperation. This resulted in the need to execute the 'xcscontrol —reset' command in macOS 12. So the reason for this problem is the reason for the system.

Last night, the same use of erasing disks, installing macOS 11.6, then installing Xcode all came back together. In the coming year, I don't plan to upgrade to the latest system.

I feedback this bug to Apple, hoping that someone can solve this problem quickly.

My problem persists.

I can't start a local Xcode Server from the Xcode Preferences window.

Failure (vanilla startup)

I've tried both a user account created for the purpose and my admin account. The progress text reaches "Confiuring SSL Certificates…", suspends for a few seconds, then displays an alert with the same sort of content others report, apparently a printout of the NSError with human-readable id:

Could not export API server SSL certificate: Error Domain=XCSSecurity Code=-1 "OpenSSL: Error decrypting key, 

followed by a stack dump of the source files and lines where the error was thrown. (Colorizing the plain text was not my idea.)

xcscontrol

As suggested on StackOverflow, I tried sudo xcscontrol --reset from the command line. It exited without error. No change.

Another reply to that SO question suggested deleting /Library/Developer/XcodeServer/. After quitting Xcode, I did, then restarted Xcode. Same problem.

Keychain xcsd

I tried xcscontrol --initialize --build-service-user xcodeuser. This resulted in a dialog box asking for the password to a keychain named "xcsd". A user on that stackoverflow exchange reported finding that keychain in Keychain Access, it's not in mine. The System.keychain contains an "Identity Preference" named com.apple.dt.XCSBuilder, which expired in mid-2021. I'm not certain enough to try deleting it. Dead end.

xcsd turns out to be a launch daemon embedded in Xcode.app. It embeds a load of JavaScript, much of it Node.js.

It also embeds a bash script named create_keychains. It does create an xcsd keychain. It's just a few lines, but I'm not eager to fool with it — especially not knowing what's in $XCSSECURITY_PATH.

TEST_PATH=/tmp/XCSTest
mkdir -p $TEST_PATH

echo "repositories" > $TEST_PATH/RepositoryKeychainSharedSecret
"$XCSSECURITY_PATH" keychain-create -k "$TEST_PATH/Repositories.keychain" -m "$TEST_PATH/RepositoryKeychainSharedSecret"

echo "xcsd" > $TEST_PATH/XCSDKeychainSharedSecret
"$XCSSECURITY_PATH" keychain-create -k "$TEST_PATH/xcsd.keychain" -m "$TEST_PATH/XCSDKeychainSharedSecret"

Configuration

• Xcode 13.2.1 (13C100)
• macOS 12.1 (21C52) Monterey
• MacBook Pro M1 (late 2020)
• 1 TB storage free
• memory pressure 50–60%, which seems typical
• CPU near-idle with short runs near-saturated
• xcode-select is pointed to /Applications/Xcode.app, which is the only instance of Xcode on the machine.

(Gosh, maybe I ought to report this to Feedback.)

Same problem here after updating a fully running Xcode Server with Xcode 12.1 on Big Sur to Xcode 13.2.1 on Monterey.

First the upgrade procedure asked for a "xcsd" keychain password that I don't have, after resetting the Xcode Server (xcscontrol --reset) the already mentioned SSL error occurs.

Feedback sent: FB9857290

I am monitoring this thread for quite some months now. Have I overlooked the workaround? No: "put this certificate in " or "make a symlink from to ".

Since October I am missing my third build agent Mac Mini, because I had to update OSX in order to install Xcode 13 and back then Big Sur wasn't available anymore so I installed Monterrey. The other two agents thankfully are still on Big Sur and can do "their work".

I thought it might only be a matter of weeks until the next release of Monterrey or Xcode.

Nothing and also no perspective. Does that mean Xcode Server is dead? Nobody cares? No reaction from Apple whatsoever? Apparently nobody uses Xcode Server or at least not enough people, so that Apple would care. Is it time to move on to another solution for my CI/CD?

And no, Xcode Cloud is not an option for companies, who do not grant access to their repositories to third parties without signing an NDA. Which is pretty common in our industry. At least amongst the bigger companies.

The 3rd Build Agent is now sitting there collecting dust. Really Apple? Not even a workaround? Sad

Same problem after updated to macOS Monterey 12.2 (21D49), Xcode 13.2.1 (13C100)