Foreman » Installer

That's not how we use it. We use SSLCertificateChainFile as the CA that allows client authentication and SSLCACertificatePath to serve the CA chain to the client. This is because we have 2 different CA chains that are being served.

Ewoud Kohl van Wijngaarden wrote in #note-1:

That's not how we use it. We use SSLCertificateChainFile as the CA that allows client authentication and SSLCACertificatePath to serve the CA chain to the client. This is because we have 2 different CA chains that are being served.

I think you mixed up some definitions

• SSLCACertificatePath will be used for both client authentication and server certificate chain.
• SSLCertificateFile will be used for server certificate and chain
• SSLCertificateChainFile will be used for server certificate and chain
• SSLCACertificateFile containing a list of ca pem certs, will be used for client authentication

Foreman is not using `SSLCACertificatePath`, which would be `ssl_certs_dir` here https://github.com/theforeman/puppet-foreman/blob/ea57c5ceb0ba99a241e5c93b708dc0f010e38c47/manifests/config/apache.pp#L318. And it should not.

It seems the `server_ssl_ca` is used as SSLCACertificateFile, which is for client authentication, see
https://github.com/theforeman/puppet-foreman/blob/ea57c5ceb0ba99a241e5c93b708dc0f010e38c47/manifests/config.pp#L159
I suggest removing `server_ssl_ca` and using `client_ssl_ca` instead.

1. `server_ssl_chain` should default to empty.
2. The generated `server_ssl_cert` file should contain the ca chain.

I am unsure about migration.
Changing the default to empty, existing installations using the foreman installer generated certificates would start to fail, since their `server_ssl_cert` file does not contain the CA.
If it can be detected whether an installation is using the default generated certs (a) or self-supplied certs (b), then maybe (a) should have their existing `server_ssl_chain` file appended to their `server_ssl_cert` file.

Rune Philosof wrote in #note-2:

Ewoud Kohl van Wijngaarden wrote in #note-1:

That's not how we use it. We use SSLCertificateChainFile as the CA that allows client authentication and SSLCACertificatePath to serve the CA chain to the client. This is because we have 2 different CA chains that are being served.

I think you mixed up some definitions

From apache documentation:

• SSLCACertificatePath will be used for both client authentication and server certificate chain.
• SSLCertificateFile will be used for server certificate and chain
• SSLCertificateChainFile will be used for server certificate and chain
• SSLCACertificateFile containing a list of ca pem certs, will be used for client authentication

Foreman is not using `SSLCACertificatePath`, which would be `ssl_certs_dir` here https://github.com/theforeman/puppet-foreman/blob/ea57c5ceb0ba99a241e5c93b708dc0f010e38c47/manifests/config/apache.pp#L318. And it should not.

It seems the `server_ssl_ca` is used as SSLCACertificateFile, which is for client authentication, see
https://github.com/theforeman/puppet-foreman/blob/ea57c5ceb0ba99a241e5c93b708dc0f010e38c47/manifests/config.pp#L159
I suggest removing `server_ssl_ca` and using `client_ssl_ca` instead.

This would be confusing, because we have client_ssl_ca for the CA that Foreman uses to verify outgoing connections to Foreman Proxies. So that the CA of a Foreman proxy is a certain CA. I realize naming is very hard here. You'd almost need to name it server_client_ssl_ca to indicate it's the CA that clients can authenticate with on a server.

1. `server_ssl_chain` should default to empty.
2. The generated `server_ssl_cert` file should contain the ca chain.

I am unsure about migration.
Changing the default to empty, existing installations using the foreman installer generated certificates would start to fail, since their `server_ssl_cert` file does not contain the CA.
If it can be detected whether an installation is using the default generated certs (a) or self-supplied certs (b), then maybe (a) should have their existing `server_ssl_chain` file appended to their `server_ssl_cert` file.

I was never sure about the interaction with a chain and a different CA. I guess I could have easily tested this myself, but never found the time for it.

You could start with making the server_ssl_chain parameter just optional. Then initially leave it to the user to migrate.