Description of problem: <bkearney> IMHO.. you should not need this page https://fedorahosted.org/katello/wiki/AdvancedInstallation [10:02] But these steps are still not performed by the installer: https://fedorahosted.org/katello/wiki/AdvancedInstallation#Integrationwithrhsmandyum The first step there (editing /etc/pulp/pulp.conf) is done, but none of the rest are done. If puppet is going to do these steps, it needs to be configurable. I want to be able to specify my own cert/key files instead of /etc/candlepin/certs/candlepin-ca.key and /etc/candlepin/certs/candlepin-ca.crt Why? Because UI automation has trouble with self-signed certs. Browsers do not accept them without manual intervention, and cannot be configured to automatically accept them. So in order for katello to load, its ssl cert must be signed by an existing CA, and the CA previously imported into the browser. I've created a CA for our QE org for this purpose, and put it into the browsers used by the automation. But this means I have to be able to install katello with this cert. Version-Release number of selected component (if applicable): katello-0.1.108-2.el6.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Moving to needinfo for specific information. It seems that the assumption I had made that today the default installation worked fine and no changes server side were needed to make clients work - is not true. From IRC discussion with Jeff Weiss, it seems that they had to follow the Pulp Server side directions from Advanced Install wiki to make *some* functionality work. He couldn't clearly articulate at the time what did not work and was broken before manually applying a change to get functionality working. As such, I'm happy to investigate and fix the puppet and katello-configure installation process, once I have replicator and understanding of what needs addressing. Cliff There is a 2nd issue - an Enhancement request - being tracked on the Tools Backlog for the SSL implementation to allow for a 'bring your own CA' during installation process.
There is definitely some misconfiguration on the server side. Note the comment from the first file "This MUST match /etc/pulp/pulp.conf [security] 'cacert'." but it does not match. The latter is correct, the former should be edited by the katello installer. #---from /etc/httpd/conf.d/pulp.conf : # Example ssl cert and key files to get you started. # This MUST match /etc/pulp/pulp.conf [security] 'cacert'. SSLCACertificateFile /etc/pki/pulp/ca.crt #------------ check /etc/pulp/pulp.conf for a match, does not match: [security] cacert: /etc/candlepin/certs/candlepin-ca.crt cakey: /etc/candlepin/certs/candlepin-ca.key user_cert_expiration: 7 consumer_cert_expiration: 3650
Jeff - What is broken? How do I test that a change proposed fixes something.
In katello, create a custom product and repo. sync the repo. in a client, register with RHSM, subscribe to the product. on client #yum repolist you get SSL error.
I believe this issue has two sides. On one side we need to change our installer to properly set all certificates for pulp. I created a ticket for that: https://bugzilla.redhat.com/show_bug.cgi?id=769888 Second, Pulp will need to be changed to support CA chains as we plan to sign everything with a katello CA. Jeff's situation is the same, but he will provide his own certificates.
fyi - see if not related to mod_wsgi issue in F16: https://bugzilla.redhat.com/show_bug.cgi?id=770066
Pulp makes use of CA certificates in 2 ways: First, when a client makes a request to the Pulp REST API, Pulp verifies the client SSL certificate is signed by the configured CA. Secondly, when a client makes a yum request to a protected repository hosted by Pulp, Pulp will verify the client SSL certificate is signed by a configured CA and that the client certificate has the correct OID extensions for the repository it is trying to access. This method is typically referred to as repository authentication or repo auth. Furthermore, repo auth can be configured with a global CA, in which case each repository is protected by the same CA. Alternatively, different CA's can be used to protect different repositories in Pulp. This is further detailed on the Pulp wiki: https://fedorahosted.org/pulp/wiki/Certificates We are adding support to verify client certificates against a CA chain to repo auth. The bugzilla for this effort is currently being worked on for Pulp v1.0: https://bugzilla.redhat.com/show_bug.cgi?id=782128 We aren't currently looking at verifying against a CA chain for the Pulp REST API. This is somewhat problematic because we also use this same CA to issue and sign client certificates, and that would be complicated if this file becomes a chain instead of just a single CA certificate. We'd have to make use of different Pulp configuratin directives most likely, one pointing at the chain to verify against, and one pointing at the CA certificate to use for signing. However, this means you wouldn't be able to symlink the certificate used for global repo auth to the certificate used for the REST API, since one might be a chain and one is not. If both files are not chains, then they could be symlinked together. Let me know if you have any questions, or if I can try to explain it better. I myself was having a little trouble following what all is defined at https://fedorahosted.org/katello/wiki/Certificates.
Looks like this is being targetted for MDP3.
I believe this is still required and @inecas made this little tool for generating/deploying certificates. And I think it allows you to import existing CA. Ivan?
We did a lot to make this possible but the there are couple of things still needed to be done to support this feature
*** Bug 1111902 has been marked as a duplicate of this bug. ***
Hey Ivan, that sounds plenty reasonable to me. Would you be able to test 1)?
+1 please test and let me know so I can document it correctly? :)
This is what I have so far: ``` REQ_FILE=$(hostname).crt.req CRT_FILE=$(hostname).crt KEY_FILE=$(hostname).key # needed just if you want your own certificates to try it out openssl req -out $REQ_FILE -new -newkey rsa:2048 -nodes -keyout $KEY_FILE penssl x509 -req -days 365 -in $REQ_FILE -signkey $KEY_FILE -out $CRT_FILE TARGET_REQ_FILE=/root/ssl-build/$(hostname)/$(hostname)-apache.crt.req TARGET_CRT_FILE=/root/ssl-build/$(hostname)/$(hostname)-apache.crt TARGET_KEY_FILE=/root/ssl-build/$(hostname)/$(hostname)-apache.key TARGET_RPM_NAME=$(hostname)-apache cp $REQ_FILE $TARGET_REQ_FILE cp $CRT_FILE $TARGET_CRT_FILE cp $KEY_FILE $TARGET_KEY_FILE katello-ssl-tool --gen-server --rpm-only --set-hostname $(hostname) --server-cert $(basename $TARGET_CRT_FILE) --server-cert-req $(basename $TARGET_REQ_FILE) --server-key $(basename $TARGET_KEY_FILE) --server-rpm $TARGET_RPM_NAME service httpd restart ``` There is still a need for update on katello-installer side to: 1. generate the consumer bootstrap rpm correctly to reflect the change 2. set the remote capsule correctly to reflect the change Ideally, even the functionality for this script would be limited to: ``` katello-installer --certs-ssl-cert path-to-the-ssl.crt --certs-ssl-key path-to-the-ssl.key --certs-ssl-ca path-to-the-ssl-ca.crt --certs-ssl-req path-to-the-ssl.req ``` @athene would it unblock you with the documentation if the setting of the own ca would be limited to this command? What could change would be the exact options that the installer gets