Identity Management and Certificates

Identity Management (IdM) in Red Hat Enterprise Linux includes an optional Certificate Authority (CA) component. This CA is the same CA included with the Red Hat Certificate System (RHCS). If they’re the same, what is the relationship between IdM and RHCS? Is there a secret plan to replace one with another? This post reviews some of the details associated with each of the offerings and explores different use cases – indicating where you might choose to use one solution over the other.

As explained in my previous post, IdM is a component of Red Hat Enterprise Linux; it is included as a part of your subscription. In a nutshell – IdM focuses on managing identities within the enterprise. Currently, as mentioned above, IdM includes a CA component that is derived from the same community project (Dogtag) as is RHCS.

RHCS, on the other hand, is a product (…and is not included as part of your Red Hat Enterprise Linux subscription). RHCS includes all of the components that are available in the Dogtag community project.

As IdM does not include all of the components available in Dogtag, IdM certificate related capabilities are currently limited. While IdM does issue certificates for hosts and services, it does not issue certificates for users, devices or client side certificates for services connecting to other services. Moreover, IdM cannot manage user smart cards or escrow keys. If you are interested in what may be coming (down the road) and/or if you want to help the community to move new features forward – check out www.FreeIPA.org and related the mailing lists.

In theory, IdM will incorporate additional components from the Dogtag project over time. Does this mean that RHCS will become obsolete? Will it essentially be replaced by IdM? The answer is most likely: no, and the main reason is scope. IdM deals with identities related to the enterprise. These identities belong to the same organization (i.e. they share a single namespace). All certificate operations in IdM are generally related to the identities operating within this namespace. In a sense, this is a controlled environment bound to the same Kerberos domain IdM servers.

On the flip side, RHCS is not bound by namespace. One RHCS deployment can issue certificates for users, devices, and services that are completely unrelated to each other. If, for example, you are considering the provision of certificates as a service – RHCS may be a good server to build your solution around. If, for example, you need to issue and manage certificates for entities operating within the enterprise then IdM would likely be a better choice. That said, RHCS could be used to manage enterprise identities if there is a need to issue certificates not only for internal identities but for external identities (e.g. customer / partners) as well.

In many scenarios, it actually might make sense to consider using both RHCS (as a root CA in the enterprise) and IdM (as a subordinate CA for the internal identities).

As can be seen, though there are a number of similarities, the use case for each solution is quite different and thus there is little sense in merging the offerings or eliminating one altogether… at least for now. Looking ahead, there is an option to offer most of the RHCS capabilities including serving different certificates for different purposes as an extension to IdM if we are able to figure out how to control namespaces within IdM. This will be a lot of work… but it is possible… and might be an approach that we would consider down the road.

  1. Which path (IDM/RHCS) would I need if I wanted to (one org/namespace only):

    1. have a single CA for just one org that issues and stores certs for servers so that if a server is rebuilt (by Sat6.2) the rebuild gets the same cert again

    2. Have puppet certs used by Sat6 and capsules generated/stored by that same CA so all cert management is centralized.

    3. Have all certs used by web portals (web interface of sat6 and capsules, DRAC/ILO, etc.) just within one org generated/stored/managed centrally.

    If I need to use RHCS can that integrate into IDM which I would need for user/group, ssh key, dns, etc. management?

    1. IdM CA should be sufficient for this use case. However there is yet no automation that would make Satellite 6.2 and its elements to use certificates provided by IdM to secure connections between different components. It would be great if you can open a support case that would explain your use case and lead to an RFE. Such RFEs help prioritize integration work.

      For 1) I would just correct you that it would not be the “same” certificate since the certificate has a public key that matches the private key that is generated on the system but it will be a replacement certificate. You might be aware that Satellite can automatically provision and AFAIR remove systems from IdM. That would be the best method to deal with certificate provisioning for those systems. Join them to IdM and request a certificate to be issued for system as a part of the ipa-client-install. In the past a host certificate was always issued by default but at some point we stopped doing it by default since the certificate was just sitting there without any specific use. Also you can use certmonger (a component of Red Hat Enterprise Linux) to fetch and renew certificates for your services listed in 3).

      With all this you might try 7.3 which comes with the new feature called sub-CAs. This feature allows you to partition your certificate namespace without building extra PKI infra. You will create two sub-CAs one for 2) and another for 3) and this will guarantee that certificates issued for puppet can’t be reused to do connections to Web portals. This feature is already a part of 7.3 beta that is out and available.

      Thank you
      Dmitri

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s