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 <[email protected]> wrote: > Usefull feedback, thanks Mike - we are taking a look into this. > > On Fri, 14 Aug 2020 at 14:13, Corey, Mike <[email protected]> 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 <[email protected]> >> Sent: Friday, August 14, 2020 7:04 AM >> To: users <[email protected]> >> Cc: Rafael del Valle <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >> > Sent: Friday, August 7, 2020 4:17 PM >> > To: [email protected] >> > 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" <[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ć >> > > >> > >> >> >> -- >> >> Andrija Panić >> > > > -- > > Andrija Panić > -- Andrija Panić
