You could probably hack this - if you only provided enough IPs for your System VMs so that it’s IP wouldn’t change, you could register the SSL cert for that specific FQDN.
Seems like it should be possible to have the console proxy run in http-only, then put an TLS endpoint in front of it (haproxy, netscaler etc) but I suspect a few code tweaks would be necessary. But no, no good out-of-the box solution. John > On Feb 19, 2016, at 8:38 AM, Nux! <n...@li.nux.ro> wrote: > > So there's no way around it, thanks Stephan. :-) > > -- > Sent from the Delta quadrant using Borg technology! > > Nux! > www.nux.ro > > ----- Original Message ----- >> From: "Stephan Seitz" <s.se...@secretresearchfacility.com> >> To: users@cloudstack.apache.org >> Sent: Friday, 19 February, 2016 16:21:37 >> Subject: Re: HTTPS for console VM, without the wildcard DNS > >> Hi, >> >> well, one could manage huge hosts-files ;) >> >> but seriously, you just need a dns-name / wildcard-certificate for a >> domain you trust. If your customers trust your certificate AND your dns >> - maybe because of dnssec - you don't need that for every customer. >> >> To keep things off our full-featured nameservers, we did a >> zone-delegation for a cloud-subdomain.domain.tld to a small bind which >> holds just a flat zone-file wich contains all of the a-b-c-d to a.b.c.d >> A-Records. >> This took us maybe one hour and a 3-liner in bash. >> >> cheers, >> >> - Stephan >> >> Am Freitag, den 19.02.2016, 16:07 +0000 schrieb Nux!: >>> Hi, >>> >>> Last I enabled HTTPS for the console VM, I had to get a *.domain.tld and a >>> wildcard certificate to match that. >>> Is there no other way to enable SSL without the wildcard DNS bit? >>> It adds a bit of overhead having to setup DNS infra for the customer just so >>> he's able to securely access his cloud. >>> >>> >>> -- >>> Sent from the Delta quadrant using Borg technology! >>> >>> Nux! >>> www.nux.ro
