Skip to content

Local template/ISO upload fails silently due to expired SSL certificate on SSVM #12490

@RosiKyu

Description

@RosiKyu

problem

Local template/ISO uploads fail silently because the SSVM uses an expired SSL certificate (expired February 7, 2017 - over 9 years ago). Modern browsers reject HTTPS requests to the SSVM without showing a clear error to the user. The upload appears to fail with a generic error 432, but the actual cause is the browser blocking the request due to certificate validation failure.
The request never reaches the SSVM at all - the browser blocks it before sending.

Related Issues

versions

CloudStack Version: 4.20.2.0
Hypervisor: XenServer
Browser: Chrome 144.0.7559.59 (64-bit) on Linux

The steps to reproduce the bug

  1. Use a fresh browser session (or clear browser data/cache) and open the dev tools
  2. Navigate to CloudStack UI → Images → Templates
  3. Click on "Upload Template from local"
  4. Fill in template details
  5. Submit the upload
  6. Observe: Upload fails with error 432, no clear indication of SSL issue
  7. Verify: Check SSVM logs - no entry for the upload (request never arrived)
  8. Workaround: Open https://<SSVM_PUBLIC_IP>/ in browser, accept certificate warning
  9. Retry upload: Now it works!

Expected Result

  • SSVM should use a valid, non-expired SSL certificate
  • OR CloudStack should provide a clear error message when SSL/certificate issues prevent uploads
  • OR the UI should warn users to accept the SSVM certificate before attempting uploads

Actual Result

  • SSVM uses a certificate that expired in February 2017
  • Browser silently blocks upload requests (no certificate warning shown for XHR requests)
  • User sees generic "error 432" with no indication of the actual cause
  • Management server logs misleading "SSVM agent not in Up state" error
  • SSVM logs show nothing - the request never arrived

Evidence

  • SSVM SSL Certificate is Expired (since 2017)
[root@mgmt1 ~]# curl -v -k https://10.0.52.202/upload/test-uuid
* Server certificate:
*  subject: O=*.realhostip.com; OU=Domain Control Validated; CN=*.realhostip.com
*  start date: Feb  3 03:30:40 2012 GMT
*  expire date: Feb  7 05:11:23 2017 GMT   ← EXPIRED 9 YEARS AGO!
*  issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certificates.godaddy.com/repository; CN=Go Daddy Secure Certification Authority; serialNumber=07969287
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
  • Without -k flag, curl fails:
[root@mgmt1 ~]# curl -v https://10.0.52.202/upload/test-uuid
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
curl: (60) SSL certificate problem: unable to get local issuer certificate
  • Browser Network Tab - Requests BLOCKED Before Reaching SSVM: Two requests to SSVM failed:
  1. "Provisional headers are shown" warning - indicates request was blocked before completing
  2. No corresponding entries in SSVM logs (request never arrived)
Request URL: https://10.0.52.202/upload/73708458-b5a9-44ae-8adf-848b6a58221a
Status: (failed)
Image Image Image
  • SSVM Received NOTHING for Failed Upload
root@s-3-VM:~# grep -i "73708458-b5a9-44ae-8adf-848b6a58221a" /var/log/cloud.log
root@s-3-VM:~#   ← No output - request never reached SSVM!
  • Apache Access Logs Empty
root@s-3-VM:~# tail -50 /var/log/apache2/ssl_access.log
root@s-3-VM:~#   ← No entries!
  • Browser Console Shows Error 432
Image
  • After Manually Accepting Certificate - Upload WORKS!
    After visiting https://10.0.52.202/ directly in browser and accepting the security warning

  • SSVM Logs now show upload received:

2026-01-21T19:29:59,472 INFO  [storage.resource.HttpUploadServerHandler] HEADER: SIGNATURE=gnUikA8l3imw7vcPg+F3Vf7LjNg=
2026-01-21T19:29:59,472 INFO  [storage.resource.HttpUploadServerHandler] HEADER: METADATA=rkiZ0wSSLCNtmXVyIjEMb0EtD7rqZ2wAHMoHynkVCSBp...
2026-01-21T19:29:59,473 INFO  [storage.resource.HttpUploadServerHandler] HEADER: EXPIRES=2026-01-21T20:29:59.270Z
2026-01-21T19:29:59,475 INFO  [storage.resource.HttpUploadServerHandler] URI: uuid=a0972001-4901-4f67-b03a-7e2e4709efd4
2026-01-21T19:31:17,968 INFO  [storage.resource.HttpUploadServerHandler] BODY FileUpload: ... filename="linux-debian-12-x86_64-gen2-v1.qcow2" ... Completed: true

What to do about it?

Option 1: Generate Valid Self-Signed Certificate
Update the SystemVM template to generate a fresh self-signed certificate on first boot, valid for a reasonable period (e.g., 10 years).

Option 2: Use HTTP for Local Uploads
Since local uploads are already happening over a potentially untrusted network (user's browser to SSVM), consider using HTTP instead of HTTPS, or making it configurable via global setting.

Option 3: Improve Error Messaging
If the upload request fails due to network/SSL issues, show a clear error message suggesting the user check the SSVM certificate or visit the SSVM URL to accept it.

Option 4: UI Pre-check
Before initiating upload, have the UI make a test request to the SSVM and guide users to accept the certificate if needed.

Workaround Before uploading templates via "Local" method:

  • Get the SSVM public IP from CloudStack (Infrastructure → System VMs)
  • Open https://<SSVM_PUBLIC_IP>/ in your browser
  • Accept the security/certificate warning
  • Return to CloudStack UI and retry the upload

Note: This workaround is session-specific and may need to be repeated after browser restart or cache clearing.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions