fixes #22196 - configure hammer SSL CA certificate bundle

[stbenjam]

No description provided.

[theforeman-bot]

Issues: #22196

[ekohl]

I wonder if it would be a good practice to extract this from the certs answers or if that'd create more problems because it might not be available yet.

[stbenjam]

Did Kafo change? foreman::cli is at the top level of the installer, so I think it has to be. The certs are hardcoded like this for all the modules :-(

[ekohl]

It didn't, but I wondered if we could use answers to get this value and reduce duplication. Looks like it's done in code (https://github.com/theforeman/puppet-certs/blob/60fad4d1057fca79b718c43d16d633be75e3d42d/manifests/init.pp#L110) so it's not going to work anyway.

[ekohl]

@mbacovsky mentioned theforeman/puppet-foreman@58f1911 should fix this already.

[stbenjam]

Oh I missed that. But, it picks the wrong cert anyway when using custom certs. default-ca is the katello-generated CA, and server-ca is the one from custom certs.

This is what it produces without this PR:

:ssl:
  :ssl_ca_file: '/etc/pki/katello/certs/katello-default-ca.crt'

Because of how we have answers set:

server_ssl_ca: /etc/pki/katello/certs/katello-default-ca.crt
server_ssl_chain: /etc/pki/katello/certs/katello-server-ca.crt

Can we reverse the CA and Chain? I'm honestly not sure how this works, I think we take the custom certs they provide and then sign them with the Katello generated CA. @ehelms would know

[ehelms]

I don't mind if we reverse them, that shouldn't have an affect since both are checked. I think the current setting is technically correct though. According to Apache This directive sets the optional all-in-one file where you can assemble the certificates of Certification Authorities (CA) which form the certificate chain of the server certificate.

Whereas the server_ssl_ca is for CAs of the clients with whom you deal with and our client certificates (e.g. rhsm) are signed by the default-ca.

[ekohl]

@stbenjam I think you're right that we should be preferring the chain since that's everything CA does + allows client certification authentication. See https://stackoverflow.com/a/5543737

[stbenjam]

@ekohl So do you think Foreman should send the CA chain to hammer instead (if there is one)?

[ehelms]

Agreed with the chain file -- it signed the server certificates and hammer is wanting to verify the server.

[ekohl]

https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#SSLCertificateChainFile is not that clear to me, but I think it supports that we should reverse the order:

This should be used alternatively and/or additionally to SSLCACertificatePath for explicitly constructing the server certificate chain which is sent to the browser in addition to the server certificate. It is especially useful to avoid conflicts with CA certificates when using client authentication. Because although placing a CA certificate of the server certificate chain into SSLCACertificatePath has the same effect for the certificate chain construction, it has the side-effect that client certificates issued by this same CA certificate are also accepted on client authentication.

[stbenjam]

I don't think so, whatever CA we put in SSLCACertificatePath will be allowed to use client certificates against the server, right?

That means for example, in the case of a corp with a PKI that issues client certificates to users too, they'll be able to authenticate to the Foreman with those certificates and it may not be desired. Worse, any client certificate from a large commercial CA would be acceptable in the case of something signed by Symantec.

[stbenjam]

I think we just want to do this?

https://github.com/theforeman/puppet-foreman/compare/master...stbenjam:22196?expand=1

[ehelms]

I agree with @stbenjam here. the Chain file should be the CA (or chain of CAs) that signed the server certificates.

[ekohl]

@stbenjam yes, I think it could be that simple.

[stbenjam]

I've opened PR's to reverse this and with the alternate fix to puppet-foreman. Sorry for the mess of PR's here, but I think this ends up being a better solution. Less hard coded paths in the answers file is better.