Created attachment 1369372 [details] Full rhn_check log Description of problem: When the client picks up a scheduled kickstart, rhn_check fails (in verbose mode) with a "Certificate verify failed" message via koan/utils.py. Version-Release number of selected component (if applicable): - Spacewalk 2.7 client and server - Minimal install of CentOS 7 (vanilla) - Python 2.7.5-58.el7 - spacewalk-koan.noarch 2.7.2-1.el7 How reproducible: Always. Steps to Reproduce: 1. Schedule a kickstart on the spacewalk server 2. Log into the to-be kickstarted machine 3. rhn_check -v Actual results: Output of rhn_check -v [...] File "/usr/lib64/python2.7/ssl.py", line 833, in do_handshake self._sslobj.do_handshake() SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579) Could not find Cobbler. rhn_ckeck fails and no kickstart is done Expected results: no error message. Continuation with kickstart Additional info: # python -c "import ssl; print(ssl.get_default_verify_paths())" DefaultVerifyPaths(cafile='/etc/pki/tls/cert.pem', capath='/etc/pki/tls/certs', openssl_cafile_env='SSL_CERT_FILE', openssl_cafile='/etc/pki/tls/cert.pem', openssl_capath_env='SSL_CERT_DIR', openssl_capath='/etc/pki/tls/certs') # ls /etc/pki/tls/certs customca.cer
Additional info: # python -mrequests.certs /etc/pki/tls/certs/ca-bundle.crt Also I believe this is related: Bug 1490392 - xmlrpclib does not support SSL context, needed for SSL verification https://bugzilla.redhat.com/show_bug.cgi?id=1490392 (Brief summary:RHEL 7.4 enabled SSL verification by default for Python 2.7. This feature was backported from python 2.7.9. However, python 2.7.9 supports "context" parameters for the xmlrpclib.ServerProxy class, which was not backported. This means that with the new default of verifying SSL certificates, it is not possible to specify a custom CAfile for xmlrpclib connections as the context parameter is unknown.) Either way, koan utils must pass the custom CAfile to xmlrpclib so this change seems to be required. I am waiting for the xmlrpclib fix to be available and then give koan another attempt and see on a possible solution
Here is the workaround 1. Copy the certificate to the folder /etc/pki/ca-trust/source/anchors/ # cp /etc/pki/tls/certs/custom.cer /etc/pki/ca-trust/source/anchors/ 2. update the system certificate store # update-ca-trust Now it should work. I have tested this with a python script and not with real cobbler. Once I do a kickstart, I will report back. The way I see it, the Spacewalk server should place the server certificate into the folder "/etc/pki/ca-trust/source/anchors/" and run "update-ca-trust" on a rhn_register
ok, one more update: 1. the Spacewalk generated rhn-org-trusted-ssl-cert-*.noarch.rpm does this as expected in "Comment 2". But this rpm is never installed on new systems via Kickstart or registration 2. Kickstart only copies the certificate file but never installs the rhn-org-trusted-ssl-cert-*.noarch.rpm or allows system wide usage of the given certificates. Kickstart only configures the rhn client to use them. 3. Client registration: I have not checked this yet but a kickstart also registers a client. so also registration also does not pull and install rhn-org-trusted-ssl-cert-*.noarch.rpm or sets the downloaded certificate up system wide (if it pulls a certificate at all). In my opinion, 2. should make the downloaded certificate files available to the system so cobbler works. So the kickstart script should include by default CERT_DIR=/usr/share/rhn CERT_FILE=RHN-ORG-TRUSTED-SSL-CERT TRUST_DIR=/etc/pki/ca-trust/source/anchors if [ -f $CERT_DIR/$CERT_FILE ]; then ln -sf $CERT_DIR/$CERT_FILE $TRUST_DIR else rm -f $TRUST_DIR/$CERT_FILE fi /usr/bin/update-ca-trust extract 3. Should also ideally work but as registration requires to download the client rpms, the certificate rpm might as well also be installed manually...
Spacewalk 2.8 (and older) has already reached it's End Of Life. Thank you for reporting this issue and we are sorry that we were not able to fix it before end of life. If you would still like to see this bug fixed and are able to reproduce it against current version of Spacewalk 2.9, you are encouraged change the 'version' and re-open it.