Red Hat NETWORK 3.7 - CLIENT Configuration Manual

Also see for NETWORK 3.7 -: Manual Reference guide

Contents

Red Hat NETWORK 3.7 - CLIENT Configuration Manual Manual pdf 13 page image

Chapter 3.SSL InfrastructureFor Red Hat Network customers, security concerns are of the utmost importance. One of the strengthsof Red Hat Network is its ability to process every single request over Secure Sockets Layer, or SSL.To maintain this level of security, customers installing Red Hat Network within their infrastructuresmust generate custom SSL keys and certificates.Manual creation and deployment of SSL keys and certificates can be quite involved. Both the RHNProxy Server and the RHN Satellite Server allow you to build your own SSL keys and certificatesbased on your own private Certificate Authority (CA) during their installation. In addition, a separatecommand line utility, the RHN SSL Maintenance Tool, exists for this same purpose. Regardless,these keys and certificates must then be deployed to all systems within your managed infrastructure.In many cases, deployment of these SSL keys and certificates is automated for you. This chapterdescribes efficient methods for conducting all of these tasks.Please note that this chapter does not explain SSL in depth. The RHN SSL Maintenance Tool wasdesigned to hide much of complexity involved in setting up and maintaining this public-key infras-tructure (PKI). For more information, please consult some of the many good references available atyour nearest bookstore.3.1. A Brief Introduction To SSLSSL, or Secure Sockets Layer, is a protocol that enables client-server applications to pass informationsecurely. SSL uses a system of public and private key pairs to encrypt communication passed betweenclients and servers. Public certificates can be left accessible, while private keys must be secured.It’s the mathematical relationship (a digital signature) between a private key and its paired publiccertificate that makes this system work. Through this relationship, a connection of trust is established.NoteThroughout this document we discuss SSL private keys and public certificates. Technically both canbe referred to as keys (public and private keys). But it is convention, when discussing SSL, to refer tothe public half of an SSL key pair (or key set) as the SSL public certificate.An organization’s SSL infrastructure is generally made up of these SSL keys and certificates:• Certificate Authority (CA) SSL private key and public certificate — only one set per organizationgenerally generated. The public certificate is digitally signed by its private key. The public certificateis distributed to every system.• Web server SSL private key and public certificate — one set per application server. The publiccertificate is digitally signed by both its private key and the CA SSL private key. We often referto a Web server’s key set; this is because there is an intermediary SSL certificate request that isgenerated. The details of what this is used for is not important to this discussion. All three aredeployed to an RHN Server.Here’s a scenario: If you have one RHN Satellite Server and five RHN Proxy Servers, you will gener-ate one CA SSL key pair and six Web server SSL key sets. The CA SSL public certificate is distributedto all systems and used by all clients to establish a connection to their respective upstream servers.Each server has its own SSL key set that is specifically tied to that server’s hostname and generatedusing its own SSL private key and the CA SSL private key in combination. This establishes a digitally