dogtagpki

#1134 Inconsistent cert revocation checking.
Closed: Duplicate Opened by edewata.

Closed: Duplicate
Reopen Issue

The auths.revocationChecking.enabled parameter is configured inconsistently in CS.cfg in different subsystems. This will lead to inconsistent behavior when a user authenticates using a revoked certificate. See also ticket #1117.

In CA it's set to true. In KRA it's set to false. In other subsystems it's not set, so it's using the default value which is false (see CertUserDBAuthentication.java).

mRevocationCheckingEnabled = mRevocationChecking.getBoolean("enabled", false);

There are several areas that need to be considered:

  • CS.cfg templates in /usr/share/pki
  • Actual CS.cfg in instance folders
  • Default value in CertUserDBAuthentication.java

The preferred solution is to remove the parameter from the templates so it will use the default value. Customization can be done by adding the parameter explicitly to the CS.cfg.

Questions:
1. Is ignoring cert revocation during authentication considered a security issue?
2. If this is a security issue, can we change the behavior of existing instances automatically during upgrade to fix it?

Per discussion with nkinder and alee:

  • the current default value in the code should remain false
  • existing instances should not be modified
  • the templates for new instances should be modified to true

In the future an upgrade script can be written to add the missing setting in the existing instances so the default can be changed to true and the templates will no longer need to have the setting.

master: 223d15539b7bcc0df025025036af2935726e52e3

Per discussion with cfu and alee, the patch has been reverted from master since the fix will not work on subsystems installed on separate instance: 8acd59fe3d32e249c5e37138ec1c360fd8ad1de2

The proposed solution is:

  • enable the CA's built-in OCSP by default
  • enable certificate revocation checking in non-CA subsystems by default by pointing it to the CA's built-in OCSP

What should be done with existing instances?

  • option 1: don't change anything
  • option 2: use an upgrade script to enable OCSP in CA and enable revocation checking in other subsystems

Related docs:

  • https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/revocation-checking.html#enabling-ocsp-checking-for-the-tks-and-drm
  • https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Deploy_and_Install_Guide/examplecc.html#Non-TMS-CC_Setup

Proposed Milestone: 10.2.2 (per CS Meeting of 09/17/2014)

This depends on a proper OCSP setup document (ticket #1182).

Per Dogtag 10.2.X meeting of 01/14/2015:

Endi to verify whether or not this ticket has already been addressed.

The ticket has not been addressed. It depends on ticket #1182 which currently has not been addressed yet.

This ticket depends on ticket #1202 which will be fixed in 10.3.

Per triage meeting of 2/25/2015: 10.2.3

This ticket is merged into #1202.

Metadata Update from @edewata:
- Issue assigned to edewata
- Issue set to the milestone: 10.2.3

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/1697

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, and we apologize for any inconvenience.
Metadata
None
None
None
Normal
None
None
None
None
None
defect
General
None
Community
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.