Bug 1219946

+++ This bug was initially created as a clone of Bug #1216273 +++

1. Proposed title of this feature request  
Able to generate/convert SHA2 SSL certificates for Satellite 5.x
      
3. What is the nature and description of the request?  
Customer would like to convert/generate SHA2 SSL certificates for his Satellite server,  because existing websites having SHA1 certificates will not be trusted on Google Chrome or IE browsers. This may fail lot of Web Based applications like RHN Satellite.
      
4. Why does the customer need this? (List the business requirements here)  

Google & Microsoft will start issuing warnings from Jan 2016. We have to issue SHA2 certificates for our Web based Red Hat tools.

http://www.symantec.com/page.jsp?id=sha2-transition
http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx

5. How would the customer like to achieve this? (List the functional requirements here)  
By generating SHA2 certificates for Satellite server.
      
6. Is there already an existing RFE upstream or in Red Hat Bugzilla?  
NO     
    
7. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?
Before Jan 2016   

9. List any affected packages or components.  
~~~~
rhn-ssl-tool is used to create CSRs for SSL certs for submission to CAs.

ie.,.. rhn-ssl-tool --gen-server --cert-req-only

the tool calls /usr/share/rhn/certs/sslToolConfig.py to generate  a config file (rhn-server-openssl.cnf) used in turn to generate the CSR.

The ssl ToolConfig.py is hard coded to use "MD = 'sha1'" instead of being an option or 'sha256' as default.. as sha1 is being phased out.
~~~

--- Additional comment from Stephen Herr on 2015-05-07 15:41:15 EDT ---

I was expecting for this to not work because RHEL 5.0 clients wouldn't be able to initiate ssl connections with a sha256 server cert, but it appears to just work when connected to Sat 5.7 (on RHEL 6).

I know that with the initial release of RHEL 5 'rpm' could not understand sha256-signed rpms, 'yum' could not use sha256 checksums to verify the file download, the python standard lib did not include sha256 support (you needed the additional python-hashlib rpm), and you could not use sha256 as your password hashing algorithm. However it appears that the networking layer is capable of using / validating sha256 server certs. I believe that the simplest / best solution here is to set "MD = 'sha256'" as Amar suggested, and have people regenerate their certs if they desire sha256 certs.

I have even verified that *if* we change spacewalk-certs-tools so that it requires python-hashlib on RHEL 5, that we can even install / use rhn-ssl-tool to generate our certs on a RHEL 5 machine (rhn-ssl-tool does not necessarily have to be run on the server that the certs are intended for).

I do not know however if Satellite running on RHEL 5 (possible in Sat 5.6 or below) would be able to use sha256 certs, it would probably depend on if httpd is able to deal with sha256 server certs or not. Additional testing would be needed. However a quick search tells me it probably does work, so there should be no problem with releasing the updated certs-tools package in the rhn-tools channel (where it would be available to Satellites of all versions).

--- Additional comment from Stephen Herr on 2015-05-08 15:17:29 EDT ---

Verified working with Satellite 5.6 on RHEL 5 too. And that means that it should work with any Satellite 5.x version on RHEL 5 or 6, which is to say all of the supported versions.

spacewalk-certs-tools is released in all the Satellite channels, all the Proxy channels, and all the rhn-tools channels, and I think this updated could be released to all of them if we thought it was necessary.