#2947 [RFE] Integrate with p11-kit to provide CA certificates and enforce trust policy from IPA and AD
Closed: wontfix 4 years ago by pbrezina. Opened 8 years ago by jcholast.

Integrate with p11-kit to provide CA certificates and enforce trust policy from IPA and AD. In IPA, CA certificates and the associtated trust policy are stored in LDAP, see the [CA certificate renewal design page]]. In AD, they are stored in the GPO, see e.g. [https://technet.microsoft.com/en-us/library/cc772491.aspx].

SSSD should be able to detect changes in the policy on the server and provide it to p11-kit. For the local policy, this is done by putting files into /etc/pki/ca-trust and running update-ca-trust.

There are 2 ways how to provide the policy to p11-kit:

  • Generate a .p11-kit file containing the certificates and trust policy on each update and put it into /etc/pki/ca-trust. This is easier to implement, but relies on an undocumented internal file format, and the SSSD-provided domain policy will be mixed with the local policy in the "System Trust" token.
  • Create a PKCS#11 module pluggable into p11-kit which provides the certificates and trust policy. This is harder to implement, but uses a standard API consumable by other applications as well, and the SSSD-provided domain policy will be able to use its own "Domain Trust" token.

This is required for [https://fedorahosted.org/freeipa/ticket/4322].


Fields changed

description: Integrate with p11-kit to provide CA certificates and enforce trust policy from IPA and AD. In IPA, CA certificates and the associtated trust policy are stored in LDAP, see the [[http://www.freeipa.org/page/V4/CA_certificate_renewal#Design|IPA CA certificate renewal design page]]. In AD, they are stored in the GPO, see e.g. [[https://technet.microsoft.com/en-us/library/cc772491.aspx]].

SSSD should be able to detect changes in the policy on the server and provide it to p11-kit. For the local policy, this is done by putting files into /etc/pki/ca-trust and running update-ca-trust.

There are 2 ways how to provide the policy to p11-kit:
Generate a .p11-kit file containing the certificates and trust policy on each update and put it into /etc/pki/ca-trust. This is easier to implement, but relies on an undocumented internal file format, and the SSSD-provided domain policy will be mixed with the local policy in the "System Trust" token.
Create a PKCS#11 module pluggable into p11-kit which provides the certificates and trust policy. This is harder to implement, but uses a standard API consumable by other applications as well, and the SSSD-provided domain policy will be able to use its own "Domain Trust" token. => Integrate with p11-kit to provide CA certificates and enforce trust policy from IPA and AD. In IPA, CA certificates and the associtated trust policy are stored in LDAP, see the [[http://www.freeipa.org/page/V4/CA_certificate_renewal#Design|IPA CA certificate renewal design page]]. In AD, they are stored in the GPO, see e.g. [[https://technet.microsoft.com/en-us/library/cc772491.aspx]].

SSSD should be able to detect changes in the policy on the server and provide it to p11-kit. For the local policy, this is done by putting files into /etc/pki/ca-trust and running update-ca-trust.

There are 2 ways how to provide the policy to p11-kit:
Generate a .p11-kit file containing the certificates and trust policy on each update and put it into /etc/pki/ca-trust. This is easier to implement, but relies on an undocumented internal file format, and the SSSD-provided domain policy will be mixed with the local policy in the "System Trust" token.
Create a PKCS#11 module pluggable into p11-kit which provides the certificates and trust policy. This is harder to implement, but uses a standard API consumable by other applications as well, and the SSSD-provided domain policy will be able to use its own "Domain Trust" token.

This is required for [[https://fedorahosted.org/freeipa/ticket/4322]].

Fields changed

rhbz: => todo

Deferring until there is p11kit API available.

milestone: NEEDS_TRIAGE => SSSD Deferred

Metadata Update from @jcholast:
- Issue set to the milestone: SSSD Patches welcome

7 years ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

4 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3988

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata