Cari di RHE Linux 
    RHE Linux User Manual
Daftar Isi
(Sebelumnya) 17 : Chapter 4. Setting up Ent ...18 : Migration Planning Guide (Berikutnya)

Chapter 6. Configuring Applications for Single Sign-On

After a smart card is enrolled, the smart card can be used for SSL client authentication and S/MIME email applications. The PKCS #11 module used by these applications, by default, is located in /usr/lib/libcoolkeypk11.so.

6.1. Configuring Firefox to Use Kerberos for Single Sign-On

Firefox can use Kerberos for single sign-on to intranet sites and other protected websites. For Firefox to use Kerberos, it first has to be configured to send Kerberos credentials to the appropriate KDC.
  1. In the address bar of Firefox, type about:config to display the list of current configuration options.
  2. In the Filter field, type negotiate to restrict the list of options.
  3. Double-click the network.negotiate-auth.trusted-uris entry.
  4. Enter the name of the domain against which to authenticate.
  5. Next, configure the network.negotiate-auth.delegation-uris entry, using the same domain as for network.negotiate-auth.trusted-uris.

NOTE

Even after Firefox is configured to pass Kerberos credentials, it still requires a valid Kerberos ticket to use. To generate a Kerberos ticket, use the kinit command and supply the user password for the user on the KDC.
[jsmith@host ~] $ kinitPassword for [email protected]:

If Kerberos authentication is not working, turn on verbose logging for the authentication process.
  1. Close all instances of Firefox.
  2. In a command prompt, export values for the NSPR_LOG_* variables:
    export NSPR_LOG_MODULES=negotiateauth:5export NSPR_LOG_FILE=/tmp/moz.log
  3. Restart Firefox from that shell, and visit the website where Kerberos authentication is failing.
  4. Check the /tmp/moz.log file for error messages with nsNegotiateAuth in the message.

There are several common errors that occur with Kerberos authentication.
  • The first error says that no credentials have been found.
    -1208550944[90039d0]: entering nsNegotiateAuth::GetNextToken()-1208550944[90039d0]: gss_init_sec_context() failed: Miscellaneous failureNo credentials cache found

    This means that there are no Kerberos tickets (meaning that they expired or were not generated). To fix this, run kinit to generate the Kerberos ticket and then open the website again.
  • The second potential error is if the browser is unable to contact the KDC, with the message Server not found in Kerberos database.
    -1208994096[8d683d8]: entering nsAuthGSSAPI::GetNextToken()-1208994096[8d683d8]: gss_init_sec_context() failed: Miscellaneous failureServer not found in Kerberos database

    This is usually a Kerberos configuration problem. The correct entries must be in the [domain_realm] section of the /etc/krb5.conf file to identify the domain. For example:
    .example.com = EXAMPLE.COMexample.com = EXAMPLE.COM
  • If there are no errors in the log, then the problem could be that an HTTP proxy server is stripping off the HTTP headers required for Kerberos authentication. Try to connect to the site using HTTPS, which allows the request to pass through unmodified.

6.2. Enabling Smart Card Login

Smart card login for Red Hat Enterprise Linux servers and workstations is not enabled by default and must be enabled in the system settings.

NOTE

Using single sign-on when logging into Red Hat Enterprise Linux requires these packages:
  • nss-tools
  • esc
  • pam_pkcs11
  • coolkey
  • ccid
  • gdm
  • authconfig
  • authconfig-gtk
  • krb5-libs
  • krb5-workstation
  • krb5-auth-dialog
  • krb5-pkinit-openssl
  1. Log into the system as root.
  2. Download the root CA certificates for the network in base 64 format, and install them on the server. The certificates are installed in the appropriate system database using the certutil command. For example:
    # certutil -A -d /etc/pki/nssdb -n "root CA cert" -t "CT,C,C" -i /tmp/ca_cert.crt
  3. In the top menu, select the System menu, select Administration, and then click Authentication.
  4. Open the Advanced Options tab.
  5. Click the Enable Smart Card Support checkbox.
  6. When the button is active, click Configure smart card ....

    There are two behaviors that can be configured for smart cards:
    • The Require smart card for login checkbox requires smart cards and essentially disables Kerberos password authentication for logging into the system. Do not select this until after you have successfully logged in using a smart card.
    • The Card removal action menu sets the response that the system takes if the smart card is removed during an active session. Ignore means that the system continues functioning as normal if the smart card is removed, while Lock immediately locks the screen.
  7. By default, the mechanisms to check whether a certificate has been revoked (Online Certificate Status Protocol, or OCSP, responses) are disabled. To validate whether a certificate has been revoked before its expiration period, enable OCSP checking by adding the ocsp_on option to the cert_policy directive.
    1. Open the pam_pkcs11.conf file.
      vim /etc/pam_pkcs11/pam_pkcs11.conf
    2. Change every cert_policy line so that it contains the ocsp_on option.
      cert_policy =ca, ocsp_on, signature;

      NOTE

      Because of the way the file is parsed, there must be a space between cert_policy and the equals sign. Otherwise, parsing the parameter fails.
  8. If the smart card has not yet been enrolled (set up with personal certificates and keys), enroll the smart card, as described in Section 5.3, "Enrolling a Smart Card Automatically".
  9. If the smart card is a CAC card, the PAM modules used for smart card login must be configured to recognize the specific CAC card.
    1. As root, create a file called /etc/pam_pkcs11/cn_map.
    2. Add the following entry to the cn_map file:
      MY.CAC_CN.123454 -> login

      MY.CAC_CN.123454 is the common name on the CAC card and login is the Red Hat Enterprise Linux login ID.

TIP

When a smart card is inserted, the pklogin_finder tool (in debug mode) first maps the login ID to the certificates on the card and then attempts to output information about the validity of certificates.
pklogin_finder debug

This is useful for diagnosing any problems with using the smart card to log into the system.

6.3. Setting up Browsers to Support SSL for Tokens

  1. In Mozilla Firefox, open the Edit menu, choose Preferences, and then click Advanced.
  2. Open the Encryption tab.
  3. Add a PKCS #11 driver.
    1. Click Security Devices to open the Device Manager window, and then click the Load button.
    2. Enter a module name, such as token key pk11 driver.
    3. Click Browse, find the Enterprise Security Client PKCS #11 driver, and click OK. The PKCS #11 module used by these applications, by default, is located in /usr/lib/libcoolkeypk11.so.
  4. If the CA is not yet trusted, download and import the CA certificate.
    1. Open the SSL End Entity page on the CA. For example:
      https://server.example.com:9444/ca/ee/ca/
    2. Click the Retrieval tab, and then click Import CA Certificate Chain.
    3. Click Download the CA certificate chain in binary form and then click Submit.
    4. Choose a suitable directory to save the certificate chain, and then click OK.
    5. Click Edit > Preferences, and select the Advanced tab.
    6. Click the View Certificates button.
    7. Click Authorities, and import the CA certificate.
  5. Set the certificate trust relationships.
    1. Click Edit > Preferences, and select the Advanced tab.
    2. Click the View Certificates button.
    3. Click Edit, and set the trust for websites.

The certificates can be used for SSL.

6.4. Using the Certificates on Tokens for Mail Clients

  1. In Mozilla Thunderbird, open the Edit menu, choose Preferences, and then click Advanced.
  2. Open the Certificate tab.
  3. Add a PKCS #11 driver.
    1. Click Security Devices to open the Device Manager window.
    2. Click the Load button.
    3. Enter the module name, such as token keypk11 driver.
    4. Click Browse, find the Enterprise Security Client PKCS #11 driver, and click OK. The PKCS #11 module used by these applications, by default, is located in /usr/lib/libcoolkeypk11.so.
  4. If the CA is not yet trusted, download and import the CA certificate.
    1. Open the SSL End Entity page on the CA. For example:
      https://server.example.com:9444/ca/ee/ca/
    2. Click the Retrieval tab, and then click Import CA Certificate Chain.
    3. Click Download the CA certificate chain in binary form and then click Submit.
    4. Choose a suitable directory to save the certificate chain, and then click OK.
    5. In Mozilla Thunderbird, open the Edit menu, choose Preferences, and then click Advanced.
    6. Open the Certificate tab, and click the View Certificates button.
    7. Click the Authorities tab, and import the CA certificate.
  5. Set up the certificate trust relationships.
    1. In Mozilla Thunderbird, open the Edit menu, choose Preferences, and then click Advanced.
    2. Open the Certificate tab, and click the View Certificates button.
    3. In the Authorities tab, select the CA, and click the Edit button.
    4. Set the trust settings for identifying websites and mail users.
    5. In the Digital Signing section of the Security panel, click Select to choose a certificate to use for signing messages.
  6. In the Encryption of the Security panel, click Select to choose the certificate to encrypt and decrypt messages.

Glossary

A

access control

The process of controlling what particular users are allowed to do. For example, access control to servers is typically based on an identity, established by a password or a certificate, and on rules regarding what that entity can do. See also access control list (ACL).
access control instructions (ACI)

An access rule that specifies how subjects requesting access are to be identified or what rights are allowed or denied for a particular subject. See access control list (ACL).
access control list (ACL)

A collection of access control entries that define a hierarchy of access rules to be evaluated when a server receives a request for access to a particular resource. See access control instructions (ACI).
administrator

The person who installs and configures one or more Certificate System managers and sets up privileged users, or agents, for them. See also agent.
Advanced Encryption Standard (AES)

The Advanced Encryption Standard (AES), like its predecessor Data Encryption Standard (DES), is a FIPS-approved symmetric-key encryption standard. AES was adopted by the US government in 2002. It defines three block ciphers, AES-128, AES-192 and AES-256. The National Institute of Standards and Technology (NIST) defined the AES standard in U.S. FIPS PUB 197. For more information, see http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf.
agent

A user who belongs to a group authorized to manage agent services for a Certificate System manager. See also Certificate Manager agent, Data Recovery Manager agent.
agent services

1. Services that can be administered by a Certificate System agent through HTML pages served by the Certificate System subsystem for which the agent has been assigned the necessary privileges.

2. The HTML pages for administering such services.
agent-approved enrollment

An enrollment that requires an agent to approve the request before the certificate is issued.
APDU

Application protocol data unit. A communication unit (analogous to a byte) that is used in communications between a smart card and a smart card reader.
attribute value assertion (AVA)

An assertion of the form attribute = value, where attribute is a tag, such as o (organization) or uid (user ID), and value is a value such as "Red Hat, Inc." or a login name. AVAs are used to form the distinguished name (DN) that identifies the subject of a certificate, called the subject name of the certificate.
audit log

A log that records various system events. This log can be signed, providing proof that it was not tampered with, and can only be read by an auditor user.
auditor

A privileged user who can view the signed audit logs.
authentication

Confident identification; assurance that a party to some computerized transaction is not an impostor. Authentication typically involves the use of a password, certificate, PIN, or other information to validate identity over a computer network. See also password-based authentication, certificate-based authentication, client authentication, server authentication.
authentication module

A set of rules (implemented as a Java™ class) for authenticating an end entity, agent, administrator, or any other entity that needs to interact with a Certificate System subsystem. In the case of typical end-user enrollment, after the user has supplied the information requested by the enrollment form, the enrollment servlet uses an authentication module associated with that form to validate the information and authenticate the user's identity. See servlet.
authorization

Permission to access a resource controlled by a server. Authorization typically takes place after the ACLs associated with a resource have been evaluated by a server. See access control list (ACL).
automated enrollment

A way of configuring a Certificate System subsystem that allows automatic authentication for end-entity enrollment, without human intervention. With this form of authentication, a certificate request that completes authentication module processing successfully is automatically approved for profile processing and certificate issuance.

B

bind DN

A user ID, in the form of a distinguished name (DN), used with a password to authenticate to Red Hat Directory Server.

C

CA certificate

A certificate that identifies a certificate authority. See also certificate authority (CA), subordinate CA, root CA.
CA hierarchy

A hierarchy of CAs in which a root CA delegates the authority to issue certificates to subordinate CAs. Subordinate CAs can also expand the hierarchy by delegating issuing status to other CAs. See also certificate authority (CA), subordinate CA, root CA.
CA server key

The SSL server key of the server providing a CA service.
CA signing key

The private key that corresponds to the public key in the CA certificate. A CA uses its signing key to sign certificates and CRLs.
certificate

Digital data, formatted according to the X.509 standard, that specifies the name of an individual, company, or other entity (the subject name of the certificate) and certifies that a public key, which is also included in the certificate, belongs to that entity. A certificate is issued and digitally signed by a certificate authority (CA). A certificate's validity can be verified by checking the CA's digital signature through public-key cryptography techniques. To be trusted within a public-key infrastructure (PKI), a certificate must be issued and signed by a CA that is trusted by other entities enrolled in the PKI.
certificate authority (CA)

A trusted entity that issues a certificate after verifying the identity of the person or entity the certificate is intended to identify. A CA also renews and revokes certificates and generates CRLs. The entity named in the issuer field of a certificate is always a CA. Certificate authorities can be independent third parties or a person or organization using certificate-issuing server software, such as Red Hat Certificate System.
certificate chain

A hierarchical series of certificates signed by successive certificate authorities. A CA certificate identifies a certificate authority (CA) and is used to sign certificates issued by that authority. A CA certificate can in turn be signed by the CA certificate of a parent CA, and so on up to a root CA. Certificate System allows any end entity to retrieve all the certificates in a certificate chain.
certificate extensions

An X.509 v3 certificate contains an extensions field that permits any number of additional fields to be added to the certificate. Certificate extensions provide a way of adding information such as alternative subject names and usage restrictions to certificates. A number of standard extensions have been defined by the PKIX working group.
certificate fingerprint

A one-way hash associated with a certificate. The number is not part of the certificate itself, but is produced by applying a hash function to the contents of the certificate. If the contents of the certificate changes, even by a single character, the same function produces a different number. Certificate fingerprints can therefore be used to verify that certificates have not been tampered with.
Certificate Management Message Formats (CMMF)

Message formats used to convey certificate requests and revocation requests from end entities to a Certificate Manager and to send a variety of information to end entities. A proposed standard from the Internet Engineering Task Force (IETF) PKIX working group. CMMF is subsumed by another proposed standard, Certificate Management Messages over Cryptographic Message Syntax (CMC). For detailed information, see http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmmf-02.txt.
Certificate Management Messages over Cryptographic Message Syntax (CMC)

Message format used to convey a request for a certificate to a Certificate Manager. A proposed standard from the Internet Engineering Task Force (IETF) PKIX working group. For detailed information, see http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-02.txt.
Certificate Manager

An independent Certificate System subsystem that acts as a certificate authority. A Certificate Manager instance issues, renews, and revokes certificates, which it can publish along with CRLs to an LDAP directory. It accepts requests from end entities. See certificate authority (CA).
Certificate Manager agent

A user who belongs to a group authorized to manage agent services for a Certificate Manager. These services include the ability to access and modify (approve and reject) certificate requests and issue certificates.
certificate profile

A set of configuration settings that defines a certain type of enrollment. The certificate profile sets policies for a particular type of enrollment along with an authentication method in a certificate profile.
Certificate Request Message Format (CRMF)

Format used for messages related to management of X.509 certificates. This format is a subset of CMMF. See also Certificate Management Message Formats (CMMF). For detailed information, see ftp://ftp.isi.edu/in-notes/rfc2511.txt.
certificate revocation list (CRL)

As defined by the X.509 standard, a list of revoked certificates by serial number, generated and signed by a certificate authority (CA).
Certificate System

See Red Hat Certificate System, Cryptographic Message Syntax (CS).
Certificate System console

A console that can be opened for any single Certificate System instance. A Certificate System console allows the Certificate System administrator to control configuration settings for the corresponding Certificate System instance.
Certificate System subsystem

One of the five Certificate System managers: Certificate Manager, Online Certificate Status Manager, Data Recovery Manager, Token Key Service, or Token Processing System.
certificate-based authentication

Authentication based on certificates and public-key cryptography. See also password-based authentication.
chain of trust

See certificate chain.
chained CA

See linked CA.
cipher

See cryptographic algorithm.
client authentication

The process of identifying a client to a server, such as with a name and password or with a certificate and some digitally signed data. See certificate-based authentication, password-based authentication, server authentication.
client SSL certificate

A certificate used to identify a client to a server using the SSL protocol. See Secure Sockets Layer (SSL).
CMC

See Certificate Management Messages over Cryptographic Message Syntax (CMC).
CMC Enrollment

Features that allow either signed enrollment or signed revocation requests to be sent to a Certificate Manager using an agent's signing certificate. These requests are then automatically processed by the Certificate Manager.
CMMF

See Certificate Management Message Formats (CMMF).
Common Criteria

A certification standard that evaluates computer security, both for software and hardware components. The software or hardware vendor defines the operating environment and specified configuration, identifies any threats, and outlines both the development and deployment processes for the target of evaluation (the thing being evaluated). The Common Criteria certification laboratory then tests the implementation design to look for any vulnerabilities.
CRL

See certificate revocation list (CRL).
CRMF

See Certificate Request Message Format (CRMF).
cross-certification

The exchange of certificates by two CAs in different certification hierarchies, or chains. Cross-certification extends the chain of trust so that it encompasses both hierarchies. See also certificate authority (CA).
cross-pair certificate

A certificate issued by one CA to another CA which is then stored by both CAs to form a circle of trust. The two CAs issue certificates to each other, and then store both cross-pair certificates as a certificate pair.
cryptographic algorithm

A set of rules or directions used to perform cryptographic operations such as encryption and decryption.
Cryptographic Message Syntax (CS)

The syntax used to digitally sign, digest, authenticate, or encrypt arbitrary messages, such as CMMF.
cryptographic module

See PKCS #11 module.
cryptographic service provider (CSP)

A cryptographic module that performs cryptographic services, such as key generation, key storage, and encryption, on behalf of software that uses a standard interface such as that defined by PKCS #11 to request such services.
CSP

See cryptographic service provider (CSP).

D

Data Recovery Manager

An optional, independent Certificate System subsystem that manages the long-term archival and recovery of RSA encryption keys for end entities. A Certificate Manager can be configured to archive end entities' encryption keys with a Data Recovery Manager before issuing new certificates. The Data Recovery Manager is useful only if end entities are encrypting data, such as sensitive email, that the organization may need to recover someday. It can be used only with end entities that support dual key pairs: two separate key pairs, one for encryption and one for digital signatures.
Data Recovery Manager agent

A user who belongs to a group authorized to manage agent services for a Data Recovery Manager, including managing the request queue and authorizing recovery operation using HTML-based administration pages.
Data Recovery Manager recovery agent

One of the m of n people who own portions of the storage key for the Data Recovery Manager.
Data Recovery Manager storage key

Special key used by the Data Recovery Manager to encrypt the end entity's encryption key after it has been decrypted with the Data Recovery Manager's private transport key. The storage key never leaves the Data Recovery Manager.
Data Recovery Manager transport certificate

Certifies the public key used by an end entity to encrypt the entity's encryption key for transport to the Data Recovery Manager. The Data Recovery Manager uses the private key corresponding to the certified public key to decrypt the end entity's key before encrypting it with the storage key.
decryption

Unscrambling data that has been encrypted. See encryption.
delta CRL

A CRL containing a list of those certificates that have been revoked since the last full CRL was issued.
digital ID

See certificate.
digital signature

To create a digital signature, the signing software first creates a one-way hash from the data to be signed, such as a newly issued certificate. The one-way hash is then encrypted with the private key of the signer. The resulting digital signature is unique for each piece of data signed. Even a single comma added to a message changes the digital signature for that message. Successful decryption of the digital signature with the signer's public key and comparison with another hash of the same data provides tamper detection. Verification of the certificate chain for the certificate containing the public key provides authentication of the signer. See also nonrepudiation, encryption.
distinguished name (DN)

A series of AVAs that identify the subject of a certificate. See attribute value assertion (AVA).
distribution points

Used for CRLs to define a set of certificates. Each distribution point is defined by a set of certificates that are issued. A CRL can be created for a particular distribution point.
dual key pair

Two public-private key pairs, four keys altogether, corresponding to two separate certificates. The private key of one pair is used for signing operations, and the public and private keys of the other pair are used for encryption and decryption operations. Each pair corresponds to a separate certificate. See also encryption key, public-key cryptography, signing key.

E

eavesdropping

Surreptitious interception of information sent over a network by an entity for which the information is not intended.
Elliptic Curve Cryptography (ECC)

A cryptographic algorithm which uses elliptic curves to create additive logarithms for the mathematical problems which are the basis of the cryptographic keys. ECC ciphers are more efficient to use than RSA ciphers and, because of their intrinsic complexity, are stronger at smaller bits than RSA ciphers. For more information, see http://ietfreport.isoc.org/idref/draft-ietf-tls-ecc/.
encryption

Scrambling information in a way that disguises its meaning. See decryption.
encryption key

A private key used for encryption only. An encryption key and its equivalent public key, plus a signing key and its equivalent public key, constitute a dual key pair.
end entity

In a public-key infrastructure (PKI), a person, router, server, or other entity that uses a certificate to identify itself.
enrollment

The process of requesting and receiving an X.509 certificate for use in a public-key infrastructure (PKI). Also known as registration.
extensions field

See certificate extensions.

F

Federal Bridge Certificate Authority (FBCA)

A configuration where two CAs form a circle of trust by issuing cross-pair certificates to each other and storing the two cross-pair certificates as a single certificate pair.
fingerprint

See certificate fingerprint.
FIPS PUBS 140

Federal Information Standards Publications (FIPS PUBS) 140 is a US government standard for implementations of cryptographic modules, hardware or software that encrypts and decrypts data or performs other cryptographic operations, such as creating or verifying digital signatures. Many products sold to the US government must comply with one or more of the FIPS standards. See http://www.nist.gov/itl/fipscurrent.cfm.
firewall

A system or combination of systems that enforces a boundary between two or more networks.

I

impersonation

The act of posing as the intended recipient of information sent over a network. Impersonation can take two forms: spoofing and misrepresentation.
input

In the context of the certificate profile feature, it defines the enrollment form for a particular certificate profile. Each input is set, which then dynamically creates the enrollment form from all inputs configured for this enrollment.
intermediate CA

A CA whose certificate is located between the root CA and the issued certificate in a certificate chain.
IP spoofing

The forgery of client IP addresses.

J

JAR file

A digital envelope for a compressed collection of files organized according to the Java™ archive (JAR) format.
Java™ archive (JAR) format

A set of conventions for associating digital signatures, installer scripts, and other information with files in a directory.
Java™ Cryptography Architecture (JCA)

The API specification and reference developed by Sun Microsystems for cryptographic services. See http://java.sun.com/products/jdk/1.2/docs/guide/security/CryptoSpec.Introduction.
Java™ Development Kit (JDK)

Software development kit provided by Sun Microsystems for developing applications and applets using the Java™ programming language.
Java™ Native Interface (JNI)

A standard programming interface that provides binary compatibility across different implementations of the Java™ Virtual Machine (JVM) on a given platform, allowing existing code written in a language such as C or C++ for a single platform to bind to Java™. See http://java.sun.com/products/jdk/1.2/docs/guide/jni/index.html.
Java™ Security Services (JSS)

A Java™ interface for controlling security operations performed by Netscape Security Services (NSS).

K

KEA

See Key Exchange Algorithm (KEA).
key

A large number used by a cryptographic algorithm to encrypt or decrypt data. A person's public key, for example, allows other people to encrypt messages intended for that person. The messages must then be decrypted by using the corresponding private key.
key exchange

A procedure followed by a client and server to determine the symmetric keys they will both use during an SSL session.
Key Exchange Algorithm (KEA)

An algorithm used for key exchange by the US Government.

L

Lightweight Directory Access Protocol (LDAP)

A directory service protocol designed to run over TCP/IP and across multiple platforms. LDAP is a simplified version of Directory Access Protocol (DAP), used to access X.500 directories. LDAP is under IETF change control and has evolved to meet Internet requirements.
linked CA

An internally deployed certificate authority (CA) whose certificate is signed by a public, third-party CA. The internal CA acts as the root CA for certificates it issues, and the third- party CA acts as the root CA for certificates issued by other CAs that are linked to the same third-party root CA. Also known as "chained CA" and by other terms used by different public CAs.

M

manual authentication

A way of configuring a Certificate System subsystem that requires human approval of each certificate request. With this form of authentication, a servlet forwards a certificate request to a request queue after successful authentication module processing. An agent with appropriate privileges must then approve each request individually before profile processing and certificate issuance can proceed.
MD5

A message digest algorithm that was developed by Ronald Rivest. See also one-way hash.
message digest

See one-way hash.
misrepresentation

The presentation of an entity as a person or organization that it is not. For example, a website might pretend to be a furniture store when it is really a site that takes credit-card payments but never sends any goods. Misrepresentation is one form of impersonation. See also spoofing.

N

Netscape Security Services (NSS)

A set of libraries designed to support cross-platform development of security-enabled communications applications. Applications built using the NSS libraries support the Secure Sockets Layer (SSL) protocol for authentication, tamper detection, and encryption, and the PKCS #11 protocol for cryptographic token interfaces. NSS is also available separately as a software development kit.
non-TMS

Non-token management system. Refers to a configuration of subsystems (the CA and, optionally, DRM, OCSP, and RA) which do not handle smart cards directly.

See Also token management system (TMS).

nonrepudiation

The inability by the sender of a message to deny having sent the message. A digital signature provides one form of nonrepudiation.

O

object signing

A method of file signing that allows software developers to sign Java code, JavaScript scripts, or any kind of file and allows users to identify the signers and control access by signed code to local system resources.
object-signing certificate

A certificate that's associated private key is used to sign objects; related to object signing.
OCSP

Online Certificate Status Protocol.
one-way hash

1. A number of fixed-length generated from data of arbitrary length with the aid of a hashing algorithm. The number, also called a message digest, is unique to the hashed data. Any change in the data, even deleting or altering a single character, results in a different value.

2. The content of the hashed data cannot be deduced from the hash.
operation

The specific operation, such as read or write, that is being allowed or denied in an access control instruction.
output

In the context of the certificate profile feature, it defines the resulting form from a successful certificate enrollment for a particular certificate profile. Each output is set, which then dynamically creates the form from all outputs configured for this enrollment.

P

password-based authentication

Confident identification by means of a name and password. See also authentication, certificate-based authentication.
PKCS #10

The public-key cryptography standard that governs certificate requests.
PKCS #11

The public-key cryptography standard that governs cryptographic tokens such as smart cards.
PKCS #11 module

A driver for a cryptographic device that provides cryptographic services, such as encryption and decryption, through the PKCS #11 interface. A PKCS #11 module, also called a cryptographic module or cryptographic service provider, can be implemented in either hardware or software. A PKCS #11 module always has one or more slots, which may be implemented as physical hardware slots in some form of physical reader, such as for smart cards, or as conceptual slots in software. Each slot for a PKCS #11 module can in turn contain a token, which is the hardware or software device that actually provides cryptographic services and optionally stores certificates and keys. Red Hat provides a built-in PKCS #11 module with Certificate System.
PKCS #12

The public-key cryptography standard that governs key portability.
PKCS #7

The public-key cryptography standard that governs signing and encryption.
private key

One of a pair of keys used in public-key cryptography. The private key is kept secret and is used to decrypt data encrypted with the corresponding public key.
proof-of-archival (POA)

Data signed with the private Data Recovery Manager transport key that contains information about an archived end-entity key, including key serial number, name of the Data Recovery Manager, subject name of the corresponding certificate, and date of archival. The signed proof-of-archival data are the response returned by the Data Recovery Manager to the Certificate Manager after a successful key archival operation. See also Data Recovery Manager transport certificate.
public key

One of a pair of keys used in public-key cryptography. The public key is distributed freely and published as part of a certificate. It is typically used to encrypt data sent to the public key's owner, who then decrypts the data with the corresponding private key.
public-key cryptography

A set of well-established techniques and standards that allow an entity to verify its identity electronically or to sign and encrypt electronic data. Two keys are involved, a public key and a private key. A public key is published as part of a certificate, which associates that key with a particular identity. The corresponding private key is kept secret. Data encrypted with the public key can be decrypted only with the private key.
public-key infrastructure (PKI)

The standards and services that facilitate the use of public-key cryptography and X.509 v3 certificates in a networked environment.

R

RC2, RC4

Cryptographic algorithms developed for RSA Data Security by Rivest. See also cryptographic algorithm.
Red Hat Certificate System

A highly configurable set of software components and tools for creating, deploying, and managing certificates. Certificate System is comprised of five major subsystems that can be installed in different Certificate System instances in different physical locations: Certificate Manager, Online Certificate Status Manager, Data Recovery Manager, Token Key Service, and Token Processing System.
registration

See enrollment.
root CA

The certificate authority (CA) with a self-signed certificate at the top of a certificate chain. See also CA certificate, subordinate CA.
RSA algorithm

Short for Rivest-Shamir-Adleman, a public-key algorithm for both encryption and authentication. It was developed by Ronald Rivest, Adi Shamir, and Leonard Adleman and introduced in 1978.
RSA key exchange

A key-exchange algorithm for SSL based on the RSA algorithm.

S

sandbox

A Java™ term for the carefully defined limits within which Java™ code must operate.
secure channel

A security association between the TPS and the smart card which allows encrypted communciation based on a shared master key generated by the TKS and the smart card APDUs.
Secure Sockets Layer (SSL)

A protocol that allows mutual authentication between a client and server and the establishment of an authenticated and encrypted connection. SSL runs above TCP/IP and below HTTP, LDAP, IMAP, NNTP, and other high-level network protocols.
security domain

A centralized repository or inventory of PKI subsystems. Its primary purpose is to facilitate the installation and configuration of new PKI services by automatically establishing trusted relationships between subsystems.
self tests

A feature that tests a Certificate System instance both when the instance starts up and on-demand.
server authentication

The process of identifying a server to a client. See also client authentication.
server SSL certificate

A certificate used to identify a server to a client using the Secure Sockets Layer (SSL) protocol.
servlet

Java™ code that handles a particular kind of interaction with end entities on behalf of a Certificate System subsystem. For example, certificate enrollment, revocation, and key recovery requests are each handled by separate servlets.
SHA-1

Secure Hash Algorithm, a hash function used by the US government.
signature algorithm

A cryptographic algorithm used to create digital signatures. Certificate System supports the MD5 and SHA-1 signing algorithms. See also cryptographic algorithm, digital signature.
signed audit log

See audit log.
signing certificate

A certificate that's public key corresponds to a private key used to create digital signatures. For example, a Certificate Manager must have a signing certificate that's public key corresponds to the private key it uses to sign the certificates it issues.
signing key

A private key used for signing only. A signing key and its equivalent public key, plus an encryption key and its equivalent public key, constitute a dual key pair.
single sign-on

1. In Certificate System, a password that simplifies the way to sign on to Red Hat Certificate System by storing the passwords for the internal database and tokens. Each time a user logs on, he is required to enter this single password.

2. The ability for a user to log in once to a single computer and be authenticated automatically by a variety of servers within a network. Partial single sign-on solutions can take many forms, including mechanisms for automatically tracking passwords used with different servers. Certificates support single sign-on within a public-key infrastructure (PKI). A user can log in once to a local client's private-key database and, as long as the client software is running, rely on certificate-based authentication to access each server within an organization that the user is allowed to access.
slot

The portion of a PKCS #11 module, implemented in either hardware or software, that contains a token.
smart card

A small device that contains a microprocessor and stores cryptographic information, such as keys and certificates, and performs cryptographic operations. Smart cards implement some or all of the PKCS #11 interface.
spoofing

Pretending to be someone else. For example, a person can pretend to have the email address [email protected], or a computer can identify itself as a site called www.redhat.com when it is not. Spoofing is one form of impersonation. See also misrepresentation.
SSL

See Secure Sockets Layer (SSL).
subject

The entity identified by a certificate. In particular, the subject field of a certificate contains a subject name that uniquely describes the certified entity.
subject name

A distinguished name (DN) that uniquely describes the subject of a certificate.
subordinate CA

A certificate authority that's certificate is signed by another subordinate CA or by the root CA. See CA certificate, root CA.
symmetric encryption

An encryption method that uses the same cryptographic key to encrypt and decrypt a given message.

T

tamper detection

A mechanism ensuring that data received in electronic form entirely corresponds with the original version of the same data.
token

A hardware or software device that is associated with a slot in a PKCS #11 module. It provides cryptographic services and optionally stores certificates and keys.
token key service (TKS)

A subsystem in the token management system which derives specific, separate keys for every smart card based on the smart card APDUs and other shared information, like the token CUID.
token management system (TMS)

The interrelated subsystems - CA, TKS, TPS, and, optionally, the DRM - which are used to manage certificates on smart cards (tokens).
token processing system (TPS)

A subsystem which interacts directly the Enterprise Security Client and smart cards to manage the keys and certificates on those smart cards.
tree hierarchy

The hierarchical structure of an LDAP directory.
trust

Confident reliance on a person or other entity. In a public-key infrastructure (PKI), trust refers to the relationship between the user of a certificate and the certificate authority (CA) that issued the certificate. If a CA is trusted, then valid certificates issued by that CA can be trusted.

V

virtual private network (VPN)

A way of connecting geographically distant divisions of an enterprise. The VPN allows the divisions to communicate over an encrypted channel, allowing authenticated, confidential transactions that would normally be restricted to a private network.
(Sebelumnya) 17 : Chapter 4. Setting up Ent ...18 : Migration Planning Guide (Berikutnya)