During the internal code review, it was discovered that Red Hat Certificate System / Dogtag Certificate System does not properly verify challenge response received during the enrollment of new security token.

If keys are generated on the token during the enrollment, TPS correctly verifies that the requestor possesses the private key, but fails to verify that the key really exists on the token and is not only in software.

An attacker with access to blank token known to TPS component and with privilege to perform enrollments of new tokens could use this flaw to successfully finish enrollment procedure with the software generated key instead of the one stored in the token.

Affected versions: Red Hat Certificate System 7.1, 7.2, 7.3 Dogtag Certificate System 1.0

A flaw was found in a way Red Hat Certificate System handled Extensions in the certificate signing requests (CSR). All requested Extensions were added to issued certificate despite constraints defined in Certificate Authority (CA) profile.

For example, CSR could contain Basic Constraints or Key Usage constraint that once copied to issued certificate would result in creation of subordinate CA certificate, even though CA configuration prohibits issuing of subordinate CA certificate, possibly leading to a bypass the intended security policy.

Affected versions: Red Hat Certificate System 7.1, 7.2, 7.3 Netscape Certificate Management System 6.x

Red Hat / Dogtag Certificate System did not prevent re-use of the one-time PIN used in the SCEP (Simple Certificate Enrollment Protocol) protocol enrollment requests. The check was done to ensure that PIN is valid, but the PIN was never removed from the list of valid PINs once it was used. An attacker possessing a valid SCEP enrollment one-time PIN could use it to generate an unlimited number of certificates.

Red Hat / Dogtag Certificate System's Certificate Authority can be asked to decrypt one-time PIN used in the SCEP (Simple Certificate Enrollment Protocol) protocol requests. This feature is intended to be used by Registration Authorities that act as proxies between CA users (e.g. network devices enrolling using SCEP protocol) and CA itself. However, Red Hat Certificate System lacked proper authentication mechanisms to ensure such decryption requests are only replied if sent form the configured Registration Authority. An attacker able to sniff SCEP request of the network could use this flaw to request decryption of the sniffed request and obtain one-time PIN.

Red Hat Certificate System updates add proper authentication, only configured authenticated Registration Authorities can request SCEP one-time PIN decryption.