cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrija Panic <andrija.pa...@gmail.com>
Subject Re: RE: Configuring HTTPS for UI
Date Fri, 14 Aug 2020 12:40:28 GMT
For the record, it works fine on 4.13 and later (up to 4.11) - perhaps some
issue in newer Jetty used in 4.14 or Java 11, etc...

On Fri, 14 Aug 2020 at 14:34, Andrija Panic <andrija.panic@gmail.com> wrote:

> Usefull feedback, thanks Mike - we are taking a look into this.
>
> On Fri, 14 Aug 2020 at 14:13, Corey, Mike <mike.corey@sap.com> wrote:
>
>> 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.panic@gmail.com>
>> Sent: Friday, August 14, 2020 7:04 AM
>> To: users <users@cloudstack.apache.org>
>> Cc: Rafael del Valle <rafael@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.corey@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 <rafael@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.corey@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.corey@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.panic@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.corey@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.panic@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.corey@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.corey@sap.com
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > > --
>> > > >
>> > > > Andrija Panić
>> > > >
>> > >
>> > >
>> > > --
>> > >
>> > > Andrija Panić
>> > >
>> >
>>
>>
>> --
>>
>> Andrija Panić
>>
>
>
> --
>
> Andrija Panić
>


-- 

Andrija Panić

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message