Custom SSL client cert for smart proxy based auth doesn't split CN correctly
|Triaged:||Fixed in Releases:|
|Bugzilla link:||1108740||Found in Releases:|
dn is evaluating with this format on RHEL 6:
but on RHEL 7 it is coming up as:
this is causing $1 one from the match above to be:
by changing request_hosts = [$1] to request_hosts = [$1.gsub(/,(\S+)/i, '')] it seems to work around the issue. I'm not sure if this is the best approach to fixing it or if someone can foresee a better way.
#4 Updated by Andrew N about 4 years ago
I'm trying to get Foreman installed at a client site and have been running into the above bug, but for different reasons. If you generate the PKI certs on windows, it will use "/" as the separation character. In addition the default regex will not pull only the CN entry, but anything after the CN as well. This was causing strange errors like the following:
/var/log/foreman/production.log:No smart proxy server found on ["foreman.linux.lab.local/emailAddressfirstname.lastname@example.org"] and is not in trusted_puppetmaster_hosts
The DN for the cert in question which was signed by a Windows CA is:
if https://github.com/theforeman/foreman/blob/develop/app/controllers/concerns/foreman/controller/smart_proxy_auth.rb#L41 is changed to the string below, the parse works for SSL certs which use "/" and "," as the separator.
dn =~ /CN=([^\s\/,]+)/i
#8 Updated by Andrew N almost 4 years ago
I've almost got a pull request done, but I'm wondering if we might be going about this all wrong. I know with the openssl command line utilities it will often display the CN entry with "," and "/" characters as separators using it's default mode. There is an option to display the CN using only "," characters, I think the option option is an RFC related one, it's been a few weeks I don't exactly recall. Perhaps it would be best to first extract the CN using the appropriate format, then parse on that.