Troubleshooting XNAT Desktop Uploader

This guide explains how to troubleshoot common connection, authentication, certificate, and upload problems when using XNAT Desktop Uploader with CNDA.

General Prerequisites to Upload Images

Account Activity Requirement

Keep Your CNDA Account Active

Your CNDA account must remain active to upload images.

Accounts are automatically disabled after 12 consecutive months without signing in to the CNDA website.

To keep your account active, sign in to CNDAopen in new window at least once every 12 months.

If your account has been disabled, email [email protected] to request reactivation.

Alias Token Authentication

XNAT Desktop Uploader and API/script users must authenticate using an XNAT alias token instead of their regular CNDA username and password.

WARNING

Alias Tokens Expire After 90 Days

Alias tokens are valid for 90 days. Once your token expires, generate a new token and update the credentials in your Desktop Uploader or scripts.

Your regular CNDA username and password cannot be used as a substitute.

Need an alias token?

Follow the instructions in Generate and Use an XNAT Alias Tokenopen in new window.

CNDA website sign-in uses WashU Key SSO. Never share your alias token password with other users or CNDA support.

Correct CNDA Server Address

The server address in XNAT Desktop Uploader must be exactly:

https://cnda.wustl.edu

There should be nothing after .edu, including slashes or additional URL paths.

Seeing Your CNDA Projects in the Application

If you cannot see your CNDA projects, or your permissions were recently updated, clearing your access cache may resolve the issue.

Clear Cache in the CNDA Website

  1. Log in to https://cnda.wustl.edu using WashU Key SSO.
  2. Click Logged in as your username in the top-right corner.
  3. Select Manage Cached Resources.
  4. Click Reset Access Cache.

Clear Cache in XNAT Desktop Uploader

  1. Open XNAT Desktop Uploader.
  2. Log in using your alias token credentials.
  3. Click the large blue MENU button in the top-left corner.
  4. Click Flush XNAT User Access Cache.

After clearing the cache, log out and back in before attempting another upload. If projects remain missing, contact CNDA support to verify permissions.

Main Symptoms of Upload Problems

Common symptoms include:

  • The upload progress bar does not move.
  • The application appears stuck while uploading or archiving.
  • The uploaded session never appears in CNDA.
  • The application cannot connect to CNDA.
  • The application reports SELF_SIGNED_CERT_IN_CHAIN or another certificate error.
  • The application rejects alias token credentials.
  • CNDA projects do not appear in the application.

Step 0 - Use Local Storage for Best Upload Performance

Uploading directly from external drives, network drives, or cloud-synchronized folders does not always fail, but using local storage generally provides better performance and helps avoid file access issues.

For the most reliable upload experience:

  1. Copy your imaging files to a local folder on your laptop or desktop.
  2. Make sure all files are fully downloaded and accessible.
  3. Start the upload using the files in that local folder.

If you experience slow uploads, stalled progress, or file access errors while using external or network storage, try uploading from a local folder instead.

Step 1 - Confirm You Can Log In to CNDA

  1. Open https://cnda.wustl.eduopen in new window in your browser.
  2. Sign in using WashU Key SSO.
  3. Confirm that you can access your account and projects.

If login works: Proceed to Step 2.

If login fails: Resolve the website authentication or account issue first.

Successful website login does not guarantee that your Desktop Uploader alias token is valid.

Step 2 - Check Desktop Uploader Configuration

  1. Open XNAT Desktop Uploader normally.
  2. Confirm that the server address is https://cnda.wustl.edu.
  3. Log in using your current alias token credentials.
  4. Confirm that you can:
    • Log in successfully.
    • View your CNDA projects.
    • Load application configuration options.
    • Reach the upload screen.
  5. A message that no anonymization configuration is available may be normal for projects without custom anonymization settings.

Connection Successful

If you can log in, see your projects, and reach the upload screen, your basic Desktop Uploader connection is working.

If the upload itself still fails or becomes stuck, continue to Step 3.

Step 3 - Check Whether the Upload Reaches CNDA

If your upload involves creating a new Subject, you can check whether XNAT Desktop Uploader successfully created it in CNDA.

  1. Open https://cnda.wustl.eduopen in new window in your browser.
  2. Sign in using WashU Key SSO.
  3. Open the destination project.
  4. Look for the new Subject created by XNAT Desktop Uploader.
  5. Check whether the Subject exists and whether an imaging session is present.

Understanding the Results

Subject Exists, but No Imaging Session Appears

The Desktop Uploader successfully created the Subject, but this does not confirm that the imaging ZIP transfer started or completed.

Continue troubleshooting the upload connection and transfer process.

No New Subject Appears

The application may have failed before creating the Subject, or your upload may be using an existing Subject.

Check whether the intended Subject already exists before assuming the upload failed.

Imaging Session Appears in CNDA

The session is visible in CNDA. Verify that the expected imaging data is present before considering the upload successful.

A missing imaging session does not automatically mean your network is blocking POST requests.

Step 4 - Test HTTPS Connectivity and Certificate Trust

Before testing POST requests, verify that your computer can establish a trusted HTTPS connection to CNDA.

These tests do not require your CNDA username, password, or alias token credentials.

Windows (PowerShell)

Open PowerShell and run:

curl.exe -sS -o NUL https://cnda.wustl.edu/

if ($LASTEXITCODE -eq 0) {
    Write-Host "CERTIFICATE TRUSTED"
} else {
    Write-Host "CERTIFICATE CHECK FAILED"
}

Linux / macOS (Terminal)

Open a terminal and run:

if curl -sS -o /dev/null https://cnda.wustl.edu/; then
    echo "CERTIFICATE TRUSTED"
else
    echo "CERTIFICATE CHECK FAILED"
fi

Understanding the Results

CERTIFICATE TRUSTED

Your computer successfully established an HTTPS connection to CNDA, and curl accepted the certificate chain.

This confirms that HTTPS connectivity and certificate validation are working for curl.

However, XNAT Desktop Uploader may use a different certificate trust store, so this does not guarantee the application will accept the same certificate.

CERTIFICATE CHECK FAILED

The HTTPS request failed. Check the error message displayed above the result.

Possible causes include:

  • An untrusted certificate authority.
  • An incomplete certificate chain.
  • Institutional HTTPS inspection.
  • DNS resolution problems.
  • VPN or firewall restrictions.
  • Network connectivity problems.

A failed test does not automatically mean CNDA has an invalid certificate.

Common Curl Error Codes

ErrorMeaning
curl: (6)DNS resolution failed
curl: (7)Connection could not be established
curl: (28)Connection timed out
curl: (35)SSL/TLS handshake failed
curl: (56)Connection interrupted or reset
curl: (60)Certificate verification failed

If you receive curl: (60), investigate the certificate chain and trusted certificate authorities.

If curl succeeds but XNAT Desktop Uploader still reports a certificate error, investigate the application's certificate trust configuration.

Do not disable certificate verification to work around a certificate error.

Step 5 - Check the CNDA Certificate in Your Browser

Some institutional networks use HTTPS inspection, which can replace certificates presented to applications. Comparing the certificate before and after logging in helps identify unexpected changes.

Check Before Logging In

  1. Open https://cnda.wustl.eduopen in new window.
  2. Do not log in yet.
  3. Click the padlock or connection information icon next to the website address.
  4. Open the certificate viewer.
  5. Confirm that your browser reports a secure connection.
  6. Record the following certificate information:
    • Issued To: Certificate subject or Common Name.
    • Issued By: Certificate issuer.
    • Valid From: Certificate start date.
    • Valid Until: Certificate expiration date.
    • SHA-256 Fingerprint: If readily available in the certificate viewer.

You do not need to open the advanced certificate details to inspect Subject Alternative Names.

Check After Logging In

  1. Sign in using WashU Key SSO.
  2. Return to https://cnda.wustl.eduopen in new window.
  3. Open the certificate viewer again.
  4. Compare the certificate information with what you recorded before login.
  5. Confirm that the certificate is the same and your browser still reports a secure connection.

Understanding the Results

Certificate Matches Before and After Login

The certificate information matches before and after logging in, and your browser reports a secure connection.

This is the expected result.

WashU Key SSO may redirect you to other websites during authentication. Compare certificates only when viewing cnda.wustl.edu.

If you recorded the SHA-256 certificate fingerprint, an exact match provides the strongest confirmation that both connections presented the same certificate.

Certificate Changes After Login

If the certificate information differs before and after login while visiting cnda.wustl.edu, further investigation may be needed.

Possible explanations include:

  • Institutional HTTPS inspection.
  • Different proxies or network paths.
  • VPN or network connection changes.
  • Legitimate certificate renewal or load balancing.

A certificate change does not automatically mean the connection is insecure, but unexpected differences should be investigated.

Contact institutional IT or CNDA support and provide the certificate information from both checks.

If the Browser Works but Desktop Uploader Fails

Even if the certificate matches before and after login, XNAT Desktop Uploader may still encounter certificate validation errors.

Browsers and desktop applications may handle certificate chains differently. For example, a browser may trust a certificate using cached or automatically retrieved intermediate certificates, while the Desktop Uploader may fail if the server does not present the complete chain.

If XNAT Desktop Uploader reports SELF_SIGNED_CERT_IN_CHAIN or another certificate error, continue to Step 6.

Do not bypass certificate warnings or disable certificate verification.

Step 6 - Troubleshoot SELF_SIGNED_CERT_IN_CHAIN

The error SELF_SIGNED_CERT_IN_CHAIN means XNAT Desktop Uploader cannot establish a trusted certificate chain for an HTTPS connection. It does not necessarily mean CNDA uses an invalid or self-signed server certificate.

Common Causes

  1. An institutional firewall or proxy performs HTTPS inspection.
  2. The application does not trust the CA used by the institution.
  3. An intermediate certificate is missing or not trusted.
  4. The application's certificate trust store differs from the operating system or browser.
  1. Run the HTTPS test from Step 4.
  2. Inspect the certificate in the browser using Step 5.
  3. Confirm the Uploader version is current.
  4. Ask whether the institution uses HTTPS inspection.
  5. Contact institutional IT if necessary.

If the browser and curl trust the certificate but the Uploader still fails, investigate the application's certificate trust configuration. Do not disable SSL verification as a permanent workaround.

Step 7 - Test HTTPS POST Requests

If HTTPS connectivity and certificate validation work, test whether authenticated POST requests can reach CNDA. A POST failure does not automatically mean POST traffic is blocked.

Windows (Command Prompt)

  1. Press Win + R, type cmd, and press Enter.

  2. Replace YOUR_ALIAS_USERNAME with the username from your current alias token:

    curl.exe -i -X POST -u YOUR_ALIAS_USERNAME https://cnda.wustl.edu/data/JSESSION

  3. When prompted, enter the password associated with your alias token. The password will not appear as you type.

Linux / macOS (Terminal)

curl -i -X POST -u YOUR_ALIAS_USERNAME https://cnda.wustl.edu/data/JSESSION

Enter your alias token password when prompted. Do not include the password directly in the command.

Understanding the Response

A successful response may include a session identifier, depending on supported authentication behavior, for example:

{"JSESSIONID":"ABC1234567890XYZ"}

Important: CNDA support should confirm that /data/JSESSION accepts alias token credentials and what response it returns before using this as a definitive success test.

ResultInterpretation
Successful authenticated responseThe tested HTTPS POST was accepted
401 UnauthorizedAuthentication failed or credentials rejected
403 ForbiddenServer or intermediary denied access
404 Not FoundEndpoint not found
curl: (35)TLS handshake problem
curl: (56)Connection interrupted or reset
curl: (60)Certificate verification failed
HTML security-blocking pageProxy or gateway may have intercepted the request

A successful POST to this endpoint does not prove large imaging uploads will work. Examine failed responses before concluding that an institutional firewall blocks POST traffic.

Step 8 - Clear XNAT Desktop Uploader Application Cache

If authentication and connectivity tests succeed but uploading still fails, clearing the cache may help.

Simple Method

  1. Open XNAT Desktop Uploader.
  2. Click the Settings Cogwheel in the top-right corner.
  3. Select Debug.
  4. Click Clear Application Cache.
  5. Completely close the application.
  6. Reopen it and retry the upload.

Alternative Method for Windows

Use this only if clearing the cache in the application does not resolve the issue.

  1. Completely close XNAT Desktop Uploader.
  2. Press Win + R.
  3. Enter %AppData%.
  4. Locate the folder XNAT Desktop Client.
  5. Rename it to XNAT Desktop Client.backup.
  6. Reopen XNAT Desktop Uploader.
  7. Remove outdated saved server connections if they remain.
  8. Add a new server: cnda.wustl.edu.
  9. Log in using your current alias token credentials.
  10. Retry the upload.

Renaming preserves a backup but may reset saved connections and preferences. Have your alias token credentials available.

Step 9 - If Uploads Still Fail

Gather the following before contacting CNDA support:

  1. Operating system: Windows, macOS, or Linux.
  2. XNAT Desktop Uploader version.
  3. Exact error message or screenshot.
  4. Whether the CNDA website works in a browser.
  5. Whether the alias token is current.
  6. Whether CNDA projects are visible.
  7. HTTPS certificate test result.
  8. POST test result, if performed.
  9. Whether connected through VPN, institutional network, or home network.
  10. Whether an empty Subject or partial session appears in CNDA.

Do not include passwords, alias token secrets, or session identifiers in screenshots or support messages.

If the Network Appears to Be Blocking Traffic

Contact institutional IT with the following message:

We are experiencing connectivity or upload problems with XNAT Desktop Uploader when connecting to https://cnda.wustl.edu.

Please investigate whether institutional firewall rules, HTTPS inspection, proxy filtering, or security software are interfering with connections or file uploads to this endpoint.

If HTTPS inspection is causing certificate validation failures, please evaluate whether an appropriate exemption can be configured for cnda.wustl.edu.

If the Problem Appears Specific to XNAT Desktop Uploader

If browser access and curl certificate validation succeed but the application fails, contact [email protected]. Include the error, operating system, application version, and troubleshooting results.

Common Error Messages

Authentication Errors

Invalid username or password: Confirm that you are using alias token credentials rather than regular CNDA login credentials.

Authentication fails after previously working: The alias token may have expired. Tokens are valid for 90 days. Generate a new one and reconnect.

Certificate Errors

SELF_SIGNED_CERT_IN_CHAIN: The application cannot establish a trusted certificate chain. Check for HTTPS inspection or differences between the application and operating system trust stores.

curl: (60) SSL certificate problem: Certificate verification failed; the CA or certificate chain may not be trusted.

schannel: CRYPT_E_NO_REVOCATION_CHECK: Windows could not complete a certificate revocation check, possibly because revocation information is inaccessible. This does not establish that POST traffic is blocked.

Connection Errors

curl: (6) Could not resolve host: DNS could not resolve the server hostname.

curl: (7) Failed to connect: The connection could not be established.

curl: (28) Operation timed out: Network restrictions, connectivity problems, or an unresponsive server may be responsible.

curl: (35) SSL connect error: The TLS handshake failed.

curl: (56) Recv failure: Connection was reset: The connection was interrupted or closed by a proxy, firewall, server, or another network component.

HTTP Errors

401 Unauthorized: Authentication was not accepted.

403 Forbidden: Access was denied by the application or an intermediary. This does not prove all POST requests are blocked.

HTML Access Denied page: A security gateway may have intercepted the request. Record details and contact institutional IT or CNDA support.

Final Notes

  • Always connect to cnda.wustl.edu.
  • Use alias token credentials for Desktop Uploader authentication.
  • Alias tokens expire after 90 days.
  • CNDA accounts are disabled after 12 months of inactivity.
  • Use WashU Key SSO for the CNDA website.
  • Keep imaging files on local storage when troubleshooting.
  • Test HTTPS connectivity and certificate trust before investigating POST requests.
  • A successful browser connection does not guarantee the Uploader trusts the same certificate.
  • A failed POST does not automatically mean POST traffic is blocked.
  • Clear application cache after checking basic connectivity and authentication.
  • Never disable SSL verification as a permanent workaround.
  • Never share alias token passwords or session identifiers.

For assistance, contact [email protected].