As a part of deprecating realhostip.com (explanation of realhostip here), we wish to provide ability for HTTP and HTTPS based console proxy access. HTTPS with custom (wildcard) domain is already supported, as documented here : http://support.citrix.com/article/CTX133468
The new implementation adheres to the following :
Console proxy will support following working modes
We will use the configured console proxy suffix domain name to identify following console proxy working modes. The config parameter is "consoleproxy.url.domain".
if console proxy suffix domain is “empty” —> work mode 1
if console proxy suffix domain is configured as *.somedomain.com —> work mode 2 (PLEASE note that * is the actual asterisk character here)
if console proxy suffix domain is configured as xyz.somedomain.com —> work mode 3
When we give out console access URL to client, the URL should be configured per current console proxy working mode
work mode 1 —> http://<ip>.<ip>.<ip>.<ip>/xxxxxx
work mode 2 —> https://<ip>-<ip>-<ip>-<ip>.somedomain.com/xxxxx
work mode 3 —> https://xyz.somedomain.com/xxxxx
SSVM refers to realhostip.com to form some URLs - like URLs for template download, extract and copy. SSVM already supports the ability to turn on or off SSL support, via the parameter secstorage.encrypt.copy.
Configuration parameter secstorage.ssl.cert.domain, as per https://issues.apache.org/jira/browse/CLOUDSTACK-2940 , is used to configure for SSL case. To keep things consistent with console proxy, the configuration parameter expects a value of the form "*.somedomain.com" for customization.
The Java Keystore for SSVM agents is updated as well when a SSL certificate is uploaded via the UI or APIs.
Implementation change here is minimal, of handing out the correct domain URL for the above mentioned tasks.
For fresh installs, console proxy will, by default, work in HTTP mode. Same is the case with SSVM.
Previously, only wildcard-based custom domains (workmode 2 above for Console Proxy, and secstorage.ssl.cert.domain for SSVM) were supported. Hence, the DB upgrade script maintains consistency by converting the existing domain values say, somedomain.com, to *.somedomain.com. People who wish to use the new features may modify this value to suit their needs after the upgrade.
As of now this is how it works and will need update to KB:
consoleproxy.url.domain
(a) if empty use HTTP (NEW)
(b) if *.somedomain.com , use HTTPS like today. Change being instead of specifying somedomain.com, we will explicitly need the wildcard
(c) if xyz.somedomain.com, use HTTPS with a LB pointing xyz…. To console proxy IPs (NEW)
NOTE : The Load Balancer case is not implemented fully in the current release. Ideally, CS should have the functionality of configuring LB and the console proxy IPs automatically, in such a way that needs no change on LB to map the IPs. This is not implemented yet.
To test this case, one can set-up a LB with a mapping to an already running console proxy IP or IPs, and test the console access.
secstorage.encrypt.copy to turn on SSL.
secstorage.ssl.cert.domain to customize the domain name. If domain is empty or null, the above SSL setting will be ignored and a warning will be thrown.
Provide the full certificate path for the System VMs if you are using a certificate from
an intermediate CA. The certificate path begins with the certificate of that certifying entity, and each certificate in the chain is signed by the entity identified by the next certificate in the chain. The chain terminates with a root CA certificate. For browsers to trust the site's certificate, you must specify the full chain: site certificate, intermediate CA, and root CA. Use the uploadCustomCertificate API calls for each level of the
chain. The certificate and private key parameters need to have the full text in PEM encoded format. For example: 'certificate':'-----BEGIN CERTIFICATE----- \nMIIDYTCCAkmgAwIBAgIQCgEBAQAAAnwasdfKasd
TIP : The information in this blog post is good to have, for real-life SSL scenarios : http://www.chipchilders.com/blog/2013/1/2/undocumented-feature-using-certificate-chains-in-cloudstack.html