Bug 1747581
| Summary: | capsule-certs-generate uses a value for --foreman-proxy-cname to add a DNS record even if it is invalid | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Gary Scarborough <gscarbor> |
| Component: | Certificates | Assignee: | Eric Helms <ehelms> |
| Status: | CLOSED ERRATA | QA Contact: | Stephen Wadeley <swadeley> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.5.0 | CC: | bkearney, ekohlvan, mmccune, pcreech |
| Target Milestone: | 6.7.0 | Keywords: | Triaged |
| Target Release: | Unused | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | No Doc Update | |
| Doc Text: |
not needed to be called out in the release notes.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-04-14 13:25:28 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: | 1659414 | ||
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.
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.
Created redmine issue https://projects.theforeman.org/issues/27847 from 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/RHSA-2020:1454 |
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...`.