Red Hat NETWORK 3.6 - Spezifikationen PDF herunterladen (Seite 13)

Chapter 3. SSL Infrastructure

For Red Hat Network customers, security concerns are of the utmost importance. One of the strengths

of Red Hat Network is its ability to process every single request over Secure Sockets Layer, or SSL. T o

maintain this level of security, customers installing Red Hat Network within their infrastructures must

generate custom SSL keys and certificates.

Manual creation and deployment of SSL keys and certificates can be quite involved. Both the RHN Proxy

Server and the RHN Satellite Server allow you to build your own SSL keys and certificates based on your

own private Certificate Authority (CA) during installation. In addition, a separate command line utility, the

RHN SSL Maintenance Tool, exists for this 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 chapter describes efficient methods for conducting

all of these tasks.

Please note that this chapter does not explain SSL in depth. T he RHN SSL Maintenance Tool was

designed to hide much of the complexity involved in setting up and maintaining this public-key

infrastructure (PKI). For more information, please consult some of the many good references available at

your nearest bookstore.

3.1. A Brief Introduction To SSL

SSL, or Secure Sockets Layer, is a protocol that enables client-server applications to pass information

securely. SSL uses a system of public and private key pairs to encrypt communication 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. Through this relationship, a connection of trust is established.

Note

Throughout this document we discuss SSL private keys and public certificates. Technically both

can be referred to as keys (public and private keys). But it is convention, when discussing SSL, to

refer to the 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 organization

generally generated. The public certificate is digitally signed by its private key. The public certificate

is distributed to every system.

Web server SSL private key and public certificate — one set per application server. T he public

certificate is digitally signed by both its private key and the CA SSL private key. We often refer to a

Web server's key set; this is because there is an intermediary SSL certificate request that is

generated. The details of what this is used for are not important to this discussion. All three are

deployed to an RHN Server.

Here's a scenario: If you have one RHN Satellite Server and five RHN Proxy Servers, you will generate

one CA SSL key pair and six Web server SSL key sets. T he CA SSL public certificate is distributed to 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 generated using its

own SSL private key and the CA SSL private key in combination. This establishes a digitally verifiable

association between the Web server's SSL public certificate and the CA SSL key pair and server's

private key. T he Web server's key set cannot be shared with other web servers.

Red Hat Network Satellite 5.4 Client Configuration Guide

1 2 ... 8 9 10 11 12 13 14 15 16 17 18 ... 41 42

Kommentare zu diesen Handbüchern

Keine Kommentare

Red Hat NETWORK 3.6 - Spezifikationen Seite 13

Kommentare zu diesen Handbüchern

Verwandte Produkte und Handbücher für Server Red Hat NETWORK 3.6 -