Bug 1747581 - capsule-certs-generate uses a value for --foreman-proxy-cname to add a DNS record even if it is invalid
Summary: capsule-certs-generate uses a value for --foreman-proxy-cname to add a DNS re...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Certificates
Version: 6.5.0
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: 6.7.0
Assignee: Eric Helms
QA Contact: Stephen Wadeley
URL:
Whiteboard:
Depends On:
Blocks: 1659414
TreeView+ depends on / blocked
 
Reported: 2019-08-30 21:28 UTC by Gary Scarborough
Modified: 2024-02-28 20:32 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
not needed to be called out in the release notes.
Clone Of:
Environment:
Last Closed: 2020-04-14 13:25:28 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 27847 0 Normal Closed foreman-proxy-certs-generate uses a value for --foreman-proxy-cname to add a DNS record even if it is invalid 2021-02-16 11:59:05 UTC
Red Hat Product Errata RHSA-2020:1454 0 None None None 2020-04-14 13:25:45 UTC

Description Gary Scarborough 2019-08-30 21:28:55 UTC
Description of problem:

capsule-certs-generate uses the value for --foreman-proxy-cname to add a DNS record in the SAN field regardless of that setting making sense or not.  E.g.   DNS:[]   and    DNS:  <= empty string.


Version-Release number of selected component (if applicable):

This was found on satellite 6.5, but may be true for older versions

How reproducible:

Always

Steps to Reproduce:

This is what capsule-certs-generate is generating for qpid-router-server.crt: (used by capsules' qdrouterd on port 5647 to listen to clients' goferds)

            X509v3 Subject Alternative Name: 
                DNS:mycapsule.example.com, DNS:[]



The DNS:[] comes from the default value for --foreman-proxy-cname:
~~~
[root@sat65a ~]# capsule-certs-generate --help

  (...snip...)

= Module foreman_proxy_certs:
    --certs-tar                   Path to tar file with certs to generate (current: UNDEF)
    --foreman-proxy-cname         additional names of the foreman proxy (current: ["[]"])   <========= here
    --foreman-proxy-fqdn          FQDN of the foreman proxy (current: "sat65a.usersys.redhat.com")


Turns out, if you use `--foreman-proxy-cname ""` with `capsule-certs-generate` it will still generate certs with DNS:<fqdn>, DNS:    <==== second DNS entry empty.

So this is either a docs bug (and somewhat of a usability bug) because capsule-certs-generate actually ALWAYS needs --foreman-proxy-cname set to whatever crazy value you want, ...

OR

...we have a bug where the contents from --foreman-proxy-cname are being added to the cert regardless of it being a valid hostname or not. That is, neither [] nor and empty string should be acceptable contents for SAN records.


## Workaround for this bug always pass `capsule-certs-generate --foreman-proxy-cname <some acceptable name here, e.g. the shortname> ...etc...`.

Comment 3 Ewoud Kohl van Wijngaarden 2019-09-12 15:51:09 UTC
It looks like it doesn't parse the array and treats it as a string as can be seen by the odd ["[]"] instead of []. That also means that changing the validation from Array[String] to Array[Stdlib::Fqdn] suddenly breaks because [] is an invalid hostname. This appears to be the root cause of the bug.

Changing the parser cache value from foreman_proxy_cname: '[]' to foreman_proxy_cname: [] corrects the default:

= Module certs:
    --cname                       The alternative names of the host the generated certificates
                                  should be for (current: [])

Either kafo or kafo_parsers has a bug in getting defaults.

Comment 4 Ewoud Kohl van Wijngaarden 2019-09-12 16:02:37 UTC
A bit more context. kafo_parsers retrieves the defaults using puppet-strings but that reports everything as a string:

      "defaults": {
        "parent_fqdn": "$::fqdn",
        "foreman_proxy_fqdn": "$::fqdn",
        "foreman_proxy_cname": "[]",
        "certs_tar": "undef"
      },

In kafo_parsers there is a sanitize method but it doesn't deal with "arrays" (https://github.com/theforeman/kafo_parsers/blob/d0f72ca2fe650267b1b035fdf1ae0fb59204f5b1/lib/kafo_parsers/puppet_strings_module_parser.rb#L133-L145).

The quickest workaround is implementing a certs::foreman_proxy_content::params class and setting the default there. It uses a different mechanism and it can use more complex data types.

Comment 5 Ewoud Kohl van Wijngaarden 2019-09-12 16:50:19 UTC
Created redmine issue https://projects.theforeman.org/issues/27847 from this bug

Comment 9 errata-xmlrpc 2020-04-14 13:25:28 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/RHSA-2020:1454


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