Bug 1498196 - Director install generates a self-signed certificate that has an illegal x.509 subjectAltName
Summary: Director install generates a self-signed certificate that has an illegal x.50...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: puppet-certmonger
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Linux
medium
medium
Target Milestone: z4
: 11.0 (Ocata)
Assignee: RHOS Maint
QA Contact: Prasanth Anbalagan
URL:
Whiteboard:
Depends On: 1445580
Blocks: 1498252
TreeView+ depends on / blocked
 
Reported: 2017-10-03 17:33 UTC by Harry Rybacki
Modified: 2018-02-13 16:38 UTC (History)
17 users (show)

Fixed In Version: puppet-certmonger-1.1.1-2.1157a7egit.el7ost
Doc Type: Bug Fix
Doc Text:
The director generated self-signed certificates with both DNS names and IP addresses listed as DNS entries. The resulting certificate contained an invalid subjectAltName section. This fix corrects how the certificate generation distinguishes between DNS names and IP addresses. The certificate's subjectAltName section is now valid.
Clone Of: 1445580
: 1498252 (view as bug list)
Environment:
Last Closed: 2018-02-13 16:38:01 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0311 normal SHIPPED_LIVE Red Hat OpenStack Platform 11 Bug Fix and Enhancement Advisory 2018-02-14 00:05:57 UTC

Description Harry Rybacki 2017-10-03 17:33:03 UTC
+++ This bug was initially created as a clone of Bug #1445580 +++

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.

--- Additional comment from Nick Satsia on 2017-04-26 10:16:32 EDT ---

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

--- Additional comment from Dan Macpherson on 2017-04-28 14:12:40 EDT ---

(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

--- Additional comment from Nick Satsia on 2017-04-29 07:08:11 EDT ---

(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

--- Additional comment from Juan Antonio Osorio on 2017-09-26 07:42:52 EDT ---

Add

--- Additional comment from Juan Antonio Osorio on 2017-09-26 07:43:42 EDT ---

Addressing it in this pull request https://github.com/saltedsignal/puppet-certmonger/pull/14

--- Additional comment from Nathan Kinder on 2017-09-29 17:35:18 EDT ---

The pull request mentioned in comment#5 has merged upstream.

--- Additional comment from Harry Rybacki on 2017-10-03 10:17:21 EDT ---

Comment 8 errata-xmlrpc 2018-02-13 16:38:01 UTC
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/RHBA-2018:0311


Note You need to log in before you can comment on or make changes to this bug.