I'm testing LoRa Edge™ Tracker Reference Design joining through Join Server. I configured my device on both the Semtech Network Server and Join server. I saw the device joined successfully and saw uplink packet. Then I tried to enable "Wrapping Key" on KEYS AND CREDENTIALS from “Lora Cloud Device Join”, which can keep my AppSKey confidential, my same device cannot join then. Got some error information, but it's not that helpful:
"error": "join-server returned error: response error, code: , description: ",

If I disable it, it will join again. Anybody can help?

The join-request is forwarded by the network-server to the join-server, which sends back the session-keys to the network-server. On the first uplink, the network-server forwards the AppSKey to the application-server (so that the application-server can encrypt/decrypt the app payloads). Within the LoRaWAN Backend Specs, there is an option to encrypt the NwkSKey and / or AppSKey. This is useful for example when the network-server and application-server are not operated by the same organization. By configuring a wrapping key known by the application-server and join-server, the organization operating the network-server is unable to decrypt the app payloads, keeping all network and application data encrypted separately with different keys.

For the Semtech Network Server we are both hosting the network-server and application-server together; it would not make a difference from a security perspective as both the NS and AS are operated by Semtech and we would need to know the wrapping-key for both to handle the decryption and encryption of the payloads in order to make the various integrations work.

So, for an enterprise implementation where you have a network-server which is totally differentiated from the application-server, this would work fine (having one key for NS and then your own wrapping key for the AS). For instance, if I used the ChirpStack NS and then perhaps another AS (or some other combination).

But for the hosted Semtech Network Server, we have opted to host both the NS and AS and therefore need to be able to see all of the traffic coming in to route correctly for the application integrations. Since both the NS and AS need to see the data to correctly route, ChirpStack doesn’t support the key wrapping, as it would still have to decrypt it and handle the overhead that comes with it while storing the data in the same backend, which defeats the purpose of having separate keys.

The error message that you are getting isn’t very helpful, though. I agree that it could be better, and we’ll see if perhaps we can get ChirpStack/Semtech Cloud Services to address this in their next release.