Rudder

Hi,

You could place already existing SSL Certificates, so they won't get generated by the RPM:

ruddersrv # rpm -qa --scripts rudder* | grep /opt/rudder/etc/ssl/rudder-webapp.crt
if [ ! -f /opt/rudder/etc/ssl/rudder-webapp.crt ] || [ ! -f /opt/rudder/etc/ssl/rudder-webapp.key ]; then
        openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$(hostname --fqdn)/" -keyout /opt/rudder/etc/ssl/rudder-webapp.key -out /opt/rudder/etc/ssl/rudder-webapp.crt -days 1460 -nodes -sha256 >/dev/null 2>&1

I agree that the knowledge of which certificates and SANs are used is vital since curl does not use -k, and requires the ssl certs to be trusted by the end systems. However, I am not sure that curl should use https on localhost/127.0.0.1, and it's not that easy to get a cert with these hostname/ip combination.

• use curl -s for localhost over https (for example in NCF technique reload or any other curl invocations), or
• use plain http for localhost (do not force redirection)

Currently we solved that by using a self-signed Root-CA based PKI (easyrsa is you friend ;), that is being rolled out to the clients, as we could not get our Certs issued with all the necessary requirements, but I agree, that a CRQ-generator would be of help.

I don't think we should avoid generating certificates, each one should be unique to your installation, otherwise you thwart the trust on first use security model.

However I do agree that we should not use httpS on localhost.

And indeed we wrote a patch a few weeks ago to avoid https for ncf technique reload