Bug 1445580
Summary: | Director install generates a self-signed certificate that has an illegal x.509 subjectAltName | |||
---|---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Nick Satsia <nsatsia> | |
Component: | puppet-certmonger | Assignee: | RHOS Maint <rhos-maint> | |
Status: | CLOSED ERRATA | QA Contact: | Prasanth Anbalagan <panbalag> | |
Severity: | medium | Docs Contact: | ||
Priority: | medium | |||
Version: | 10.0 (Newton) | CC: | apannu, aschultz, dmacpher, jjoyce, josorior, jpichon, jschluet, jslagle, mburns, mcornea, nkinder, nsatsia, panbalag, rhel-osp-director-maint, slinaber, tvignaud | |
Target Milestone: | beta | Keywords: | Triaged | |
Target Release: | 12.0 (Pike) | |||
Hardware: | Unspecified | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | puppet-certmonger-1.2.1-0.20170825101332.el7ost | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1498196 (view as bug list) | Environment: | ||
Last Closed: | 2017-12-13 21:25:26 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: | ||||
Bug Blocks: | 1498196, 1498252 |
Description
Nick Satsia
2017-04-26 03:11:17 UTC
Further testing with this I realised that the public endpoints for the undercloud are defined as IPv4 addresses instead of FQDN. Re: "/usr/lib/python2.7/site-packages/backports/ssl_match_hostname/__init__.py" "match_hostname" only searches for "DNS" entries in the SAN even though the hostname given is an IPv4 address. Until ssl_match_hostname can handle "IP Address" entries in the SAN or FQDNs are defined for the undercloud endpoints an IPv4 address must be set as a DNS entry in the SAN. I discovered that the Firefox issue for the ui described in Appendix D of the installation document can be avoided by defining the IPv4 address as the 2nd DNS entry: X509v3 Subject Alternative Name: DNS:<FQDN of undercloud>, DNS:192.168.208.2 -Nick (In reply to Nick Satsia from comment #1) > I discovered that the Firefox issue for the ui described in Appendix D of > the installation document can be avoided by defining the IPv4 address as the > 2nd DNS entry: Hi Nick, Are you sure about this? Appendix D was meant to be a workaround for a Firefox bug [1][2] where it would only create a server exception for the standard port (443), whereas the other ports needed their own exception. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=700837 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1392627 (In reply to Dan Macpherson from comment #2) > (In reply to Nick Satsia from comment #1) > > I discovered that the Firefox issue for the ui described in Appendix D of > > the installation document can be avoided by defining the IPv4 address as the > > 2nd DNS entry: > > Hi Nick, > > Are you sure about this? Appendix D was meant to be a workaround for a > Firefox bug [1][2] where it would only create a server exception for the > standard port (443), whereas the other ports needed their own exception. > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=700837 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1392627 I tested this on my MAC running latest OSX and Firefox. I ran 3-4 tests and it definitely worked around the issue (at least for me). If the 1st DNS entry is an IPv4 address it fails to match any entries. Revert back to IPv4 1st and problem comes back. I set the 1st DNS entry to a proper FQDN of the server (even though endpoints are still IPv4) and it obviously triggers a different code path in Firefox. Originally came across this workaround on the overcloud where I followed the doco example and set the IPv4 address as the 1st DNS entry in the SAN. Interestingly safari would only hit the problem with the overcloud when I try and connect to a VM console FQDN:13080 whilst on the dashboard using an FQDN. Safari just gave me an odd error regarding the console unrelated to the cert but Firefox was more descriptive. So when this workaround fixed the VM console issue I thought I'd try it on the Director UI :) Try it out yourself. You do not need to deploy an overcloud, just the undercloud with the UI enabled. Having said that..... there is still "real" issues we need to address as this is just a band-aid workaround: 1. Open an RFE for python ssl_match_hostname to support IPv4 addresses. 2. This will enable us to fix the undercloud installer to define the IPv4 address as a SAN "IP address" instead of "DNS". 3. Open an RFE for the undercloud installer allow for FQDN entries instead of IPv4 for the endpoints as we do for the overcloud. -Nick Add Addressing it in this pull request https://github.com/saltedsignal/puppet-certmonger/pull/14 The pull request mentioned in comment#5 has merged upstream. *** Bug 1485498 has been marked as a duplicate of this bug. *** Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:3462 |