My certificate issue is with 4.14. When I have a certificate using SAN the UI
doesn't load. When I have a certificate using just the CN as FQDN the UI loads.
Mike
-----Original Message-----
From: Andrija Panic <andrija.pa...@gmail.com>
Sent: Friday, August 14, 2020 7:04 AM
To: users <users@cloudstack.apache.org>
Cc: Rafael del Valle <raf...@livelens.net>
Subject: Re: RE: Configuring HTTPS for UI
Mike are you trying on 4.14 or older build?
I believe I've just seen an issue on 4.14.
Best,
On Mon, 10 Aug 2020 at 17:12, Corey, Mike <mike.co...@sap.com> wrote:
> Thanks for the feedback Rafael,
>
> When I use a certificate created with the FQDN as the CN, and with
> DNS:<shortname> and/or IP:<ip address> in the SubjectAlternate piece of the
> CNF file - https: UI doesn't load.
>
> When I use a certificate created with the FQDN as the CN only - the https:
> UI loads with the valid certificate.
>
> If I understand your suggestion the CSR field CN should be a description.
> The SubjectAlternateName fields should be DNS: <FQDN>, DNS:<shortname> ???
>
> Mike
>
>
>
> -----Original Message-----
> From: Rafael del Valle <raf...@livelens.net.INVALID>
> Sent: Friday, August 7, 2020 4:17 PM
> To: users@cloudstack.apache.org
> Subject: Re: RE: Configuring HTTPS for UI
>
> Hi Mike,
>
> do you have the non-working certificates to have a look?
>
> We automated certificate generation for our corporate CA with ansible some
> time ago, we have a intermediate CA which is kind of our in-house lets
> encrypt for our private cloud.
>
> Did you remember to prefix the Alt Names with "DNS:" ?
>
> About a year ago webkit browsers started requiring Alt-Name extension and
> would not verify the site if only CN was used.
>
> I had a look at our code and we now we use a textual description on CN,
> such as: "Support Center LBS" and the like, with AltNames for each
> entry-point domain prefixed with DNS:
>
> We generate the CSRs like this, and we wrote a python plugin for the
> signature:
>
>
> - name: "Generate {{pvz_ca_certdesc}} certificate request"
> openssl_csr:
> path: "{{pvz_ca_certhome}}/{{pvz_ca_certname}}.csr"
> privatekey_path: "{{pvz_ca_certhome}}/{{pvz_ca_certname}}.pem"
> country_name: "{{pvzcloud.cert.country_name}}"
> organization_name: "{{pvzcloud.cert.organization_name}}"
> organizational_unit_name: "{{pvzcloud.cert.organizational_unit_name}}"
> email_address: "{{pvzcloud.cert.email_address}}"
> common_name: "{{pvzcloud.cert.organization_name}} {{pvz_ca_certdesc}}"
> basic_constraints_critical: yes
> basic_constraints:
> - "CA:FALSE"
> key_usage:
> - digitalSignature
> - nonRepudiation
> - keyEncipherment
> subject_alt_name: "{{ pvz_ca_certdomains | map('regex_replace',
> '^(.*)$', 'DNS:\\1') | list }}"
> group: "{{pvz_ca_group}}"
> owner: "{{pvz_ca_owner}}"
>
>
>
>
>
> Hope this helps...
> R.
>
> On Fri, 2020-08-07 06:02 PM, "Corey, Mike" <mike.co...@sap.com> wrote:
> >
> One thing that came up. When I use Subject Alternative Names in my CSR,
> the 8443 url doesn't work for either names I have in the cert. However,
> using just the vanilla CSR with FQDN works fine.
> >
> > Is that something with the openssl configuration file I have
> misconfigured, the type of cert I'm getting from my corporate CA, or can
> jetty(java, tomcat?) only support the single commonname cert?
> >
> > Thanks!
> >
> > Mike
> >
> > -----Original Message-----
> > From: Corey, Mike " target="_blank"><mike.co...@sap.com>
> > Sent: Thursday, August 6, 2020 3:07 PM
> > To: users@cloudstack.apache.org
> > Subject: [CAUTION] RE: Configuring HTTPS for UI
> >
> > Thanks for the feedback.
> >
> > I followed the procedures found here:
> https://www.shapeblue.com/securing-cloudstack-4-11-with-https-tls/
> >
> > For good measure I did add rule:
> > iptables -I INPUT 1 -p tcp -m tcp --dport 8443 -j ACCEPT
> >
> > Note I received an error regarding this line in the web.xml file:
> > <url-pattern>*</url-pattern>
> >
> > I needed to change it to <url-pattern>*.</url-pattern> for the error to
> go away and the UI to start.
> >
> >
> >
> >
> > -----Original Message-----
> > From: Andrija Panic " target="_blank"><andrija.pa...@gmail.com>
> > Sent: Wednesday, August 5, 2020 11:29 AM
> > To: users " target="_blank"><users@cloudstack.apache.org>
> > Subject: Re: Configuring HTTPS for UI
> >
> > Hi Mike,
> >
> > not sure what to docs say (haven't read that part recently), but the blog
> > page should suffice (well, I see that github issue with 4.14 and SSL -
> > haven't tested myself, so can't confirm/deny the issue).
> >
> > Just follow the blog page (no direct jetty modification needed) - and let
> > us know if that works (pay attention to the firewall...)
> >
> > Regards,
> >
> > On Wed, 5 Aug 2020 at 16:37, Corey, Mike " target="_blank"><
> mike.co...@sap.com> wrote:
> >
> > > Thanks Andrija,
> > >
> > > I came across that link in my search, but the Jetty link in the
> > > instructions takes me to a page that says the version is End of Life.
> I
> > > wasn't sure if the Jetty piece had to be configured or I just had to
> do the
> > > CloudStack portion. Do I have to modify the Jetty piece as described
> in
> > > the link in item 1 below? If so, what is the path to the Jetty
> > > configuration files where the SslSocketConnector is configured?
> > >
> > > Just to be clear of the process:
> > > 1 - modify the Jetty according to
> > > http://wiki.eclipse.org/Jetty/Howto/Configure_SSL#Configuring_Jetty
> > > 2 - Combine key, cert, subroot, root certs into one cert.
> > > 3 - Convert cert to pkcs12 format
> > > 4 - Create and copy to pkcs12 keystore
> > > 5 - modify server.properties with keystore info
> > > 6 - modify the 8080 to 8443 redirect
> > > 7 - restart cloudstack-management
> > > 8 - BOOM hit https://mycloudstack:8443/client without issue
> > >
> > >
> > > At first, I thought I had ran into the issue described here:
> > > https://github.com/apache/cloudstack/issues/4199 But, maybe I just
> > > haven't completed the process if I have to do something to Jetty first.
> > >
> > > -----Original Message-----
> > > From: Andrija Panic " target="_blank"><andrija.pa...@gmail.com>
> > > Sent: Wednesday, August 5, 2020 5:14 AM
> > > To: users " target="_blank"><users@cloudstack.apache.org>
> > > Subject: Re: Configuring HTTPS for UI
> > >
> > > Hi Mike,
> > >
> > > in production, you might want to do the SSL offloading on the load
> > > balancer, but yes, you can also setup SSL on the Jetty as well -
> please see
> > > the article
> > > https://www.shapeblue.com/securing-cloudstack-4-11-with-https-tls/
> (skip
> > > the first part which describes securing system VMs with SSL)
> > >
> > > Best,
> > > Andrija
> > >
> > > On Tue, 4 Aug 2020 at 20:47, Corey, Mike " target="_blank"><
> mike.co...@sap.com> wrote:
> > >
> > > > Hi,
> > > >
> > > >
> > > >
> > > > I’m trying to figure out how to use https or 8443 with an internally
> > > > signed certificate and chain for the UI. The latest documentation
> only
> > > has
> > > > the below snippet. I’ve created my internally signed certificate,
> root,
> > > > and intermediary cert and I believe I’ve done all the imports into my
> > > > keystore using keytool correctly. I’ve also modified the
> > > server.properties
> > > > with the correct jks location and password as directed by the
> > > documentation.
> > > >
> > > >
> > > >
> > > > Older versions of CloudStack documentation reference doing something
> with
> > > > Jetty, but the link to the reference is for out of life versions. I
> > > don’t
> > > > see any messages in the logs pertaining to TLS, SSL, 8443, etc. Is
> there
> > > > more to this process than documented?
> > > >
> > > >
> > > >
> > > > *SSL (Optional)*
> > > >
> > > > CloudStack provides HTTP access in its default installation. There
> are a
> > > > number of technologies and sites which choose to implement SSL/TLS.
> As a
> > > > result, we have left CloudStack to expose HTTP under the assumption
> that
> > > a
> > > > site will implement its typical practice.
> > > >
> > > > CloudStack 4.9 and above uses embedded Jetty as its servlet
> container.
> > > For
> > > > sites that would like CloudStack to terminate the SSL session, HTTPS
> can
> > > be
> > > > enabled by configuring the https-related settings in CloudStack
> > > management
> > > > server’s server.properties file at /etc/cloudstack/management/
> location:
> > > >
> > > > *# For management server to pickup these configuration settings, the
> > > > configured*
> > > >
> > > > *# keystore file should exists and be readable by the management
> server.*
> > > >
> > > > https.enable=true
> > > >
> > > > https.port=8443
> > > >
> > > > https.keystore=/etc/cloudstack/management/cloud.jks
> > > >
> > > > https.keystore.password=vmops.com
> > > >
> > > > For storing certificates, admins can create and configure a java
> keystore
> > > > file and configure the same in the server.properties file as
> illustrated
> > > > above.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > *Mike Corey*
> > > >
> > > >
> > > > Technology Senior Consultant, IT CS CTW Operation & Virtualization
> > > Service
> > > > US
> > > >
> > > >
> > > > *SAP AMERICA, INC.* 3999 West Chester Pike, Newtown Square, 19073
> United
> > > > States
> > > >
> > > >
> > > > T +1 610 661 0905, M +1 484 274 2658, E mike.co...@sap.com
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > Andrija Panić
> > >
> >
> >
> > --
> >
> > Andrija Panić
> >
>
--
Andrija Panić
