pegasus/doc/PegasusSSLGuidelines.htm - diff

Return to PegasusSSLGuidelines.htm CVS log

Up to [Pegasus] / pegasus / doc

Diff for /pegasus/doc/PegasusSSLGuidelines.htm between version 1.4 and 1.4.4.1

version 1.4, 2006/09/29 17:38:11

version 1.4.4.1, 2006/11/23 06:22:36

Line 1

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

<title>OpenPegasus SSL Guidelines</title>

</head>

<body>

<h2>OpenPegasus 2.5.1 SSL Guidelines</h2>

<h2>OpenPegasus 2.6 SSL Guidelines</h2>

Version: 1.1

Created: July 20, 2005

Updated: March 20, 2006

Updated: November 23, 2006

<ul>

<li><a href="#OVERVIEW">Overview</a> </li>

<li>

<li><a href="#RELATED">Related Information</a> </li>

<a href="#OVERVIEW">Overview</a>

<li><a href="#BUILDING">Building Pegasus with SSL</a> </li>

<li>

<li><a href="#CERTS">Creating SSL Certificates</a> </li>

<a href="#RELATED">Related Information</a>

<li><a href="#CONFIGURE">Configuring Pegasus for SSL</a> </li>

<li>

<li><a href="#DESIGN">SSL Design Question List</a> </li>

<a href="#BUILDING">Building Pegasus with SSL</a>

<li><a href="#TRUSTSTORE">Truststore Management</a> </li>

<li>

<li><a href="#CLI">cimtrust & cimcrl CLI</a> </li>

<a href="#CERTS">Creating SSL Certificates</a>

<li><a href="#CLIENT">Configuring the Pegasus CIM Client for SSL</a> </li>

<li>

<li><a href="#AUTH">SSL Authorization</a> </li>

<a href="#CONFIGURE">Configuring Pegasus for SSL</a>

<li><a href="#EXT">Critical Extension Handling</a> </li>

<li>

<li><a href="#RESOURCES">Resources</a>

<a href="#DESIGN">SSL Design Question List</a>

<li>

<a href="#TRUSTSTORE">Truststore Management</a>

<li>

<a href="#CLI">cimtrust & cimcrl CLI</a>

<li>

<a href="#CLIENT">Configuring the Pegasus CIM Client for SSL</a>

<li>

<a href="#AUTH">SSL Authorization</a>

<li>

<a href="#EXT">Critical Extension Handling</a>

<li>

<a href="#RESOURCES">Resources</a>

</li>

</ul>

<h3><a name="OVERVIEW">Overview</a></h3>

The following document serves as a guide on how to build and configure

The following document serves as a guide on how to build and configure Pegasus

Pegasus for SSL support. It also discusses how to utilize a

for SSL support. It also discusses how to utilize a certificate-based

certificate-based

infrastructure and configure the Pegasus CIM client.

infrastructure and configure the Pegasus CIM client.

This guide requires a basic understanding of SSL, OpenSSL, and basic

authentication. This guide is intended to help developers and

authentication. This guide is intended to help developers and administrators

administrators make the right decisions about how to use SSL for their

make the right decisions about how to use SSL for their particular application.

particular application. It is not intended to be a primary source of

It is not intended to be a primary source of education on SSL. If you are not

education on SSL. If you are not familiar with these technologies,

familiar with these technologies, consult the sources in the <a href="#RESOURCES">Resources</a>

consult the sources in the <a href="#RESOURCES">Resources</a> section

section at the bottom.

at the bottom.

Note: In this document, the term "trust" refers only to

Note: In this document, the term "trust" refers only to authentication. It does

authentication. It does not imply full trust in the traditional sense,

not imply full trust in the traditional sense, because it does not take into

because it does not take into account authorization checks. It remains

account authorization checks. It remains the responsibility of providers and

the responsibility of providers and clients to perform authorization,

clients to perform authorization, and therefore establish real trust. Likewise,

and therefore establish real trust. Likewise, the term "Trust Store"

the term "Trust Store" can be misleading since the "store" is only a source of

can be misleading since the "store" is only a source of authentication

authentication credentials. Please bear this in mind when documenting

credentials. Please bear this in mind when documenting recommended

recommended deployments or building clients or providers.

deployments or building clients or providers.

<h3><a name="RELATED">Related Information</a></h3>

A significant portion of the information in this document is taken from

A significant portion of the information in this document is taken from various

various PEP's. This document attempts to bring all of this information

PEP's. This document attempts to bring all of this information together in a

together in a cohesive and simplified format.

cohesive and simplified format.

<ul>

<li>PEP#035 - Add support for /dev/random in SSLContext</li>

<li>

<li>PEP#060 - SSL support in CIM/XML indication delivery</li>

PEP#035 - Add support for /dev/random in SSLContext

<li>PEP#074 - SSLContext and Certificate verification interface

<li>

enhancement</li>

PEP#060 - SSL support in CIM/XML indication delivery

<li>PEP#165 - SSL Client Verification</li>

<li>

<li>PEP#187 - SSL Certificate Management Enhancements</li>

PEP#074 - SSLContext and Certificate verification interface enhancement

<li>PEP#200 - Recommended OpenPegasus 2.5 Build and Configuration

<li>

Options for Selected Platforms</li>

PEP#165 - SSL Client Verification

<li>

PEP#187 - SSL Certificate Management Enhancements

<li>

PEP#200 - Recommended OpenPegasus 2.5 Build and Configuration Options for

Selected Platforms</li>

</ul>

<h3><a name="BUILDING">Building Pegasus with SSL</a></h3>

To build Pegasus with HTTPS support, you will need to build against

the <a href="http://www.openssl.org">OpenSSL package</a>. <font

style="color: rgb(0, 0, 0);" color="MAGENTA">The SSL support outlined

here has been tested against recent releases of the major versions

0.9.7X and 0.9.8X (most notably, 0.9.7d). Because some versions of

0.9.6X do not contain full support for the security functions that

Pegasus utilizes (for example, certificate-based authentication is not

fully supported by some versions of 0.9.6X), Pegasus does not

officially support major version 0.9.6.

See Bugzilla 4048 for more information.

Because this is an open source project, the SSL support has been tested

with many versions of OpenSSL, but we cannot guarantee it has been

tested with every version on every platform. A list of recent OpenSSL

releases, and important-to-review security advisories and fixes, can

be found on the <a href="http://www.openssl.org/news">OpenSSL News page</a>.

After grabbing the OpenSSL source tarball, you need to set the

following environment variables before building Pegasus:

<ul>

<li>PEGASUS_HAS_SSL=1</li>

<li>OPENSSL_HOME=<location of the SDK package> This directory

must contain the OpenSSL include directory, $(OPENSSL_HOME)/include,

and the OpenSSL library directory, $(OPENSSL_HOME)/lib.</li>

<li>OPENSSL_BIN=<location of the binary package> This only

needs to be set if the OpenSSL binaries are not in $(OPENSSL_HOME)/bin.</li>

</ul>

Note that Pegasus supports SSLv3 and TLSv1 by default. It does NOT

support SSLv2. To turn on SSLv2 support, enable the additional

environment variable:

<ul>

<li> PEGASUS_ENABLE_SSLV2=1 </li>

</ul>

It is not recommended to enable this protocol, as there have been many

security weaknesses associated with it. Unless you are dealing

with very outdated clients, you probably do not need to enable it.

After setting these variables, proceed as normal with the build

To build Pegasus with HTTPS support, you will need to build against the <a href="http://www.openssl.org">

instructions in the readme file.

OpenSSL package</a>. The SSL

support outlined here has been tested against recent releases of the major

versions 0.9.7X and 0.9.8X (most notably, 0.9.7d). Because some versions of

0.9.6X do not contain full support for the security functions that Pegasus

utilizes (for example, certificate-based authentication is not fully supported

by some versions of 0.9.6X), Pegasus does not officially support major version

0.9.6. See Bugzilla 4048 for more information. Because this is an

open source project, the SSL support has been tested with many versions of

OpenSSL, but we cannot guarantee it has been tested with every version on every

platform. A list of recent OpenSSL releases, and important-to-review security

advisories and fixes, can be found on the <a href="http://www.openssl.org/news">OpenSSL

News page</a>.

After grabbing the OpenSSL source tarball, you need to set the following

environment variables before building Pegasus:

<ul>

<li>

PEGASUS_HAS_SSL=1

<li>

OPENSSL_HOME=<location of the SDK package> This directory must contain

the OpenSSL include directory, $(OPENSSL_HOME)/include, and the OpenSSL library

directory, $(OPENSSL_HOME)/lib.

<li>

OPENSSL_BIN=<location of the binary package> This only needs to be set if

the OpenSSL binaries are not in $(OPENSSL_HOME)/bin.</li>

</ul>

Note that Pegasus supports SSLv3 and TLSv1 by default. It does NOT support

SSLv2. To turn on SSLv2 support, enable the additional environment variable:

<ul>

<li>

PEGASUS_ENABLE_SSLV2=1

</li>

</ul>

It is not recommended to enable this protocol, as there have been many security

weaknesses associated with it. Unless you are dealing with very outdated

clients, you probably do not need to enable it.

After setting these variables, proceed as normal with the build instructions in

the readme file.

<h3><a name="CERTS">Creating SSL Certificates</a></h3>

There are two options for creating the CIMOM's certificate:

<ul>

<li>Self-signed certificate</li>

<li>

<li>Certificate issued by a third-party certificate authority</li>

Self-signed certificate

<li>

Certificate issued by a third-party certificate authority</li>

</ul>

To generate a self-signed certificate, you must create a private key, a

certificate signing request (CSR), and finally the public x509

certificate signing request (CSR), and finally the public x509 certificate. You

certificate.

also need an SSL configuration file that defines the parameters of the

You also need an SSL configuration file that defines the parameters of

Distinguished Name (DN). You can use the one that comes with Pegasus, ssl.cnf

the Distinguished Name (DN). You can use the one that comes with

in the root directory, or generate your own. For a self-signed certificate, the

Pegasus, ssl.cnf in the root directory, or generate your own. For a

subject is the same as the issuer. Execute the following commands to create a

self-signed certificate, the subject

self-signed certificate. The PEGASUS_ROOT and PEGASUS_HOME have to be set to

is the same as the issuer. Execute the following commands to create a

your respective installation and source directory. You will also need an

self-signed certificate. The PEGASUS_ROOT and PEGASUS_HOME have to be

OpenSSL configuration file. There is a sample configuration file that comes

set to your respective installation and source directory. You will also

with the OpenSSL package.

need an OpenSSL configuration

file. There is a sample configuration file that comes with the OpenSSL

package.

<ul>

<li>To generate a private key, execute the following:

<li>

openssl genrsa -out

To generate a private key, execute the following:

myserver.key 1024

openssl genrsa -out myserver.key 1024

Set the "sslKeyFilePath" configuration property to point to this key

Set the "sslKeyFilePath" configuration property to point to this key file.

file. </li>

<li>

<li>To generate a certificate signing request, execute the following:

To generate a certificate signing request, execute the following:

openssl req -config

openssl req -config openssl.cnf -new -key

openssl.cnf -new -key myserver.key -out myserver.csr

myserver.key -out myserver.csr

</li>

<li>

<li> At this point, the certificate signing request can be sent out

At this point, the certificate signing request can be sent out to a third-party

to a third-party certificate authority for signing, or a self-signed

certificate authority for signing, or a self-signed certificate can be

certificate can be generated. To generate a self-signed certificate,

generated. To generate a self-signed certificate, execute the following:

execute the following:

openssl x509 -in myserver.csr -out

openssl x509 -in myserver.csr

myserver.cert -req -signkey myserver.key -days 365

-out myserver.cert -req -signkey myserver.key -days 365

Set the "sslCertificateFilePath" configuration property to point to this

Set the "sslCertificateFilePath" configuration property to point to

certificate file. The above CSR file can be discarded after the certificate is

this certificate file. The above CSR file can be discarded after the

created.

certificate is created.

</li>

</ul>

After creating the keypair, make sure you protect the information

After creating the keypair, make sure you protect the information sufficiently

sufficiently by changing permissions on the files and/or directories.

by changing permissions on the files and/or directories. The following table

The following table shows the recommended privileges:

shows the recommended privileges:

<tbody>

<tr>

<th>

<th>Pegasus Config property</th>

SSL file</th>

<th>Permissions</th>

<th>

Pegasus Config property</th>

<th>

Permissions</th>

</tr>

<tr>

<td>Private key</td>

Line 178

Line 199

</tr>

<tr>

<td>CRL store </td>

<td>CRL store

</td>

<td>crlStore</td>

</tr>

</tbody>

</table>

The administrator is responsible for ensuring that the above file

The administrator is responsible for ensuring that the above file permissions

permissions are set correctly. The administrator should also ensure

are set correctly. The administrator should also ensure that all containing

that all containing directories all the way up to the base directory

directories all the way up to the base directory are not world-writable.

are not world-writable. Pegasus only checks the following conditions

Pegasus only checks the following conditions when starting up:

when starting up:

<ul>

<li>

<li>The sslKeyFilePath and the sslCertificateFilePath are readable by

The sslKeyFilePath and the sslCertificateFilePath are readable by the CIMOM.

the CIMOM.</li>

<li>

<li>The sslTrustStore and crlStore are readable

The sslTrustStore and crlStore are readable by the CIMOM if they are a single

by the CIMOM if they are a single file.</li>

file.

<li>The sslTrustStore and crlStore are readable

<li>

and writable by the CIMOM if they are a directory.</li>

The sslTrustStore and crlStore are readable and writable by the CIMOM if they

</ul>

are a directory.</li>

</ul>

These same file permissions should be used for protecting a client's

private key, public key, truststore, and crl store as well.

These same file permissions should be used for protecting a client's private

key, public key, truststore, and crl store as well.

For more information on generating keys and certificates, consult

the <a href="http://www.openssl.org/docs/HOWTO/">OpenSSL HOW-TO

documentation</a>.

For more information on generating keys and certificates, consult the <a href="http://www.openssl.org/docs/HOWTO/">

OpenSSL HOW-TO documentation</a>.

<h3><a name="CONFIGURE">Configuring Pegasus for SSL</a></h3>

There are many environment variable settings associated with SSL. Here

There are many environment variable settings associated with SSL. Here is a

is a brief discussion of the subtleties of these options and how they

brief discussion of the subtleties of these options and how they work together

work together to

to create a more secure environment. More information on the default and

create a more secure environment. More information on the default and

recommended settings can be found in PEP#200 Recommended OpenPegasus 2.5 Build

recommended settings can be found in PEP#200 Recommended OpenPegasus

and Configuration Options for Selected Platforms. Additionally, the section on <a href="#DESIGN">

2.5 Build and Configuration Options for Selected Platforms.

Design Question List</a> should help determine what these settings should

Additionally, the section on <a href="#DESIGN">Design Question List</a>

be for a given application.

should help determine what these settings should be for a given

application.

enableHttpsConnection

This is disabled by default on most platforms. It is recommended that

This is disabled by default on most platforms. It is recommended that all

all remote communication be done over the HTTPS port. However, if you

remote communication be done over the HTTPS port. However, if you are sending

are sending cleartext passwords over the wire, it is imperative that

cleartext passwords over the wire, it is imperative that you only use the

you only use the secure port. For added security, the HTTP port can be

secure port. For added security, the HTTP port can be disabled to prevent

disabled to prevent clients from connecting to it. The HTTPS connection

clients from connecting to it. The HTTPS connection is enabled by default only

is enabled by default only on the following platforms:

on the following platforms:

<ul>

<li>LINUX</li>

<li>

LINUX

<li>HP_UX (if PEGASUS_USE_RELEASE_CONFIG_OPTIONS is true)</li>

<li>

<li>VMS (if PEGASUS_USE_RELEASE_CONFIG_OPTIONS is true)</li>

OS-400

<li>

HP_UX (if PEGASUS_USE_RELEASE_CONFIG_OPTIONS is true)

<li>

VMS (if PEGASUS_USE_RELEASE_CONFIG_OPTIONS is true)</li>

</ul>

httpsPort

The default setting is 5989, the official WBEM secure port.

The default setting is 5989, the official WBEM secure port.

sslCertificateFilePath

This is the path to the x509 server certificate. The server certificate

may be a chain in which case the file should contain PEM encoded

sslCertificateFilePath

certificates beginning with the server certificate and followed by each

signing certificate authority (CA) including the root CA. If the server

This is the path to the x509 server certificate. The server certificate may be

certificate is a self signed certificate, the file only contains the

a chain in which case the file should contain PEM encoded certificates

self-signed certificate in PEM format.

beginning with the server certificate and followed by each signing certificate

The certificate cannot be encrypted because there is currently no

authority (CA) including the root CA. If the server certificate is a self

mechanism for decrypting the certificate using a user-supplied

signed certificate, the file only contains the self-signed certificate in PEM

password. This property must be defined if enableHttpsConnection is

format. The certificate cannot be encrypted because there is currently no

true. Any failure in finding this file will result in the cimserver

mechanism for decrypting the certificate using a user-supplied password. This

failing to start. See <a href="#CERTS">Creating SSL Certificates</a>

property must be defined if enableHttpsConnection is true. Any failure in

for more information.

finding this file will result in the cimserver failing to start. See <a href="#CERTS">

Creating SSL Certificates</a> for more information.

sslKeyFilePath

This is the path to the server's private key. All keys should be at

This is the path to the server's private key. All keys should be at least 1024

least 1024 bytes long. This property must be defined if

bytes long. This property must be defined if enableHttpsConnection is true. Any

enableHttpsConnection is true. Any failure in finding this file will

failure in finding this file will result in the cimserver failing to start. See <a href="#CERTS">

result in the cimserver failing to start. See <a href="#CERTS">Creating

Creating SSL Certificate</a> for more information.

SSL Certificate</a> for more information.

sslClientVerificationMode

This setting controls how the cimserver (i.e. the HTTPS port) is

This setting controls how the cimserver (i.e. the HTTPS port) is configured.

configured. There are three possible settings: disabled, required,

There are three possible settings: disabled, required, optional. There is no

optional. There is no "right" setting for this property. The default is

"right" setting for this property. The default is disabled and it is fine to

disabled and it is fine to leave the setting as disabled if you are

leave the setting as disabled if you are going to use basic authentication to

going to use basic authentication to authenticate all client requests.

authenticate all client requests. In many applications where a physical person

In many applications where a physical person is there to supply a

is there to supply a username and password, basic authentication is sufficient.

username and password, basic authentication is sufficient. Other

Other environments may be heterogeneous, in which case it makes sense to allow

environments may be heterogeneous, in which case it makes sense to

both basic authentication and SSL certificate verification. The setting of this

allow both basic authentication and SSL certificate verification. The

variable also impacts what happens during the OpenSSL handshake:

setting of this variable also impacts what happens during the OpenSSL

handshake:

<ul>

<li>

<li>"required" -- The server requires that the client

"required"

certificate be trusted in order for the handshake to continue. If the

-- The server requires that the client certificate be trusted in order for the

client fails to send a certificate or sends an untrusted certificate,

handshake to continue. If the client fails to send a certificate or sends an

the handshake is immediately terminated.</li>

untrusted certificate, the handshake is immediately terminated.

<li>"optional" -- The server will request that a client

<li>

certificate be sent, but will continue the handshake even if no

"optional" -- The server will request that a client certificate be sent,

certificate is received. If authentication is enabled, the server will

but will continue the handshake even if no certificate is received. If

seek to authenticate the client via an alternative method of

authentication is enabled, the server will seek to authenticate the client via

authentication. As

an alternative method of authentication.

of 2.5.1, if a certificate is sent but it is not validated, the

As of 2.5.1, if a certificate is sent but it is not validated, the handshake

handshake will fail. Before 2.5.1,the handshake would have

will fail. Before 2.5.1,the handshake would have continued and basic

continued and basic authentication would have proceeded. </li>

authentication would have proceeded.

<li>"disabled" -- The server will not prompt the client for a

<li>

certificate. This is the default.</li>

"disabled" -- The server will not prompt the client for a certificate. This

</ul>

is the default.</li>

Pegasus currently ties a certificate to a valid OS user. Multiple

</ul>

certificates may be registered to the same user. When a certificate is

Pegasus currently ties a certificate to a valid OS user. Multiple certificates

authenticated, Pegasus views it in the same way as if a user was

may be registered to the same user. When a certificate is authenticated,

authenticated via basic authentication. The providers

Pegasus views it in the same way as if a user was authenticated via basic

receive the username that the certificate was mapped to. See the SSL

authentication. The providers receive the username that the certificate was

Authorization section

mapped to. See the SSL Authorization section for more information.

for more information.

sslTrustStore

This setting controls the truststore for the cimserver's HTTPS

This setting controls the truststore for the cimserver's HTTPS connection. It

connection. It can be

can be either a directory or a single root CA file. When set to a directory, it

either a directory or a single root CA file. When set to a directory,

is recommended that you use the cimtrust CLI to populate the truststore as

it is recommended that you use the cimtrust CLI to populate the

there are strict naming requirements for trusted certificate files. See the <a href="#CLI">

truststore as there are strict naming requirements for trusted

cimtrust & cimcrl CLI</a> section for further information.

certificate files. See the <a href="#CLI">cimtrust & cimcrl CLI</a>

section for further information.

sslTrustStoreUserName

This setting is only utilized if the sslTrustStore is a single CA file.

This setting is only utilized if the sslTrustStore is a single CA file. It is

It is not used if the sslTrustStore setting is a directory, but it

not used if the sslTrustStore setting is a directory, but it still must be set

still must be set to a valid system user. This is because the

to a valid system user. This is because the validation of the property is done

validation of the property is done independently of the sslTrustStore

independently of the sslTrustStore setting. This property represents the valid

setting. This property represents the valid OS user that corresponds to

OS user that corresponds to the root certificate. All requests authenticated

the root certificate. All requests authenticated with a certificate

with a certificate under the root CA will be associated with this user and the

under the root CA will be associated with this user and the username

username will be propagated to providers. If applications desire for there to

will be propagated to providers. If applications desire for there to be

be a one-to-one correspondence between users and certificates, it is

a one-to-one correspondence between users and certificates, it is

recommended that each certificate be registered individually using the <a href="#CLI">

recommended that each certificate be registered individually using the

cimtrust CLI</a>.

<a href="#CLI">cimtrust CLI</a>.

crlStore

This is where the CRL (Certificate Revocation List) store resides.

crlStore

It is important to note that certificates are

This is where the CRL (Certificate Revocation List) store resides. It is

checked first against the CRL (if specified) and then against the

important to note that certificates are checked first against the CRL (if

server truststore. The <a href="#CLI">cimcrl CLI</a> should be used for

specified) and then against the server truststore. The <a href="#CLI">cimcrl CLI</a>

CRL management.

should be used for CRL management.

<h4>Configuration Limitations</h4>

The following are configuration limitations:

<ul>

<li>The x509 server certificate file cannot be encrypted. The reason

<li>

for this is that there is currently no mechanism in Pegasus to grab the

The x509 server certificate file cannot be encrypted. The reason for this is

password needed to unencrypt it. Therefore, the best way to secure the

that there is currently no mechanism in Pegasus to grab the password needed to

file is to follow the file permissions settings specified in <a

unencrypt it. Therefore, the best way to secure the file is to follow the file

href="#CERTS">Creating SSL Certificates.</a></li>

permissions settings specified in <a href="#CERTS">Creating SSL Certificates.</a>

<li>There is no property to specify supported cipher lists at this

<li>

time. Pegasus uses the default OpenSSL cipher list. The cipher lists

There is no property to specify supported cipher lists at this time. Pegasus

can be found at <a

uses the default OpenSSL cipher list. The cipher lists can be found at <a href="http://www.openssl.org/docs/apps/ciphers.html#SSL_v3_0_cipher_suites_">

href="http://www.openssl.org/docs/apps/ciphers.html#SSL_v3_0_cipher_suites_">http://www.openssl.org/docs/apps/ciphers.html#SSL_v3_0_cipher_suites_</a>

http://www.openssl.org/docs/apps/ciphers.html#SSL_v3_0_cipher_suites_</a> and

and <a

<a href="http://www.openssl.org/docs/apps/ciphers.html#TLS_v1_0_cipher_suites_">http://www.openssl.org/docs/apps/ciphers.html#TLS_v1_0_cipher_suites_</a>

href="http://www.openssl.org/docs/apps/ciphers.html#TLS_v1_0_cipher_suites_">http://www.openssl.org/docs/apps/ciphers.html#TLS_v1_0_cipher_suites_</a></li>

<li>

<li>The verification depth cannot be specified. Pegasus uses the

The verification depth cannot be specified. Pegasus uses the default OpenSSL

default OpenSSL depth of 9. This means the OpenSSL will only accept

depth of 9. This means the OpenSSL will only accept client certificate chains

client certificate chains up to 9 levels deep.</li>

up to 9 levels deep.

<li>No hostname checking is performed to ensure that the subject

<li>

field of the distinguished name (DN) matches the hostname.</li>

No hostname checking is performed to ensure that the subject field of the

distinguished name (DN) matches the hostname.</li>

</ul>

<h3><a name="DESIGN">SSL Design Question List</a></h3>

The following questions may be helpful in determining how to

The following questions may be helpful in determining how to configure Pegasus

configure Pegasus CIM Server.

CIM Server.

Should I enable the HTTPS port?

Yes, especially if you are sending passwords with requests. The HTTP

Yes, especially if you are sending passwords with requests. The HTTP port can

port can be disabled for additional security if desired.

be disabled for additional security if desired.

Should I configure the CIMOM to use a truststore?

This depends on the infrastructure of the application. If all clients

This depends on the infrastructure of the application. If all clients are using

are using basic authentication over the secure port

basic authentication over the secure port (and the passwords are secured), then

(and the passwords are secured), then a truststore may not be needed.

a truststore may not be needed. If an application does not want to store

If an application does not want to store user/pw information,

user/pw information, then it is a good idea to use a certificate-based

then it is a good idea to use a certificate-based infrastructure. If a

infrastructure. If a CIMOM certificate is compromised, the cimserver and the

CIMOM certificate is compromised, the cimserver and the providers

providers of the system are compromised. The severity of this scenario is

of the system are compromised. The severity of this scenario is

dependent on the resources the providers have access to. If an OS password is

dependent on the resources the providers have access to. If an OS

compromised, the entire system may be compromised. If using peer verification,

password is compromised, the entire system may be compromised.

it is important to ensure that 1) the cimserver is properly configured to use a

If using peer verification, it is important to ensure that 1) the

truststore, 2) the truststore is loaded properly and protected, and 3)

cimserver is properly configured to use a truststore,

authorization checks are performed after a certificate is verified. These same

2) the truststore is loaded properly and protected, and 3)

conditions also apply to a client that is verifying a server.

authorization checks are performed after a certificate is verified.

Should I use a self-signed certificate or one issued by a third-party

These same conditions also apply to a client that is verifying a server.

certificate authority?

Should I use a self-signed certificate or one issued by a

third-party certificate authority?

Generally, scalability will determine whether it's appropriate to use a

self-signed certificate or one issued by Verisign

self-signed certificate or one issued by Verisign or another third-party

or another third-party certificate authority.

certificate authority. If an administrator administrates their self-signed

If an administrator administrates their self-signed certificates

certificates correctly, they are no less secure than one issued by a CA. What a

correctly, they are no less secure than one issued by a CA. What a CA

CA buys you is scalability. An up front cost of setting up a CA relationship

buys you is scalability. An up front cost of setting up a CA

will be offset by the convenience of having that CA "vouch" for certs it has

relationship will be offset by the convenience of having that CA

signed, in large deployments. In small deployments the incremental cost might

"vouch" for certs it has signed, in large deployments. In small

never outweigh the initial CA-setup cost.

deployments the incremental cost might never outweigh the initial

CA-setup cost.

One important thing to remember is that you should not use the same certificate

One important thing to remember is that you should not use the same

for multiple CIMOMs. If using a self-signed certificate, a different one should

certificate for multiple CIMOMs. If using a self-signed certificate, a

be generated for each CIMOM, using some unique piece of data to make them

different one should be generated for each CIMOM, using some unique

different. That way, if one of the certificates is compromised, the other ones

piece of data to make them different. That way, if one of the

remain secure.

certificates is compromised, the other ones remain secure.

Should the truststore be a single root CA file or a directory?

If you only anticipate connections from a narrowly defined set of

If you only anticipate connections from a narrowly defined set of clients, then

clients, then a single root CA certificate file should be sufficient.

a single root CA certificate file should be sufficient. Alternatively, multiple

Alternatively, multiple trusted certificates may be stored in PEM

trusted certificates may be stored in PEM format inside of a single CA file. If

format inside of a single CA file.

you anticipate getting requests from a heterogeneous set of clients, then it

If you anticipate getting requests from a heterogeneous set of clients,

probably makes sense to use the directory option to allow flexibility in the

then it probably makes sense to use the directory option to allow

future. In the latter scenario, the same single root CA file can still be used

flexibility in the future. In the latter scenario, the same single root

with the additional step of using cimtrust to register it. It's important to

CA file can still be used with the additional step of using cimtrust

note that when registering a root CA, only one user can be associated with ALL

to register it.

certificates under that CA. Following the principle of least privilege, it is

It's important to note that when registering a root CA, only one user

not a good idea to register a root CA to a privileged user if lesser privileged

can be associated with ALL certificates under that CA. Following the

users will be connecting with it.

principle of

least privilege, it is not a good idea to register a root CA to a

privileged user if lesser privileged users will be connecting with it.

How do I protect the keystore and the truststore?

The server's private key should always be protected; it is private for

The server's private key should always be protected; it is private for a

a reason. Only the system administrator should be able to see it. The

reason. Only the system administrator should be able to see it. The public

public certificate can be viewed by anyone, however, it should be

certificate can be viewed by anyone, however, it should be protected from

protected from alteration by system users. Similarly, any truststore or

alteration by system users. Similarly, any truststore or CRL file or directory

CRL file or directory should also be protected from alteration. See <a

should also be protected from alteration. See <a href="#CERTS">Creating SSL

href="#CERTS">Creating SSL Certificates</a> for the recommended file

Certificates</a> for the recommended file privileges.

privileges.

When do I need to use a CRL?

Certificate Revocation Lists are regularly issued by CA's. They contain

Certificate Revocation Lists are regularly issued by CA's. They contain a list

a list of certificates that have been revoked. Any application using a

of certificates that have been revoked. Any application using a CA certificate

CA certificate in its truststore should also implement CRLs (if the CA

in its truststore should also implement CRLs (if the CA supports them). Pegasus

supports them). Pegasus itself

itself does not check CRL validity dates during startup. Therefore, it is the

does not check CRL validity dates during startup. Therefore, it is the

responsibility of the administrator to regularly download or acquire the CRL

responsibility of the administrator

and import it into the CRL store using the <a href="#CLI">cimcrl CLI</a>.

to regularly download or acquire the CRL and import it into the CRL

CRLs are not checked for expiration during the SSL callback. This means that if

store using the <a href="#CLI">cimcrl CLI</a>.

a CRL for a particular issuer has expired, Pegasus still accepts certificates

CRLs are not checked

from the issuer and uses the expired CRL as the latest. Again, it is the

for expiration during the SSL callback. This means that if a CRL for a

responsibility of the administrator to ensure the CRL is up to date. CRLs are

particular issuer has expired,

not checked for critical extensions during CRL verification. If a CRL contains

Pegasus still accepts certificates from the issuer and uses the expired

a critical extension it will be ignored.

CRL as the latest. Again, it is the responsibility of the administrator

to ensure the CRL is up to date. CRLs are not checked for critical

If using self-signed certificates, however, a CRL is most likely not needed

extensions during CRL verification. If a CRL contains a critical

(You can create a self-signed CRL but it is not really necessary). Because of

extension it will be ignored.

this, the certificate deletion option available via cimtrust is primarily

intended for self-signed certificates. Technically, CRL's are the correct way

If using self-signed certificates, however, a CRL is most likely not

to revoke compromised or invalid certificates.

needed (You can create a self-signed CRL but it is not really

necessary). Because of this, the certificate deletion option available

via cimtrust is primarily intended for self-signed certificates.

Technically, CRL's are the correct way to revoke compromised or invalid

certificates.

What is the order of operations for certificate verification?

The certificate is checked against any CRLs first before going through

The certificate is checked against any CRLs first before going through the rest

the rest of the verification process. Verification starts with the

of the verification process. Verification starts with the root certificate and

root certificate and continues down to the peer certificate. If

continues down to the peer certificate. If verification fails at any of these

verification fails at any of these points, the certificate is

points, the certificate is considered untrusted and the verification process

considered

reports an error.

untrusted and the verification process reports an error.

<h3><a name="TRUSTSTORE">Truststore Management</a></h3>

There are two directions of trust in an SSL client-server handshake:

There are two directions of trust in an SSL client-server handshake: The client

The client trusts the server. The server trusts the client. Pegasus

trusts the server. The server trusts the client. Pegasus provides a way to

provides a way to implement one or both of these relationships.

implement one or both of these relationships. Ideally, an application should

Ideally, an application should support both levels of trust for maximum

support both levels of trust for maximum security and this is the

security and this is the implementation Pegasus recommends. However, in

implementation Pegasus recommends. However, in some scenarios it may make sense

some scenarios it may make sense to only implement one of these; in

to only implement one of these; in that case, it is possible to override the

that case, it is possible to override the client or the server to

client or the server to "trust all certificates." For example, if all clients

"trust all certificates." For example, if all clients will be using

will be using basic authentication over HTTPS, then the server can be setup to

basic authentication over HTTPS, then the server can be setup to "trust

"trust all client certificates."

all client certificates."

To tell the cimserver to require that all clients be trusted,

To tell the cimserver to require that all clients be trusted, simply set the

simply set the sslClientVerification<font style="color: rgb(0, 0, 0);"

sslClientVerificationMode

color="MAGENTA">Mode property to "required."

property to "required."

To tell the cimserver to trust all clients, set the

To tell the cimserver to trust all clients, set the sslClientVerificationMode

sslClientVerificationMode

property to "disabled" or "optional".

The SSL verification in Pegasus is independent of any other

The SSL verification in Pegasus is independent of any other authentication

authentication mechanism. It can still be utilized when authentication

mechanism. It can still be utilized when authentication is disabled. When

is disabled.

authentication is enabled, the first line of defense is SSL client

When authentication is enabled, the first line of defense is SSL client

verification. In situations where a

verification.

client is not authenticated by SSL because the client sent no certificate and

In situations where a client is not authenticated by SSL because the

the setting is "optional", the server will attempt to authenticate the client

client sent no certificate and the setting is "optional", the server

via another method of authentication . In this case, the authentication

will attempt to authenticate the client via another method of

mechanism specified by the configuration property "httpAuthType" will be used

authentication . In this case, the authentication mechanism specified

for remote connections and local authentication will be used for local

by the configuration property "httpAuthType" will be used for remote

connections. In situations where a client is not authenticated by SSL because

connections and local authentication will be used for local

the client certificate was invalid, the handshake will be terminated.

connections.

In situations where a client is not authenticated by SSL because the

Note: Before 2.5.1, in the latter case, authentication would have proceeded in

client certificate was invalid, the handshake will be terminated.

the same way as if the client had sent no certificate. To enable the legacy

Note: Before 2.5.1, in the latter case, authentication would have

behavior, the compile-time flag PEGASUS_OVERRIDE_SSL_CERT_VERIFICATION_RESULT

proceeded in the same way as if the client had sent no certificate. To

should be defined.

enable the legacy behavior, the compile-time flag

PEGASUS_OVERRIDE_SSL_CERT_VERIFICATION_RESULT should be defined.

See the <a href="#CLIENT">Configuring the Pegasus CIM Client for SSL</a> section

below on how to setup the client's truststore.

See the <a href="#CLIENT">Configuring the Pegasus CIM Client for SSL</a>

section below on how to setup the client's truststore.

<h3><a name="CLI">cimtrust & cimcrl CLI</a></h3>

cimtrust CLI may be used to add, remove or list X509 certificates in a PEM

<h3><a name="CLI">cimtrust & cimcrl CLI</a></h3>

format truststore. cimcrl CLI may be used to add, remove or list X509

cimtrust CLI may be used to add, remove or list X509 certificates in a

Certificate Revocation Lists in a PEM format CRL store. The CLIs interface with

PEM format truststore. cimcrl CLI may be used to add, remove or list

a Certificate control provider that runs as part of Pegasus's core. It operates

X509 Certificate Revocation Lists in a PEM format CRL store.

on the PG_SSLCertificate and PG_SSLCertificateRevocationList classes in

root/PG_Internal. It is recommended that the CLIs be used in place of manual

The CLIs interface with a Certificate control provider that runs as

part of Pegasus's core. It operates on the PG_SSLCertificate and

PG_SSLCertificateRevocationList classes in root/PG_Internal.

It is recommended that the CLIs be used in place of manual

configuration for several reasons:

<ul>

<li>OpenSSL places strict naming restrictions on certificates and

<li>

CRLs in a directory (the files are looked up via a subject hash code)</li>

OpenSSL places strict naming restrictions on certificates and CRLs in a

<li>Certificate instances are stored in the repository along with the

directory (the files are looked up via a subject hash code)

corresponding username. If the certificate is not properly registered,

<li>

the username mapping will fail. <span

Certificate instances are stored in the repository along with the corresponding

style="color: rgb(0, 0, 0);">cimtrust CLI supports the

username. If the certificate is not properly registered, the username mapping

will fail.

cimtrust CLI supports the

ability to register a certificate without a username for root

certificates and intermediate certificates, since these certificates

represent a collection of users. In this scenario, each leaf

certificate must be registered to an individual user. See the

Authorization section for more information on username validation.

</li>

<li>

<li>The CLIs,

The CLIs,

or more correctly the provider they operate on, supports dynamic

deletion of certificates by resetting the cimserver's SSL context.

Normally, you would need to stop and start the cimserver to

accomplish this.</li>

Normally, you would need to stop and start the cimserver to accomplish this.

<li>The CLIs, or more correctly the provider they operate on, performs

<li>

a ton of error checking you would not get by manually configuring the

The CLIs, or more correctly the provider they operate on, performs a ton of

stores. This alerts the administrator to various error conditions (e.g.

error checking you would not get by manually configuring the stores. This

the certificate expired) associated with a certificate or CRL.</li>

alerts the administrator to various error conditions (e.g. the certificate

expired) associated with a certificate or CRL.</li>

</ul>

The CIMOM must be up and running while executing cimtrust/cimcrl CLI. The

cimtrust and cimcrl manpages provide more information on commands and syntax.

<h3><a name="CLIENT">Configuring the Pegasus CIM Client for SSL</a></h3>

A Pegasus CIM client can be configured to use SSL by using a

constructor that takes an SSLContext. The construction of the

A Pegasus CIM client can be configured to use SSL by using a constructor that

SSLContext is really what controls the behavior of the client during

takes an SSLContext. The construction of the SSLContext is really what controls

the SSL handshake. Without going into minute details about what happens

the behavior of the client during the SSL handshake. Without going into minute

under the covers, here is a description of the various SSLContext

details about what happens under the covers, here is a description of the

constructor parameters.

various SSLContext constructor parameters.

Here's a code snippet that shows how to call a client constructor

that connects to a server over SSL and can present its own trusted

certificate if the server requests it. In this scenario, the client

Here's a code snippet that shows how to call a client constructor that connects

also checks the server certificate against its truststore and specifies

to a server over SSL and can present its own trusted certificate if the server

an additional callback in addition to the default one (the

requests it. In this scenario, the client also checks the server certificate

user-specified callback is optional and can be set to null).

against its truststore and specifies an additional callback in addition to the

default one (the user-specified callback is optional and can be set to null).

<ul>

client.connect( hostname, port, SSLContext(trustStore,

certPath, keyPath, verifyCert, randomFile), username, password);

</ul>

Here's a code snippet that shows how to call a client constructor

that connects to a server over SSL and does not possess its own trusted

Here's a code snippet that shows how to call a client constructor that connects

certificate. In this scenario, the client also checks the server

to a server over SSL and does not possess its own trusted certificate. In this

certificate against its truststore.

scenario, the client also checks the server certificate against its truststore.

<ul>

client.connect( hostname, port, SSLContext(trustStore,

client.connect( hostname, port, SSLContext(trustStore, NULL,

NULL, randomFile), username password);

randomFile), username password);

</ul>

<ul>

<li>trustStore -- This specifies the truststore that the

<li>

client uses to verify server certificates. It can be String::EMPTY if

trustStore

no truststore exists. </li>

-- This specifies the truststore that the client uses to verify server

<li>certPath -- This specifies the x509 certificate of the

certificates. It can be String::EMPTY if no truststore exists.

client that will be sent during an SSL handshake. Note that this

<li>

certificate will only be sent if the server requests it. If this option

certPath

is specified, the keyPath parameter must also be specified.</li>

-- This specifies the x509 certificate of the client that will be sent during

<li>keyPath -- This specifies the private key of the client.

an SSL handshake. Note that this certificate will only be sent if the server

If this option is specified, the certPath parameter must also be

requests it. If this option is specified, the keyPath parameter must also be

specified.</li>

specified.

<li>crlPath -- This specifies an optional CRL store path. The

<li>

client checks the CRL list first, before attempting any further

keyPath

authentication, including the user-specified callback.</li>

-- This specifies the private key of the client. If this option is specified,

<li>verifyCert -- This is a user-specified verification

the certPath parameter must also be specified.

callback. If this is set to null, the default OpenSSL verification

<li>

callback will be executed. You can implement this method to "trust all

crlPath

servers" or to perform additional authentication checks that OpenSSL

-- This specifies an optional CRL store path. The client checks the CRL list

does not perform by default.</li>

first, before attempting any further authentication, including the

<li>randomFile -- A file to seed the pseudo random number

user-specified callback.

generator (PRNG).</li>

<li>

</ul>

verifyCert

Here are some general guidelines on implementing peer verification

-- This is a user-specified verification callback. If this is set to null, the

for the client:

default OpenSSL verification callback will be executed. You can implement this

method to "trust all servers" or to perform additional authentication checks

<ul>

that OpenSSL does not perform by default.

<li>The client should enable peer verification by specifying a

<li>

truststore and (optionally) a user-specified callback function.</li>

randomFile -- A file to seed the pseudo random number generator (PRNG).</li>

<li>The client should employ a truststore in order to properly verify

</ul>

the server. The truststore should contain a file or directory of

Here are some general guidelines on implementing peer verification for the

trusted CA certificates. The cimtrust CLI cannot be used to

client:

configure client truststores. The trusted certificate(s) should be

placed in a protected file or directory specified by the trustStore

<ul>

parameter. Keep in mind that the SSL context generally has to be

<li>

reloaded to pick up any truststore changes.</li>

The client should enable peer verification by specifying a truststore and

<li>The client could also use a user-specified callback in addition

(optionally) a user-specified callback function.

to the default verification callback, if additional verifications are

<li>

desired over the normal checks that OpenSSL performs. In most cases,

The client should employ a truststore in order to properly verify the server.

the default verification callback is sufficient for checking server

The truststore should contain a file or directory of trusted CA certificates.

certificates.</li>

The cimtrust CLI cannot be used to configure client truststores. The trusted

<li>The client should ensure that adequate entropy is attained.</li>

certificate(s) should be placed in a protected file or directory specified by

<li>The client should use a CRL store if the truststore contains CA

the trustStore parameter. Keep in mind that the SSL context generally has to be

certificates that support one.</li>

reloaded to pick up any truststore changes.

<li>The client should only use the SSLv3 and TLSv1 protocols. By

<li>

default, Pegasus is not built with SSLv2 support.</li>

The client could also use a user-specified callback in addition to the default

<li>The client should perform post-connection checks. </li>

verification callback, if additional verifications are desired over the normal

<ul>

checks that OpenSSL performs. In most cases, the default verification callback

<li>Ensure a certificate was received.</li>

is sufficient for checking server certificates.

<ul>

<li>

<li>WARNING:  In some implementations of SSL a NULL server

The client should ensure that adequate entropy is attained.

certificate is perfectly valid and authenticates against all trust

<li>

stores.  If the client does not ensure a certificate exists then

The client should use a CRL store if the truststore contains CA certificates

the client is not providing server authentication and could have a

that support one.

security bulletin class defect.</li>

<li>

</ul>

The client should only use the SSLv3 and TLSv1 protocols. By default, Pegasus

<li>Validate that the certificate received was issued to the host

is not built with SSLv2 support.

for which the client was attempting to connect.</li>

<li>

<ul>

The client should perform post-connection checks.

<li>Ensure that the common name (CN) in the server’s certificate

<ul>

subject matches the host name of the server.  For X509v3

<li>

certificates, the “SubjectAltName” fields

Ensure a certificate was received.

in the certificate's extended attributes are also valid host names for

<ul>

the certificate. </li>

<li>

<li>WARNING:  If the client does not ensure the host name of

WARNING:  In some implementations of SSL a NULL server certificate is

the server is the same as one of the host names explicitly described in

perfectly valid and authenticates against all trust stores.  If the client

the server’s certificate, you have not authenticated the server’s

does not ensure a certificate exists then the client is not providing server

identity.  Any other server which was issued a certificate from

authentication and could have a security bulletin class defect.</li>

the same trusted CA can masquerade as the server unless the client

</ul>

performs the host name check.</li>

<li>

</ul>

Validate that the certificate received was issued to the host for which the

<li>Ensure that certificate verification methods/routines return no

client was attempting to connect.

errors.</li>

<ul>

</ul>

<li>

</ul>

Ensure that the common name (CN) in the server�s certificate subject matches

the host name of the server.  For X509v3 certificates, the �SubjectAltName�

Because only the above arguments can be passed into the Pegasus

fields in the certificate's extended attributes are also valid host names for

SSLContext, there are some limitations in the client configuration:

the certificate.

<li>

<ul>

WARNING:  If the client does not ensure the host name of the server is the

<li>The verification depth cannot be specified. Pegasus uses the

same as one of the host names explicitly described in the server�s certificate,

default OpenSSL depth of 9.</li>

you have not authenticated the server�s identity.  Any other server which

<li>The cipher list cannot be specified. Pegasus uses the default

was issued a certificate from the same trusted CA can masquerade as the server

OpenSSL cipher list. The cipher lists can be found at <a

unless the client performs the host name check.</li>

href="http://www.openssl.org/docs/apps/ciphers.html#SSL_v3_0_cipher_suites_">http://www.openssl.org/docs/apps/ciphers.html#SSL_v3_0_cipher_suites_</a>

</ul>

and <a

<li>

href="http://www.openssl.org/docs/apps/ciphers.html#TLS_v1_0_cipher_suites_">http://www.openssl.org/docs/apps/ciphers.html#TLS_v1_0_cipher_suites_</a></li>

Ensure that certificate verification methods/routines return no errors.</li>

<li>No hostname checking is performed to ensure that the subject

</ul>

field of the distinguished name (DN) matches the hostname. If desired,

</li>

a user-specified callback should be configured to perform this check or

</ul>

any additional checks relevant to the application.</li>

Because only the above arguments can be passed into the Pegasus SSLContext,

there are some limitations in the client configuration:

<ul>

<li>

The verification depth cannot be specified. Pegasus uses the default OpenSSL

depth of 9.

<li>

The cipher list cannot be specified. Pegasus uses the default OpenSSL cipher

list. The cipher lists can be found at <a href="http://www.openssl.org/docs/apps/ciphers.html#SSL_v3_0_cipher_suites_">

http://www.openssl.org/docs/apps/ciphers.html#SSL_v3_0_cipher_suites_</a> and

<a href="http://www.openssl.org/docs/apps/ciphers.html#TLS_v1_0_cipher_suites_">http://www.openssl.org/docs/apps/ciphers.html#TLS_v1_0_cipher_suites_</a>

<li>

No hostname checking is performed to ensure that the subject field of the

distinguished name (DN) matches the hostname. If desired, a user-specified

callback should be configured to perform this check or any additional checks

relevant to the application.</li>

</ul>

<h3><a name="AUTH">SSL Authorization</a></h3>

The following paragraphs concern authorization of users

The following paragraphs concern authorization of users authenticated by

authenticated by certificate on the cimserver's HTTPS port.

certificate on the cimserver's HTTPS port.

It is important to note that SSL certificates are verified during

the initial handshake, BEFORE any further authentication takes place.

It is important to note that SSL certificates are verified during the initial

If a certificate fails, the connection can be terminated immediately,

handshake, BEFORE any further authentication takes place. If a certificate

resulting in a connection exception. This scenario will occur if the

fails, the connection can be terminated immediately, resulting in a connection

sslClientVerification property is set to "required" and no certificate

exception. This scenario will occur if the sslClientVerification property is

or an untrusted certificate is sent.

set to "required" and no certificate or an untrusted certificate is sent.

Further authorization checks must be performed when

validating the user that is mapped to the certificate. First, the user

that is registered to the certificate is validated as a valid system

Further authorization checks must be performed when validating

user and a valid cimuser (if the cimuser function has been configured).

the user that is mapped to the certificate. First, the user that is registered

In the case of

to the certificate is validated as a valid system user and a valid cimuser (if

the cimuser function has been configured).

In the case of

a certificate chain, the username authorization starts with the leaf

certificate. If it successfully finds a mapping

for the leaf certificate, it continues; if there is no username for the

leaf certificate, the validation proceeds up to the root certificate.

If the root certificate is reached and there is still no mapped

username, the authorization fails.

Additionally, if Pegasus was configured to use PAM, the

Additionally, if Pegasus was configured to use PAM, the pam_acct_mgmt

pam_acct_mgmt function will be called with the user that is mapped to

function will be called with the user that is mapped to the certificate. This

the certificate. This ensures that any login conditions that would have

ensures that any login conditions that would have been placed on a user

been placed on a user authenticated via basic authentication are still

authenticated via basic authentication are still applied to a user

applied to a user authenticated via certificate. The pam_authenticate

authenticated via certificate. The pam_authenticate method will NOT be called.

method will NOT be called. Lastly, the providers must authorize the

Lastly, the providers must authorize the user. They receive the username that

user. They receive the username that was mapped to the certificate in

was mapped to the certificate in the OperationContext.

the OperationContext.

A provider may request the client's certificate chain information through its

provider registration MOF. The "RequestedOperationContextContainers" property

of PG_Provider should be set to include the "SSLCertificateChainContainer"

value. If a client is authenticated via trusted certificate, then the container

will include a certificate for each level in the client's certificate chain, up

to a maximum depth of seven.

The behavior of this property is dependent on the overall

CIMOM settings. The "enableHttpsConnection" configuration property must be set

to true for the property to have any effect. Additionally, the

"sslClientVerificationMode" configuration property must be set to either

"required" or "optional". If "required" is specified, then the container will

always be populated. If "optional" is specified, the container will be populated

only if the client is authenticated via trusted certificate, as opposed to

another mechanism such as basic authentication. Because the container may not

always be included in the OperationContext, providers should always check for

its existence before performing operations on it. See the SSLCertificateInfo

class in Pegasus/Common/SSLContext.h for a full list of certificate parameters

that the SSLCertificateChainContainer supports.

<o:p></o:p>

<h3><a name="EXT">Critical Extension Handling</a></h3>

The extensions defined for X.509 v3 certificates provide methods for

associating additional attributes with users or public keys and for

managing the certification hierarchy. Each extension in a certificate

Line 667

Line 719

specified in a certificate. Please refer to the OpenSSL documentation

for more information on currently supported extensions in OpenSSL and

on the behavior of OpenSSL in the case of unhandled critical extensions.

<h3><a name="RESOURCES">Resources</a></h3>

For OpenSSL information pick up a copy of O'Reilly's Network Security

For OpenSSL information pick up a copy of O'Reilly's Network Security with

with OpenSSL or go to the OpenSSL Site:

OpenSSL or go to the OpenSSL Site:

<a href="http://www.openssl.org">http://www.openssl.org</a>

<a href="http://www.openssl.org">http://www.openssl.org</a>

A really fabulous guide on certificate management and installation

with OpenSSL:

A really fabulous guide on certificate management and installation with OpenSSL:

<a href="http://www.gagravarr.org/writing/openssl-certs/index.shtml">http://www.gagravarr.org/writing/openssl-certs/index.shtml</a>

x509 Certificate and CRL RFC:

Line 690

Line 743

<hr>

Hewlett-Packard Development Company, L.P.; IBM Corp.; The Open Group;

Company, L.P.; IBM Corp.; The Open Group; VERITAS Software Corporation

VERITAS Software Corporation

Permission is hereby granted, free of charge, to any person

Permission is hereby granted, free of charge, to any

obtaining a copy  of this software and associated documentation files (the

person obtaining a copy  of this software and associated

"Software"), to deal in the Software without restriction, including without

documentation files (the "Software"), to deal in the Software without

limitation the rights to use, copy, modify, merge, publish, distribute,

restriction, including without limitation the rights to use, copy,

sublicense, and/or sell copies of the Software, and to permit persons to whom

modify, merge, publish, distribute, sublicense, and/or sell copies of

the Software is furnished to do so, subject to the following conditions:

the Software, and to permit persons to whom the Software is furnished

to do so, subject to the following conditions:

THE ABOVE COPYRIGHT NOTICE AND THIS PERMISSION NOTICE SHALL

BE INCLUDED IN ALL COPIES OR SUBSTANTIAL PORTIONS OF THE SOFTWARE. THE SOFTWARE

THE ABOVE COPYRIGHT NOTICE AND THIS PERMISSION NOTICE

IS PROVIDED  "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,

SHALL BE INCLUDED IN ALL COPIES OR SUBSTANTIAL PORTIONS OF THE

INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A

SOFTWARE. THE SOFTWARE IS PROVIDED  "AS IS", WITHOUT WARRANTY OF

PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR

ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE

WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND

IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN

NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE

CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION

OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION

WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

<hr>

</body>

</html>

Legend:

Removed from v.1.4
changed lines
	Added in v.1.4.4.1

No CVS admin address has been configured