Sorry should have said that, yes cpvm is the more important one to restart for your issue. Ssvm also uses cert for transfers.
________________________________ From: Andrija Panic <andrija.pa...@gmail.com> Sent: Friday, 2 February 2018 3:13 pm To: users Cc: Paul Angus; Benjamin Naber Subject: Re: Failing to enable SSL/HTTPS on console proxy vm You need to put all certificates in the chain in the GUI dialog, in 4.8 this is supported in GUI, made easy (god forgive doing the same work in 4.5 :) I don't remember ATM, but I believe also restarting MGMT was required or advises, since it build up the ssl/trust chan (of whaever...) so make sure you better do than don't do it (I hardly remember that MGMT would not start due to some hacks I did with SSLs back in the days) paul.an...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue On 2 February 2018 at 15:10, Ugo Vasi <ugo.v...@procne.it<mailto:ugo.v...@procne.it>> wrote: Hi Paul, do I have to destroy console-proxy too? Could the problem be caused by certificates' chain? I've got two intermediate certificates between the root and the leaf one, could this cause problems? Thanks On 02/02/2018 13:18, Paul Angus wrote: Hi Ugo, Have you destroyed your sec storage VM and let CloudStack recreate it. A stop-start isn't usually enough to reconfigure certificates. paul.an...@shapeblue.com<mailto:paul.an...@shapeblue.com> www.shapeblue.com<http://www.shapeblue.com> 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue -----Original Message----- From: Ugo Vasi [mailto:ugo.v...@procne.it<mailto:ugo.v...@procne.it>] Sent: 02 February 2018 11:37 To: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>; Benjamin Naber <benjamin.na...@coders-area.de<mailto:benjamin.na...@coders-area.de>> Subject: Re: Failing to enable SSL/HTTPS on console proxy vm Hi Ben, I'm sure that the DNS is resolving the right IP (aaa-bbb-ccc-ddd.domain.com<http://aaa-bbb-ccc-ddd.domain.com> -> aaa.bbb.ccc.ddd), I tried with wget using the same src of iframe (masquerade log): $ wget https://123-123-123-123.domain.com/ajax?token=...(snipped) --2018-02-02 10:24:23-- https://123-123-123-123.domain.com/ajax?token=... Resolving 123-123-123-123.domain.com<http://123-123-123-123.domain.com> (123-123-123-123.domain.com<http://123-123-123-123.domain.com>)... 123.123.123.123 Connecting to 123-123-123-123.domain.com<http://123-123-123-123.domain.com> (123-123-123-123.domain.com<http://123-123-123-123.domain.com>)|123.123.123.123|:443... here the command hangs until a timeout. On 02/02/2018 11:43, Benjamin Naber wrote: Hi Ugo, you need a DNS Record for the public ip address the consoleproxy has beed allocatet. should be look like this: 80-190-44-22.domain.com<http://80-190-44-22.domain.com> otherwise the iframe denied loading in case of ssl error. In Global setting "Console proxy url domain" set *.domain.com<http://domain.com> restart management server and it should work. Kind Regards Ben Ugo Vasi <ugo.v...@procne.it<mailto:ugo.v...@procne.it>> hat am 2. Februar 2018 um 11:26 geschrieben: Hi all, I had the same problem installing the wildcard certificate. I tried to set the consoleproxy.url.domain in global settings but now the console interface inside the iframe does not respond... The dns record are OK. On 16/06/2016 18:10, Andy Dills wrote: I have this working perfectly. Couple of key things that are not mentioned in the documentation: - You need to set consoleproxy.url.domain to *.domain.com<http://domain.com> for whatever domain you're using. Do this before re-uploading your SSL certificate. The SSL upload dialogue doesn't set this value as it should. - You need a wildcard certificate for that domain. Assuming you setup the proper DNS records, it should then work. I'm open to follow up questions if anybody is struggling with this. Thanks, Andy Sent from my iPhone On Jun 16, 2016, at 12:01 PM, Will Stevens <wstev...@cloudops.com<mailto:wstev...@cloudops.com>> wrote: We have been having issues with this for as long as I can remember (on both ACS and CCP). In order to get it to work you have to 'trust unsafe scripts' or whatever by clicking the shield in the URL bar in the top right (maybe that is chrome). I don't know that there is a solution, but if there is, I am all ears... *Will STEVENS* Lead Developer *CloudOps* *| *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com<http://cloudops.com> *|* tw @CloudOps_ On Thu, Jun 16, 2016 at 11:54 AM, Nux! <n...@li.nux.ro<mailto:n...@li.nux.ro>> wrote: Hi, Is there any particular voodoo involved in getting the $subject to work correctly on 4.8.0? I've uploaded the Comodo wildcard cabundle, crt and key in the Infrastructure page, the systemvms have rebooted. They came back fine and nothing dodgy in the logs, but when I open the console of a VM Firefox will say there are insecure contents loaded and will not display the terminal ajax thingy. View source shoes an iframe linking http://1.2.3.4 instead of https://1-2-3-4.wildcarddomain.tld. Apache HTTPD and Tomcat had no issues with these certs. Is there something that I am missing? Thanks -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro<http://www.nux.ro> -- *Ugo Vasi* / System Administrator ugo.v...@procne.it<mailto:ugo.v...@procne.it> <mailto:ugo.v...@procne.it<mailto:ugo.v...@procne.it>> *Procne S.r.l.* +39 0432 486 523<tel:%2B39%200432%20486%20523> via Cotonificio, 45 33010 Tavagnacco (UD) www.procne.it<http://www.procne.it> <http://www.procne.it/> Le informazioni contenute nella presente comunicazione ed i relativi allegati possono essere riservate e sono, comunque, destinate esclusivamente alle persone od alla Società sopraindicati. La diffusione, distribuzione e/o copiatura del documento trasmesso da parte di qualsiasi soggetto diverso dal destinatario è proibita sia ai sensi dell'art. 616 c.p., che ai sensi del Decreto Legislativo n. 196/2003 "Codice in materia di protezione dei dati personali". Se avete ricevuto questo messaggio per errore, vi preghiamo di distruggerlo e di informare immediatamente Procne S.r.l. scrivendo all' indirizzo e-mail i...@procne.it<mailto:i...@procne.it> <mailto:i...@procne.it<mailto:i...@procne.it>>. -- *Ugo Vasi* / System Administrator ugo.v...@procne.it<mailto:ugo.v...@procne.it> <mailto:ugo.v...@procne.it<mailto:ugo.v...@procne.it>> *Procne S.r.l.* +39 0432 486 523<tel:%2B39%200432%20486%20523> via Cotonificio, 45 33010 Tavagnacco (UD) www.procne.it<http://www.procne.it> <http://www.procne.it/> Le informazioni contenute nella presente comunicazione ed i relativi allegati possono essere riservate e sono, comunque, destinate esclusivamente alle persone od alla Società sopraindicati. La diffusione, distribuzione e/o copiatura del documento trasmesso da parte di qualsiasi soggetto diverso dal destinatario è proibita sia ai sensi dell'art. 616 c.p., che ai sensi del Decreto Legislativo n. 196/2003 "Codice in materia di protezione dei dati personali". Se avete ricevuto questo messaggio per errore, vi preghiamo di distruggerlo e di informare immediatamente Procne S.r.l. scrivendo all' indirizzo e-mail i...@procne.it<mailto:i...@procne.it> <mailto:i...@procne.it<mailto:i...@procne.it>>. -- Andrija Panić
