Red Hat NETWORK 4.0.5 - CLIENT Configuration Manual

Also see for NETWORK 4.0.5 -: Manual Reference guide

Contents

Chapter 3.SSL InfrastructureFor Red Hat Network customers, security concerns are of the utmost importance. One ofthe strengths of Red Hat Network is its ability to process every single request over SecureSockets Layer, or SSL. To maintain this level of security, customers installing Red HatNetwork within their infrastructures must generate custom SSL keys and certificates.Manual creation and deployment of SSL keys and certificates can be quite involved. Boththe RHN Proxy Server and the RHN Satellite Server allow you to build your own SSL keysand certificates based on your own private Certificate Authority (CA) during installation.In addition, a separate command line utility, the RHN SSL Maintenance Tool, exists forthis purpose. Regardless, these keys and certificates must then be deployed to all systemswithin your managed infrastructure. In many cases, deployment of these SSL keys andcertificates is automated for you. This chapter describes efficient methods for conductingall of these tasks.Please note that this chapter does not explain SSL in depth. The RHN SSL MaintenanceTool was designed to hide much of the complexity involved in setting up and maintain-ing this public-key infrastructure (PKI). For more information, please consult some of themany good references available at your nearest bookstore.3.1. A Brief Introduction To SSLSSL, or Secure Sockets Layer, is a protocol that enables client-server applications to passinformation securely. SSL uses a system of public and private key pairs to encrypt com-munication passed between clients 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 public certificate that makes this system work. Throughthis relationship, a connection of trust is established.NoteThroughout this document we discuss SSL private keys and public certificates. Techni-cally both can be referred to as keys (public and private keys). But it is convention, whendiscussing SSL, to refer to the public half of an SSL key pair (or key set) as the SSL publiccertificate.An organization’s SSL infrastructure is generally made up of these SSL keys and certifi-cates: