Description of problem: When you elect to self-generate a self-signed certificate with the following options, the certificate generated has an IPv4 address for a DNS entry in subjectAltName. This trigger various issues with browsers including what is described in Appendix D of the RH Director installation documentation (link below). https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html-single/director_installation_and_usage/#appe-Server_Exceptions Based on the following RFCs a DNS name cannot start with a number (0-9) and therefore the self signed certificated is illegal as it defines the IPv4 address as a DNS entry and not IP: https://tools.ietf.org/html/rfc5280#section-4.2.1.6 https://tools.ietf.org/html/rfc1034#section-3.5 # openssl x509 -text -noout -in /etc/pki/tls/certs/undercloud-192.168.208.2.pem . . X509v3 extensions: X509v3 Subject Alternative Name: DNS:192.168.208.2 . . Entry should be: . . X509v3 extensions: X509v3 Subject Alternative Name: IP Address:192.168.208.2 . . Version-Release number of selected component (if applicable): RHOSP10 How reproducible: Consistent Steps to Reproduce: 1. Deploy Director setting the following option sin undercloud.conf: generate_service_certificate = true certificate_generation_ca = local 2. Try connecting to ui with Firefox without following Appendix D in the installation documentation (link above). Actual results: Even though you accept and trust the self-signed certificate all FQDN:<tcp port> referrals to OpenStack services (such as keystone) fail unless you manually accept them as described in Appendix D of installation document (link above). Expected results: HTTPS browsing should work without any certificate exceptions. Additional info: Safari and Chrome seem to be OK with this "until" they are redirected to another tcp port of the server. This is not evident with the director ui but it is when the same mistake by the user/installer is made for an overcloud self-signed certificate (by following RH documentation again, another doco BZ to open). Safari will fail to connect to a VM console via the dashboard.
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