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" <[email protected]> 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"><[email protected]>
> Sent: Thursday, August 6, 2020 3:07 PM
> To: [email protected]
> 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"><[email protected]>
> Sent: Wednesday, August 5, 2020 11:29 AM
> To: users " target="_blank"><[email protected]>
> 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"><[email protected]> 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"><[email protected]>
> > Sent: Wednesday, August 5, 2020 5:14 AM
> > To: users " target="_blank"><[email protected]>
> > 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"><[email protected]> 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 [email protected]
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --
> >
> > Andrija Panić
> >
>
>
> --
>
> Andrija Panić
>
