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

### 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 #12486
- Related to #12488
- Related to #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

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:/// 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)
```

- 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:/// 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.