Thank you for your findings and sharing experiences! So what i got from your post is that
a) you didn't got the native ssl encryption up either up till now (limited time) b) you are using a set up with an resverse proxy beforehand which is taking care of the ssl - encyption c) you are actually facing challenges with the console proxy as you didn't had time to configure encryption for the CPVM - and i gues SSVM, too Which is quiet a 'bummer' as we were planning to get cloudstack into an productive environment. Maybe one of the other readers here may add something regarding the natively provided solution of cloudstack for using ssl - connections... ? Am Mi., 15. Sept. 2021 um 23:41 Uhr schrieb Darren Cole <[email protected]>: > I have two cloudstack clusters I installed and manage. > One is my personal two node cluster, and the other is an experimental 5 > node cluster for work. > These are both side projects, so time configuring and managing them is > limited. > > In both cases I configured an Apache proxy in front of cloudstack's > webinterface on 443. > My personal cluster is using a letsencrypt.com cert loaded into Apache. > The work cluster is using a self-signed cert load into Apache for now > (when not experimental a real cert of some sort will be used). > I have configured Clodustack management to only listen on loopback (except > when I need consoleproxy access) > > The problem with that is then consoleproxy default configuration breaks. > Consoleproxy default to non-ssl and ajax loading of non-ssl connections in > an ssl connection is...well problematic. > Since both Cloudstack's are side projects I have not gotten around to > configuring consoleproxy to use ssl yet, but it is on the list. > Until I get time to get consoleproxy using ssl, I've changed Cloudstack's > management configuration to listen beyond just the loop back address when > consoleproxy access is actually required. > > I tried loading various certs into Cloudstack management to get the > webinterface to use ssl but it never worked. > I ran out of time to figure out what I was missing, so I put an Apache > proxy in front of it. > > Darren > -- > This e-mail is confidential. Any distribution, use or copying of this > e-mail or the information it contains other than by the intended recipient > is forbidden. If you are not the intended recipient, please advise the > sender (by return e-mail or otherwise) immediately and delete this e-mail. > > ----- Original Message ----- > From: "Vash X" <[email protected]> > To: "users" <[email protected]> > Sent: Tuesday, September 14, 2021 10:18:32 AM > Subject: Problems setting up HTTPS on CS Managementserver GUI / > recommadations relizing > > Hi, > > at the moment I am trying to setting up https - access for the management > server with my own certificates. Sadly i wasn't successfull until now. > OS: Ubuntu 20.04 > Standard Cloudstack > Basically i was following the documentation ( > > http://docs.cloudstack.apache.org/en/latest/installguide/optional_installation.html#ssl-optional > ) > as well as following guide from shapeblue ( > https://www.shapeblue.com/securing-cloudstack-4-11-with-https-tls/) for > setting up https for the GUI. > > At the moment i am stuck, as i didn't really have clue where and how to > proceed onwards, as i am not finding any problems, warinings or errors in > the cloudstack log's. > Usage of netstat shows, that currently no service is listening on port > 8443. > > Which leads me to a assumption that i maybe messed up access-priviledges > for the actual keystore-file, as the server.properties noted sais, that the > https configuration will only be used when the keystorefile exists and is > readable by the managementserver. > Therefore which permissions are normally used for the keystore to be > accessed by the management server? > > As the documentation states, that more or less every site has it's own > practices on providing webservices to actual users, > i would like to ask for some experiences with different appoaches? > Till now i "stumbled" over some ways the set up a reverseproxy based on > nginx / apache "in front" of the actual CS-Management WebServer, which > shall take care of the certificate handling. Another idea i have read on a > side would be to "by pass" the CS-Management Webserver, targetting directly > to the "root"-volume. Which seems to be a aventures appoach... > > So i am highly interested in your approaches and experiences regardning > this topic. > > Thanks in advance! >
