Bug 1559121

Summary: The login to UI is not possible with https://FQDN:443 until first login using https://<IP>:443.
Product: Red Hat OpenStack Reporter: Alexander Chuzhoy <sasha>
Component: openstack-tripleo-uiAssignee: RHOS Maint <rhos-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Alexander Chuzhoy <sasha>
Severity: medium Docs Contact:
Priority: medium    
Version: 13.0 (Queens)CC: dtrainor, fedora, giondog, jjoyce, jrist, jschluet, slinaber, tvignaud
Target Milestone: betaKeywords: TestOnly, Triaged
Target Release: 13.0 (Queens)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-06-28 15:17:17 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1560961    
Bug Blocks:    

Description Alexander Chuzhoy 2018-03-21 18:06:00 UTC 
The login to UI is not possible with https://FQDN:443 until first login using https://<IP>:443. 

Tried both chrome and firefox:

First attempt to login to https://FQDN:443 results in:
Unauthorized Connection to Keystone API could not be established

Then tried with https://IP:443 - succeeded.

Then re-tried with https://FQDN:443 results - also succeeded.


Environment:
instack-undercloud-8.3.1-0.20180304032746.fc5704f.el7ost.noarch
openstack-tripleo-heat-templates-8.0.0-0.20180304031148.el7ost.noarch
openstack-tripleo-ui-8.3.1-0.20180303225336.57e3d96.el7ost.noarch
Comment 3 Alexander Chuzhoy 2018-04-09 16:29:01 UTC 
If the CN in SSL certificate  on the undercloud is set with hostname, that using hostname would work on first attempt and using IP won't work until the first login with hostname.
Comment 4 Dan Trainor 2018-04-09 16:32:03 UTC 
I believe this[1] will fix the problem you describe, as it puts the IP as the CN and the hostname as the SubjAltName.  However, it doesn't look like it will be available until 7.5.z; it should probably be backported to 7.4z to cover OSP12.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1560961
Comment 5 Jason E. Rist 2018-04-25 14:43:08 UTC 
This should be fixed with the above bug fixed (now verified)
Comment 9 Alexander Chuzhoy 2018-05-18 02:01:51 UTC 
Verified:

Environment:
openstack-tripleo-ui-8.3.1-2.el7ost.noarch
instack-undercloud-8.4.1-4.el7ost.noarch

Was able to login after first attempt to connect to  https://FQDN:443
Comment 11 David Pasqua 2018-07-25 16:14:23 UTC 
this issues seems to continue in osp13

[root@director01 ~]# rpm -qa |grep instack-undercloud
instack-undercloud-8.4.1-5.el7ost.noarch
[root@director01 ~]# rpm -qa |grep openstack-tripleo-ui
openstack-tripleo-ui-8.3.1-3.el7ost.noarch
Comment 12 Chris Smart 2018-09-25 06:26:39 UTC 
In case useful, I also just hit this with RHOSP13 using self-generated SSL certs.

I set the CN in the cert to be the FQDN of the Director, however I was not able to log in using the FQDN first. I had to log in with the IP first, even though the IP was not the CN (it was in Alternative Name).

This seems to contradict comment #3

-c