-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Description
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
- Related to Uploading Template / ISO from local file is getting failed intermittently #12486
- Related to Local Template/ISO Upload Fails - SSVM receives SIGNATURE=null #12488
- Related to Netty IllegalReferenceCountException causes false upload failure despite successful upload #12489
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
- Use a fresh browser session (or clear browser data/cache) and open the dev tools
- Navigate to CloudStack UI → Images → Templates
- Click on "Upload Template from local"
- Fill in template details
- Submit the upload
- Observe: Upload fails with error 432, no clear indication of SSL issue
- Verify: Check SSVM logs - no entry for the upload (request never arrived)
- Workaround: Open https://<SSVM_PUBLIC_IP>/ in browser, accept certificate warning
- 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:
- "Provisional headers are shown" warning - indicates request was blocked before completing
- No corresponding entries in SSVM logs (request never arrived)
Request URL: https://10.0.52.202/upload/73708458-b5a9-44ae-8adf-848b6a58221a
Status: (failed)
- 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
-
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.