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.4.1 and 1.8

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

version 1.8, 2013/08/06 08:37:35

Line 1

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

<html>

<head>

<title>OpenPegasus SSL Guidelines</title>

</head>

<body>

<h2>OpenPegasus 2.6 SSL Guidelines</h2>

<h2>OpenPegasus 2.5.1 SSL Guidelines</h2>

Version: 1.1

Created: July 20, 2005

Updated: November 23, 2006

Updated: March 20, 2006

<ul>

<li>

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

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

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

<li>

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

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

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

<li>

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

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

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

<li>

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

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

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

<li>

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

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

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

<li>

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

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

<li><a href="#RESOURCES">Resources</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 Pegasus

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

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

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

infrastructure and configure the Pegasus CIM client.

certificate-based

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 administrators

authentication. This guide is intended to help developers and

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

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

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

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

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

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

section at the bottom.

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

at the bottom.

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

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

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

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

account authorization checks. It remains the responsibility of providers and

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

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

the responsibility of providers and clients to perform authorization,

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

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

authentication credentials. Please bear this in mind when documenting

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

recommended deployments or building clients or providers.

credentials. Please bear this in mind when documenting recommended

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 various

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

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

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

cohesive and simplified format.

together in a cohesive and simplified format.

<ul>

<li>

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

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

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

<li>

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

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

enhancement</li>

<li>

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

PEP#074 - SSLContext and Certificate verification interface enhancement

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

<li>

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

PEP#165 - SSL Client Verification

Options for Selected Platforms</li>

<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.

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

After setting these variables, proceed as normal with the build

OpenSSL package</a>. The SSL

instructions in the readme file.

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>

<li>Self-signed certificate</li>

Self-signed certificate

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

<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. You

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

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

certificate.

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

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

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

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

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

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

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

self-signed certificate, the subject

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

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

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

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

with the OpenSSL package.

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

need an OpenSSL configuration

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

package.

<ul>

<li>

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

To generate a private key, execute the following:

openssl genrsa -out

openssl genrsa -out myserver.key 1024

myserver.key 1024

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

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

<li>

file. </li>

To generate a certificate signing request, execute the following:

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

openssl req -config openssl.cnf -new -key

openssl req -config

myserver.key -out myserver.csr

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

<li>

</li>

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

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

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

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

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

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

openssl x509 -in myserver.csr -out

execute the following:

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

openssl x509 -in myserver.csr

Set the "sslCertificateFilePath" configuration property to point to this

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

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

Set the "sslCertificateFilePath" configuration property to point to

created.

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

certificate is created.

</li>

</ul>

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

After creating the keypair, make sure you protect the information

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

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

shows the recommended privileges:

The following table shows the recommended privileges:

<tbody>

<tr>

<th>

SSL file</th>

<th>Pegasus Config property</th>

<th>

<th>Permissions</th>

Pegasus Config property</th>

<th>

Permissions</th>

</tr>

<tr>

<td>Private key</td>

Line 199

Line 178

</tr>

<tr>

<td>CRL store

<td>CRL store </td>

</td>

<td>crlStore</td>

</tr>

</tbody>

</table>

The administrator is responsible for ensuring that the above file permissions

The administrator is responsible for ensuring that the above file

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

permissions are set correctly. The administrator should also ensure

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

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

Pegasus only checks the following conditions when starting up:

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

when starting up:

<ul>

<li>

<ul>

The sslKeyFilePath and the sslCertificateFilePath are readable by the CIMOM.

<li>The sslKeyFilePath and the sslCertificateFilePath are readable by

<li>

the CIMOM.</li>

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

<li>The sslTrustStore and crlStore are readable

file.

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

<li>

<li>The sslTrustStore and crlStore are readable

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

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

are a directory.</li>

</ul>

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

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

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

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

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

documentation</a>.

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 is a

There are many environment variable settings associated with SSL. Here

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

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

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

work together to

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

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

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

recommended settings can be found in PEP#200 Recommended OpenPegasus

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

2.5 Build and Configuration Options for Selected Platforms.

be for a given application.

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

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 all

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

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

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

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

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

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

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

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

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

on the following platforms:

is enabled by default only on the following platforms:

<ul>

<li>

<li>LINUX</li>

LINUX

<li>

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

OS-400

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

<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

sslCertificateFilePath

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

certificates beginning with the server certificate and followed by each

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

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

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

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

beginning with the server certificate and followed by each signing certificate

self-signed certificate in PEM format.

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

The certificate cannot be encrypted because there is currently no

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

mechanism for decrypting the certificate using a user-supplied

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

password. This property must be defined if enableHttpsConnection is

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

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

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

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

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

for more information.

Creating SSL Certificates</a> for more information.

sslKeyFilePath

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

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

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

least 1024 bytes long. This property must be defined if

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

enableHttpsConnection is true. Any failure in finding this file will

Creating SSL Certificate</a> for more information.

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

SSL Certificate</a> for more information.

sslClientVerificationMode

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

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

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

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

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

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

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

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

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

going to use basic authentication to authenticate all client requests.

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

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

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

username and password, basic authentication is sufficient. Other

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

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

variable also impacts what happens during the OpenSSL handshake:

allow both basic authentication and SSL certificate verification. The

setting of this variable also impacts what happens during the OpenSSL

<ul>

handshake:

<li>

<ul>

"required"

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

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

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

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

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

untrusted certificate, the handshake is immediately terminated.

the handshake is immediately terminated.</li>

<li>

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

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

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

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

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

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

seek to authenticate the client via an alternative method of

an alternative method of authentication.

authentication. As

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

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

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

handshake will fail. Before 2.5.1,the handshake would have

authentication would have proceeded.

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

<li>

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

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

certificate. This is the default.</li>

is the default.</li>

</ul>

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

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

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

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

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

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

authenticated via basic authentication. The providers

authentication. The providers receive the username that the certificate was

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

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

Authorization section

for more information.

sslTrustStore

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

This setting controls the truststore for the cimserver's HTTPS

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

connection. It can be

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

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

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

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

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

truststore as there are strict naming requirements for trusted

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. It is

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

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

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

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

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

independently of the sslTrustStore setting. This property represents the valid

validation of the property is done independently of the sslTrustStore

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

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

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

the root certificate. All requests authenticated with a certificate

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

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

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

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

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

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

cimtrust CLI</a>.

recommended that each certificate be registered individually using the

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

crlStore

crlStore

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

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

It is important to note that certificates are

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

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

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

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

should be used for CRL management.

CRL management.

sslCipherSuite

This setting specifies the cipher list used by the server during the

SSL handshake phase. If not specified, the "DEFAULT" OpenSSL cipher

list is used. The cipher list should be mentioned between single

quotes since it can contain special characters like .+, !, -. The

cipher lists can be found at <a

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

sslBackwardCompatibility

This setting specifies whether the ssl supports SSLv3 and versions of TLS

lesser than 1.2. Ideally for security Compilance purposes it is by default

set to false.

<h4>Configuration Limitations</h4>

The following are configuration limitations:

<ul>

<li>

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

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

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

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

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

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

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

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

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

<li>

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

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

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

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_">

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

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

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

<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>

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

<li>

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

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

up to 9 levels deep.

<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 configure Pegasus

The following questions may be helpful in determining how to

CIM Server.

configure Pegasus CIM Server.

Should I enable the HTTPS port?

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

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

be disabled for additional security if desired.

port can 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 are using

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

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

are using basic authentication over the secure port

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

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

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

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

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

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

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

CIMOM certificate is compromised, the cimserver and the providers

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

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

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

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

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

password is compromised, the entire system may be compromised.

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

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

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

cimserver is properly configured to use a truststore,

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

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

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

authorization checks are performed after a certificate is verified.

certificate authority?

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

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 or another third-party

self-signed certificate or one issued by Verisign

certificate authority. If an administrator administrates their self-signed

or another third-party certificate authority.

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

If an administrator administrates their self-signed certificates

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

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

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

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

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

relationship will be offset by the convenience of having that CA

never outweigh the initial CA-setup cost.

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

deployments the incremental cost might never outweigh the initial

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

CA-setup cost.

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

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

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

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

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

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

remain secure.

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

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 clients, then

If you only anticipate connections from a narrowly defined set of

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

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

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

Alternatively, multiple trusted certificates may be stored in PEM

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

format inside of a single CA file.

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

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

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

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

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

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

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

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

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

to register it.

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

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

users will be connecting with it.

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

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 a

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

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

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

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

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

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

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

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

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

Certificates</a> for the recommended file privileges.

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

privileges.

When do I need to use a CRL?

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

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

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

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

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

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

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

supports them). Pegasus itself

responsibility of the administrator to regularly download or acquire the CRL

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

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

responsibility of the administrator

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

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

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

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

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

CRLs are not checked

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

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

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

particular issuer has expired,

a critical extension it will be ignored.

Pegasus still accepts certificates from the issuer and uses the expired

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

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

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

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

extensions during CRL verification. If a CRL contains a critical

this, the certificate deletion option available via cimtrust is primarily

extension it will be ignored.

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

to revoke compromised or invalid certificates.

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

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 rest

The certificate is checked against any CRLs first before going through

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

the rest of the verification process. Verification starts with the

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

root certificate and continues down to the peer certificate. If

points, the certificate is considered untrusted and the verification process

verification fails at any of these points, the certificate is

reports an error.

considered

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: The client

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"trust all client certificates."

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

all client certificates."

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

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

sslClientVerificationMode

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

property to "required."

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

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

To tell the cimserver to trust all clients, set the

sslClientVerificationMode

property to "disabled" or "optional".

The SSL verification in Pegasus is independent of any other authentication

The SSL verification in Pegasus is independent of any other

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

authentication mechanism. It can still be utilized when authentication

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

is disabled.

verification. In situations where a

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

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

verification.

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

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

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

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

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

will attempt to authenticate the client via another method of

for remote connections and local authentication will be used for local

authentication . In this case, the authentication mechanism specified

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

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

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

connections and local authentication will be used for local

connections.

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

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

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

client certificate was invalid, the handshake will be terminated.

behavior, the compile-time flag PEGASUS_OVERRIDE_SSL_CERT_VERIFICATION_RESULT

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

should be defined.

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

enable the legacy behavior, the compile-time flag

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

PEGASUS_OVERRIDE_SSL_CERT_VERIFICATION_RESULT should be defined.

below on how to setup the client's truststore.

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

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

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

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

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

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

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

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

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

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

on the PG_SSLCertificate and PG_SSLCertificateRevocationList classes in

X509 Certificate Revocation Lists in a PEM format CRL store.

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>

<li>OpenSSL places strict naming restrictions on certificates and

OpenSSL places strict naming restrictions on certificates and CRLs in a

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

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

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

<li>

corresponding username. If the certificate is not properly registered,

Certificate instances are stored in the repository along with the corresponding

the username mapping will fail. <span

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

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

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

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

accomplish this.</li>

<li>

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

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

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

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

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

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

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

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

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

constructor that takes an SSLContext. The construction of the

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

SSLContext is really what controls the behavior of the client during

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

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

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

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

various SSLContext constructor parameters.

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

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

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

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

also checks the server certificate against its truststore and specifies

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

an additional callback in addition to the default one (the

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

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

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);

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

</ul>

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

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

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

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

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

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

certificate against its truststore.

<ul>

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

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

randomFile), username password);

NULL, randomFile), username password);

</ul>

<ul>

<li>

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

trustStore

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

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

no truststore exists. </li>

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

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

<li>

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

certPath

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

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

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

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

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

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

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

specified.

specified.</li>

<li>

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

keyPath

client checks the CRL list first, before attempting any further

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

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

the certPath parameter must also be specified.

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

<li>

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

crlPath

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

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

servers" or to perform additional authentication checks that OpenSSL

first, before attempting any further authentication, including the

does not perform by default.</li>

user-specified callback.

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

<li>

generator (PRNG).</li>

verifyCert

<li>cipherSuite -- This specifies the cipher list used by the

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

client during the SSL handshake phase. This is an experimental

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

interface.</li>

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

</ul>

that OpenSSL does not perform by default.

Here are some general guidelines on implementing peer verification

<li>

for the client:

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

</ul>

<ul>

Here are some general guidelines on implementing peer verification for the

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

client:

truststore and (optionally) a user-specified callback function.</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

<li>

trusted CA certificates. The cimtrust CLI cannot be used to

The client should enable peer verification by specifying a truststore and

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

(optionally) a user-specified callback function.

placed in a protected file or directory specified by the trustStore

<li>

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

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

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

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

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

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

to the default verification callback, if additional verifications are

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

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

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

the default verification callback is sufficient for checking server

reloaded to pick up any truststore changes.

certificates.</li>

<li>

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

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

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

verification callback, if additional verifications are desired over the normal

certificates that support one.</li>

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

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

is sufficient for checking server certificates.

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

<li>

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

The client should ensure that adequate entropy is attained.

<ul>

<li>

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

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

<ul>

that support one.

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

<li>

certificate is perfectly valid and authenticates against all trust

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

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

is not built with SSLv2 support.

the client is not providing server authentication and could have a

<li>

security bulletin class defect.</li>

The client should perform post-connection checks.

</ul>

<ul>

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

<li>

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

Ensure a certificate was received.

<ul>

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

<li>

subject matches the host name of the server.  For X509v3

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

certificates, the “SubjectAltName” fields

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

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

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

the certificate. </li>

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

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

</ul>

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

<li>

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

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

identity.  Any other server which was issued a certificate from

client was attempting to connect.

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

<ul>

performs the host name check.</li>

<li>

</ul>

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

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

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

errors.</li>

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

</ul>

the certificate.

</ul>

<li>

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

Because only the above arguments can be passed into the Pegasus

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

SSLContext, there are some limitations in the client configuration:

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

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

<ul>

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

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

</ul>

default OpenSSL depth of 9.</li>

<li>

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

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

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

</ul>

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

</li>

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

</ul>

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 authenticated by

The following paragraphs concern authorization of users

certificate on the cimserver's HTTPS port.

authenticated by certificate on the cimserver's HTTPS port.

It is important to note that SSL certificates are verified during

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

the initial handshake, BEFORE any further authentication takes place.

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

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

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

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

exception. This scenario will occur if the sslClientVerification property is

sslClientVerification property is set to "required" and no certificate

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

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

Further authorization checks must be performed when validating

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

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

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

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

In the case of

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 pam_acct_mgmt

Additionally, if Pegasus was configured to use PAM, the

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

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

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

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

authenticated via basic authentication are still applied to a user

been placed on a user authenticated via basic authentication are still

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

applied to a user authenticated via certificate. The pam_authenticate

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

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

was mapped to the certificate in the OperationContext.

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

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 719

Line 673

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 with

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

OpenSSL or go to the OpenSSL Site:

with 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

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

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 743

Line 696

<hr>

Licensed to The Open Group (TOG) under one or more contributor license

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

agreements. Refer to the OpenPegasusNOTICE.txt file distributed with

this work for additional information regarding copyright ownership.

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

Each contributor licenses this file to you under the OpenPegasus Open

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

Source License; you may not use this file except in compliance with the

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

License.

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

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

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

copy of this software and associated documentation files (the "Software"),

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

to deal in the Software without restriction, including without limitation

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

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

THE ABOVE COPYRIGHT NOTICE AND THIS PERMISSION NOTICE SHALL

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

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

The above copyright notice and this permission notice shall be included

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

in all copies or substantial portions of the Software.

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

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS

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

OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF

MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

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

IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY

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

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.4.1
changed lines
	Added in v.1.8

No CVS admin address has been configured