Este contenido no está disponible en el idioma seleccionado.

Chapter 1. Public key certificates in Identity Management


X.509 public key certificates are used to authenticate users, hosts and services in Identity Management (IdM). In addition to authentication, X.509 certificates also enable digital signing and encryption to provide privacy, integrity and non-repudiation.

A certificate contains the following information:

  • The subject that the certificate authenticates.
  • The issuer, that is the CA that has signed the certificate.
  • The start and end date of the validity of the certificate.
  • The valid uses of the certificate.
  • The public key of the subject.

A message encrypted by the public key can only be decrypted by a corresponding private key. While a certificate and the public key it includes can be made publicly available, the user, host or service must keep their private key secret.

1.1. Certificate authorities in IdM

Certificate authorities operate in a hierarchy of trust. In an IdM environment with an internal Certificate Authority (CA), all the IdM hosts, users and services trust certificates that have been signed by the CA. Apart from this root CA, IdM supports sub-CAs to which the root CA has granted the ability to sign certificates in their turn. Frequently, the certificates that such sub-CAs are able to sign are certificates of a specific kind, for example VPN certificates. Finally, IdM supports using external CAs. The table below presents the specifics of using the individual types of CA in IdM.

Table 1.1. Comparison of using integrated and external CAs in IdM
Name of CADescriptionUseUseful links

The ipa CA

An integrated CA based on the Dogtag upstream project

Integrated CAs can create, revoke, and issue certificates for users, hosts, and services.

Using the ipa CA to request a new user certificate and exporting it to the client

IdM sub-CAs

An integrated CA that is subordinate to the ipa CA

IdM sub-CAs are CAs to which the ipa CA has granted the ability to sign certificates. Frequently, these certificates are of a specific kind, for example VPN certificates.

Restricting an application to trust only a subset of certificates

External CAs

An external CA is a CA other than the integrated IdM CA or its sub-CAs.

Using IdM tools, you add certificates issued by these CAs to users, services, or hosts as well as remove them.

Managing externally signed certificates for IdM users, hosts, and services

From the certificate point of view, there is no difference between being signed by a self-signed IdM CA and being signed externally.

The role of the CA includes the following purposes:

  • It issues digital certificates.
  • By signing a certificate, it certifies that the subject named in the certificate owns a public key. The subject can be a user, host or service.
  • It can revoke certificates, and provides revocation status via Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP).

Additional resources

1.2. Comparison of certificates and Kerberos

Certificates perform a similar function to that performed by Kerberos tickets. Kerberos is a computer network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. The following table shows a comparison of Kerberos and X.509 certificates:

Table 1.2. Comparison of certificates and Kerberos

Characteristic

Kerberos

X.509

Authentication

Yes

Yes

Privacy

Optional

Yes

Integrity

Optional

Yes

Type of cryptography involved

Symmetrical

Asymmetrical

Default validity

Short (1 day)

Long(2 years)

By default, Kerberos in Identity Management only ensures the identity of the communicating parties.

1.3. The pros and cons of using certificates to authenticate users in IdM

The advantages of using certificates to authenticate users in IdM include the following points:

  • A PIN that protects the private key on a smart card is typically less complex and easier to remember than a regular password.
  • Depending on the device, a private key stored on a smart card cannot be exported. This provides additional security.
  • Smart cards can make logout automatic: IdM can be configured to log out users when they remove the smart card from the reader.
  • Stealing the private key requires actual physical access to a smart card, making smart cards secure against hacking attacks.
  • Smart card authentication is an example of two-factor authentication: it requires both something you have (the card) and something you know (the PIN).
  • Smart cards are more flexible than passwords because they provide the keys that can be used for other purposes, such as encrypting email.
  • Using smart cards use on shared machines that are IdM clients does not typically pose additional configuration problems for system administrators. In fact, smart card authentication is an ideal choice for shared machines.

The disadvantages of using certificates to authenticate users in IdM include the following points:

  • Users might lose or forget to bring their smart card or certificate and be effectively locked out.
  • Mistyping a PIN multiple times might result in a card becoming locked.
  • There is generally an intermediate step between request and authorization by some sort of security officer or approver. In IdM, the security officer or administrator must run the ipa cert-request command.
  • Smart cards and readers tend to be vendor and driver specific: although a lot of readers can be used for different cards, a smart card of a specific vendor might not work in the reader of another vendor or in the type of a reader for which it was not designed.
  • Certificates and smart cards have a steep learning curve for administrators.
Red Hat logoGithubRedditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

© 2024 Red Hat, Inc.