8. Known Issues

8.1. Reconfiguring the Red Hat Certificate System Subsystems to Prevent a Potential TLS-Related Man-in-the-Middle Attack

Transport Layer Security (TLS) is a protocol which establishes a secure connection between a client and a server. Marsh Ray of PhoneFactor discovered a flaw in the TLS protocol itself which could allow an attack to insert plain text into an existing session during a TLS renegotiation operation.
The Educated Guesswork blog has a good description of this kind of attack at http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html.
Either a client or a server may request a renegotiation of an existing TLS/SSL session (for instance, to renew session encryption keys or to use different cipher suite). When TLS/SSL is used to secure access to an HTTP service and a client attempts to access some protected resource, server-initiated renegotiation asks client to authenticate with a certificate.
However, the TLS/SSL protocols did not use any mechanism to verify that session peers do not change during the session renegotiation. Therefore, a man-in-the-middle attacker could use this flaw to open TLS/SSL connections to the server, send attacker-chosen request to the server, trigger the renegotiation (either by directly requesting it or by attempting to access protected resource, resulting in server-initiated renegotiation) and splice victim's initial connection attempt to an existing TLS/SSL session. Depending on the application-layer protocol, this may lead to attacker request being performed by the server as if authenticated using victim's credentials or using data from victim's request. After the renegotiation, attacker can no longer decrypt communication between the client and the victim, so this attack is also referred to as a "blind prefix injection" attack. Eric Rescorla's blog post "Understanding the TLS Renegotiation Attack" provides additional details about this flaw.
In Certificate System, this kind of session renegotiation occurs if a user connects to an end-entity port that doesn't require client authentication, but then attempts to submit a certificate enrollment form for an enrollment profile that requires client authentication. The Certificate System server requests and then parses a client certificate for the user.
For both client-initiated and server-initiated renegotiation to be fixed, then both the client and server need to be updated to apply RFC 5746. which resolves the man-in-the-middle vulnerability. For the Certificate System subsystems, the resolution is supplied through Errata RHBA-2010:0169 and Errata RHBA-2010:0165, plus these configuration changes.
Certificate System supports several different clients:
  • Certificate System and third-party RA subsystems (used by both regular users and SCEP services)
  • TPS subsystems, which connect to the CA for token operations
  • The Windows Autoenrollment Proxy
  • Web browsers, which are used by users to connect to the CA's end-entities pages
Updating the system NSS packages on any system that hosts a Certificate System subsystem will take care of all subsystem communication. When the NSS packages are updated, the CA-RA and CA-TPS connections will use the new session renegotiation protocol and all of the operations will proceed as normal.
Additional configuration changes may need to be made for the Windows auto-enrollment proxy or third-party RAs if those systems aren't updated to use the new renegotiation protocol. Contact Red Hat support for information on what needs to be done for those clients.
It is unclear on when browser clients will have updates available and applied to use the new session renegotiation protocol. If these clients aren't updated, but the server is, then the connections to the subsystem server may fail.


These changes are not required if all clients accessing Certificate Systems are upgraded to support RFC 5746.
Certificate System 8.0 uses the Red Hat Enterprise Linux 5 system NSS packages. Updated NSS packages for Red Hat Enterprise Linux 5 are available as part of Errata RHBA-2010:0165. Existing instances need to be reconfigured to add the new port, and direct requests to this port. Any new instances will automatically have these changes applied.

Procedure 1. For Existing CAs

  1. Before making any edits to the CA configuration, back up the following files:
    • /var/lib/instance_name/webapps/ca/WEB-INF/web.xml
    • /var/lib/instance_name/web-apps.ee/ca/ee/ca/ProfileSelect.template
    • /var/lib/instance_name/conf/server.xml
    • /etc/init.d/instance_name
  2. Since database changes are also required, back up the database.
  3. Modify the server.xml file to add the new client authentication end-entities port.
    1. At the top of the file, replace the PKI status definitions with the following section, with the correct hostname and ports. Replace all the lines with the exact excerpt because there are important spacing differences in the definitions.
      <!-- DO NOT REMOVE - Begin PKI Status Definitions -->
      Unsecure Port       = http://server.example.com:9180/ca/ee/ca
      Secure Agent Port   = https://server.example.com:9443/ca/agent/ca
      Secure EE Port      = https://server.example.com:9444/ca/ee/ca
      Secure Admin Port   = https://server.example.com:9445/ca/services
      EE Client Auth Port = https://server.example.com:9446/ca/eeca/ca
      PKI Console Port    = pkiconsole https://server.example.com:9445/ca
      Tomcat Port         = 9802 (for shutdown)
      <!-- DO NOT REMOVE - End PKI Status Definitions -->
    2. Add a section for the new port. Make sure that the clientAuth value is set to true. (The port number and serverCertNickFile and passwordFile directives should all match your instance information.)
      <!-- Port Separation:  EE Secure Client Auth Port Connector -->
      <Connector name="EEClientAuth" port="9446" maxHttpHeaderSize="8192"
              maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
              enableLookups="false" disableUploadTimeout="true"
              acceptCount="100" scheme="https" secure="true"
              clientAuth="true" sslProtocol="SSL"    
  4. Modify the /etc/init.d/instance_name initialization script to read the new status definitions.
    1. At line 242, replace the following lines. Replace all the lines with the exact excerpt below because there are important differences in whitespace in the quoted strings.
      unsecure_port_statement="Unsecure Port       = "     
      secure_agent_port_statement="Secure Agent Port   = "
      secure_ee_port_statement="Secure EE Port      = "     
      secure_ee_client_auth_port_statement="EE Client Auth Port = "
      secure_admin_port_statement="Secure Admin Port   = "
      pki_console_port_statement="PKI Console Port    = "
      tomcat_port_statement="Tomcat Port         = "
    2. Modify the highlighted code at around line 280.
                                    head=`echo "$line" | cut -b1-22` 
                                    if      [ "$head" == "$unsecure_port_statement"     ] ||    
                                            [ "$head" == "$secure_agent_port_statement" ] ||
                                            [ "$head" == "$secure_ee_port_statement"    ] ||    
                                            [ "$head" == "$secure_ee_client_auth_port_statement" ] ||    
                                            [ "$head" == "$secure_admin_port_statement" ] ||
                                            [ "$head" == "$pki_console_port_statement"  ] ||
                                            [ "$head" == "$tomcat_port_statement"       ] ; then
                                            echo "    $line"  
                                            total_ports=`expr ${total_ports} + 1`
                    if [ ${total_ports} -eq 7 ] ; then
                            return 0
  5. Open the web.xml file.
    vim /var/lib/instance_name/webapps/ca/WEB-INF/web.xml
  6. Add the following servlet mappings for submitting profiles to the secure end-entities client authentication URL:
          <servlet-name>  caProfileSubmitSSLClient  </servlet-name>
          <url-pattern>   /eeca/ca/profileSubmitSSLClient  </url-pattern>
          <servlet-name>  caGetCertFromRequest  </servlet-name>
          <url-pattern>   /eeca/ca/getCertFromRequest  </url-pattern>
  7. Edit the profile selection template to use the URL for the new secure end-entities client authentication services port. For example, assuming the default end-entities client authentication SSL port of 9446:
    vim /var/lib/instance_name/webapps/ca/ee/ca/ProfileSelect.template
    ... original ...
        uri = 'profileSubmitSSLClient';
    ... update ...
        uri = 'https://server.example.com:9446/ca/eeca/ca/profileSubmitSSLClient';
  8. The new port information needs to be added to security domain description of the subsystem, as stored in the database.
    1. Connect to the database and update the schema.
      /usr/lib/mozldap/ldapmodify -p db_port -h db_host -D "cn=Directory Manager" -w db_password
      dn: cn=schema
      changetype: modify
      add: attributeTypes
      attributeTypes: ( SecureEEClientAuthPort-oid NAME 'SecureEEClientAuthPort'  SYNTAX SINGLE-VALUE X-ORIGIN 'user defined' )
      changetype: modify
      delete: objectClasses
      objectClasses: ( pkiSubsystem-oid NAME 'pkiSubsystem' DESC 'CMS defined class' SUP top STRUCTURAL MUST ( cn $ Host $ SecurePort $ SubsystemName $ Clone ) MAY ( DomainManager $ SecureAgentPort $ SecureAdminPort  $ UnSecurePort ) X-ORIGIN 'user defined' )
      add: objectClasses
      objectClasses: ( pkiSubsystem-oid NAME 'pkiSubsystem' DESC 'CMS defined class' SUP top STRUCTURAL MUST ( cn $ Host $ SecurePort $ SubsystemName $ Clone ) MAY ( DomainManager $ SecureAgentPort $ SecureAdminPort $SecureEEClientAuthPort $ UnSecurePort ) X-ORIGIN 'user defined' )
    2. Add the new port information to the security domain entry for this subsystem.
      /usr/lib/mozldap/ldapmodify -p db_port -h db_host -D "cn=Directory Manager" -w db_password 
      dn: cn=hostname:admin_port,cn=CAList,ou=Security Domain,dc=basedn
      changetype: modify
      add: SecureEEClientAuthPort
      SecureEEClientAuthPort: new_port_number

8.2. List of Known Issues in Red Hat Certificate System 8.0

These are known issues in the 8.0 release of Red Hat Certificate System. When available, workarounds are included.

Table 7. Known Issues

Bug Number Description Workaround
223299 If a TKS master key is generated on a SafeNet LunaSA HSM, server-side key generation fails with the following error in the TKS debug log:
"can't generate key encryption key"
A similar message also appears in the debug log if server-side key generation is turned on:
"TokenServlet: key encryption key generation failed for CUID"
CUID is the card unique ID.
Do not use LunaSA HSMs to generate keys for the TKS subsystem.
223343 When an nCipher HSM is used for a Certificate System instance, the nfast group needs to include the user ID of the Certificate System instance process. For example, since default Certificate System instances run as pkiuser, then the pkiuser group needs to be added as a member to the nfast group, if the Certificate System group has not already been added as a member. Add the Certificate System user, such as pkiuser, as a member of the nfast group.
223391 If there are multiple enrollment operations using the tpsclient tool when server-side key generation is enabled in the TPS, then the DRM connection can time out before the TPS can generate the keys. The tool will then return the error Failed to generate key on server. Please check DRM. Edit the TPS CS.cfg configuration file and increase the timeout period for the connection to the DRM by adding the following line:
224837 The configuration wizard is still available even after the subsystem instance configuration is complete.
224994 CEP currently logs any authentication failures during enrollment to the system log. These should log to the audit log.
233024 The auto enrollment proxy configuration is not added to everyone's profile. This is typically occurs when configuring the auto enrollment proxy on Windows child domains where the local administrator does not have permission to modify the cn=configuration tree in Active Directory. The simplest workaround is to use the Run as .. option to authenticate as the primary domain controller administrator and to then try to modify the cn=configuration. This relates to the Populate AD option in AEP.
234884 The Phone Home UI pops up for both enrolled and uninitialized tokens on RHEL4 and MAC OS X, even though the tokens contain Phone Home URLs. Type in the Phone Home URL and proceed.
235150 The TKS sub-system start and stop scripts currently do not check that the package is installed before attempting to execute.
236857 In the RA agent page, the RA attempts to retrieve revocation information for a certificate that the agent does not have the rights to see. This is not an issue at present and can be ignored.  
237050 There can be numerous File does not exist errors in the RA error logs. The administrator can safely ignore these error messages.
237056 On the agent interface of the RA, the List Requests page displays the total number of certificate requests. On the List Certificates page, the corresponding information is missing. This will be fixed in the next release.
237250 There is currently no facility for canceling certificate revocation. This will be added in the next release.
237251 There is currently no option to add comments to a revocation request submitted through the RA. This is useful for agents if they are temporarily putting certificates on hold. This facility is currently only provided in the CA. It will be added to the RA in the next release.
237305 The CA subsystem in Certificate System does not process SCEP requests that have been previously submitted. This can result in an error message similar to the following:
1706.http-9080-Processor24 - [20/Apr/2007:05:47:23 PDT] [20] [3] CEP Enrollment: Enrollment failed: user used duplicate transaction ID.
To avoid this situation, ensure that the Cisco router generates fresh sets of keys for SCEP enrollments.
237353 If the user clicks a link in the agent interface too fast and too many times, the server may return Broken pipe: core_output_filter: writing data to the network and terminate the SSL connection. Re-authenticate to the agent interface.
238039 The Subject Alt Name extension in certificates that are issued using the caDirUserCert profile contain unsubstituted variables, such as $request.requestor_email$), if the profile request does not contain values available for substitution.  
238203 The TPS instance name is hard-coded in the CS.cfg. Because the instance name is hard-coded, the TPS looks for the configuration file in /var/lib/rhpki-tps/conf/CS.cfg. If you create an instance with a name other than rhpki-tps, modify the /var/lib/tps-instance-name/cgi-bin/sow/cfg.pl file to remove the hard-coded instance name.
456701 The default signing algorithm used by the CA cannot be successfully changed in the CA configuration or when setting up the CA. The default is hard-coded to MD5withRSA.
When trying to renew a subsystem certificate using the certificate wizard tool in the Java console (pkiconsole), the certificate renewal fails and the console throws a Java exception, such as UNKNOWNEXCEPTION-java.util. MissingRessourceException: Can't find resource for bundle com.netscape.admin. certsrv.CMSAdminResources, key UNKNOWNEXCEPTION.
The console relied on the old policy framework to renew certificates, but the policy framework was replaced by a new profile framework in Certificate System 7.2. Therefore, the renewal feature in the console is broken.
This is related to bug 499014.
Use the certificate wizard in the console to generate new certificates for the subsystem. Alternatively, use the CA's web services forms to renew the certificate or create a new renewal profile for the subsystem certificates.
454559 Attempting to connect to the Online Certificate Status Manager using wget or HTTP POST to send OCSP requests times out. Use the OCSPClient tool to send status requests.
Due to a security concern, the Red Hat Directory Server Perl files on Sun Solaris platforms were moved from /opt/perl5x to /usr/lib/sparcv9/dirsec/perl5x. However, some Perl utilities includes with Certificate System are hard-coded to reference /opt/perl5x. This move can cause problems if users running Red Hat Certificate System upgrade their local Directory Server to Red Hat Directory Server 8.0 on the same machine.
Create symlinks to the new Perl directory.
ln -s /usr/lib/sparcv9/dirsrv/perl5x /opt/perl5x
491438 If the TPS server is unavailable, then the Enterprise Security Client opens a blank screen in security officer mode rather than returning an error message that the server is unreachable. If a blank screen appears when opening the Enterprise Security Client in security officer mode, try restarting the TPS server, and then restarting the Enterprise Security Client.
The tokendb.allowedTransitions parameter in the TPS configuration sets the revocation states that a token can be assigned. For example, a token can go from a valid state to a permanently lost state.
The tokendb.allowedTransitions parameter can be set to allow a transition from a state where the certificates are permanently revoked back to the active state. However, the TPS will not allow a token to go from a permanently revoked state back to active. Even though those operations appear to complete successfully, the certificates on that token are still revoked.
When trying to renew a DRM certificate using the certificate wizard tool in the Java console (pkiconsole), the certificate renewal fails and the DRM crashes.
The console relied on the old policy framework to renew certificates, but the policy framework was replaced by a new profile framework in Certificate System 7.2. Therefore, the renewal feature in the console is broken.
This is related to bug 453501.
Generate and install new subsystem certificates using the certificate wizard in the console, rather than attempting to renew existing certificates.
499052 If the configured OCSP responder in the RA or TPS nss.conf file is not the default responder, then NSS attempts to verify the OCSP signing certificate used by the OCSP, but it instead creates an infinite loop attempting to verify the certificate status against itself. Make sure that any OCSP responder in the RA or TPS nss.conf file is the default, such as the CA's internal OCSP service.
The e-gate drivers (eginstall.exe) would not install properly on Windows servers, which caused installing the Enterprise Security Client to fail on Windows.
The e-gate drivers have been removed from the Windows Enterprise Security Client packages on Windows to allow the client to be installed.
e-gate tokens must be formatted on Red Hat Enterprise Linux or Mac systems, since the e-gate drivers are not available for the Enterprise Security Client on Windows.
Token operations can cause a large number of unindexed searches to be returned in the instance's internal Directory Server logs. An unindexed search shows up in Directory Server access logs as notes=U.
Unindexed searches are resource-intensive and can affect performance for the Directory Server. However, most of the unindexed searches returned for Certificate System token operations are improperly labeled index searches when they are really indexed VLV searches (related to Red Hat Directory Server bug 507460). The remainder of the unindexed searches still had very low etimes for the searches and should not significantly affect Certificate System performance.
Attempting to load the Certicom ECC module fails if SELinux is in enforcing mode, the default setting for Certificate System 8.0.
modutil, the tool which is used to load ECC modules, requests text relocation permissions for Certicom's /usr/lib/libsbgse2.so library. This is not allowed by SELinux's enforcing mode.
SELinux can be configured to allow /usr/lib/libsbgse2.so to have text relocation permissions, which allows the ECC module to be successfully loaded.
  1. Change the file context to textrel_shlib_t.
    chcon -t textrel_shlib_t '/usr/lib/libsbgse2.so'
  2. Then change the default file context files on the system so that the updated context is preserved even if the system is fully relabel.
    semanage fcontext -a -t textrel_shlib_t '/usr/lib/libsbgse2.so'
  3. Reload the ECC module; this should be successful.
    modutil -dbdir /var/lib/pki-ca/alias/ -nocertdb -add certicom -libfile /usr/certicom/lib/libsbcpgse.so
504013 Because of potential security risks, SCEP enrollment is disabled through the RA for Certificate System 8.0, and the corresponding enrollment forms have been removed.
The CRMFPopClient tool is used to submit a CRMF request to a CA, with proof of possession that the CA can verify. The CA then generates and, optionally, returns a certificate request or generates a request and archives the key (for DRM transport certificates).
Running the CRMFPopClient tool to generate a transport certificate request for a DRM returns the error java.io.FileNotFoundException when submitting the CRMF request to a CA.
Use the CA's web interface to submit the CRMF transport certificate request.
509804 Installing or migrating instances on a Safenet Chrysalis-IT LunaSA HSM could fail. SSL connections from the subsystem begin failing after a short period of time and the connection could not be re-established. Make sure that the following line must be added to the /etc/Chrystoki.conf configuration file:
Misc { NetscapeCustomize=1023; }
Additionally, these two lines must be removed:
511327 Trying to set up a TPS using a Safenet Chrysalis-IT LunaSA HSM fails with an error indicating that the password to access the HSM was incorrect or that the CA was unavailable. Safenet Chrysalis-IT LunaSA HSM tokens cannot be used to set up the TPS.
512029 If the same HSM partition is used to multiple Certificate System subsystem instances, than the instance names cannot be used more than once, even if the instances are on different hosts. If a user tries to configure a new instance with the same name (including the default options) as an existing instance, then configuration will stall at key generation with an error that the certificate subject name already exists. When using an HSM, always use unique instance names.
512493 Client authentication to the Java console fails in Red Hat Certificate System 8.0 because the console is unable to verify the client certificate required for authentication. This means that the console cannot be configured to run over SSL.


If CA is configured for client authentication over the admin port and that CA is a security domain manager, then no new PKI subsystems can be configured that use that CA for its security domain. New PKI instances register themselves to the security domain CA over the admin port but without using client authentication. If the CA requires client authentication, then the registration attempt fails.
  1. Stop the server.
    service pki-ca stop
  2. Open the CS.cfg file and change the authType value to the client authentication setting.
    vim /var/lib/pki-ca/conf/CS.cfg
  3. Open the server.xml file and change the clientAuth value to true for the admin port, in the admin connector entry.
    vim /var/lib/pki-ca/conf/server.xml
    <Connector port="9445" maxHttpHeaderSize="8192"
              maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
              enableLookups="false" disableUploadTimeout="true"
              acceptCount="100" scheme="https" secure="true"
              clientAuth="true" sslProtocol="SSL"
  4. Start the server.
    service pki-ca start
  5. Configure the console.
    1. Open the user's console directory.
    2. Create new security databases.
      certutil -N -d .
    3. Export the administrator user certificate from your browser and save it to a .p12 file, such as /tmp/admin.p12.
    4. Copy the administrator user certificate .p12 file to the console directory, and use pk12util to import it into the security databases.
      cp -p /tmp/admin.p12 /user-directory/.redhat-idm-console
      # pk12util -i ./admin.p12 -d /user-directory/.redhat-idm-console
    5. Export the 64-bit blob of the issuing CA certificate from the browser and save it to a file like ca.crt.
    6. Import the CA certificate from the base 64-blob associated with the admin user cert.
      certutil -A -d . -n ca -t CT,C,C -i ./ca.crt
  6. The next time you run pkiconsole, it prompts for you to supply the security database password and admin certificate to allow client authentication.
    pkiconsole https://server.example.com:9445/ca
513450 The CA is missing the configuration to support the Authority Information Access extension for CRLs. This entry can be added manually to the CA CS.cfg file.
  1. Stop the CA instance.
    service pki-ca stop
  2. Add the extension to the file. For example:
    vim /var/lib/pki-ca/conf/CS.cfg
  3. Start the CA instance again.
    service pki-ca start
The Authority Information Access extension is described in the CRLs extension reference chapter in the Certificate System Administrator's Guide.
523568 On Windows XP and Vista systems, logging into the Enterprise Security Client using LDAP authentication can fail if the password is stored using the SSHA hash and has the exclamation point (!) or dollar sign ($) characters. The exclamation point (!) and dollar sign ($) characters must be properly escaped for a user to bind successfully to the Enterprise Security Client.
  • For the dollar sign ($) character, escape the dollar sign when the password is created:
    Then, enter only the dollar sign ($) character when logging into the Enterprise Security Client.
  • For the exclamation point (!) character, escape the character when the password is created and when the password is entered to log into the Enterprise Security Client.