Configuration changes to prevent server-initiated TLS session renegotiations in Red Hat Certificate System

Updated -

Issue

A vulnerability was discovered in the Secure Sockets Layer (SSL) version 3 and Transport Layer Security (TLS) version 1 protocols related to session renegotiation. An attacker could initiate a man-in-the-middle attack that inserts plain text as a prefix to a victim's communication using a session renegotiation operation. This vulnerability has been assigned CVE identifier CVE-2009-3555. For additional details about this flaw, refer to Is Red Hat affected by TLS renegotiation MITM attacks (CVE-2009-3555)?.

How this affects Certificate System

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 Red Hat 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 enrolment form for an enrolment 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 a fix for the man-in-the-middle vulnerability.Certificate System supports several different clients:

  • RA subsystems (both for users and SCEP enrollments), which connect to the CA; this includes both the Certificate System RA and third-party RAs
  • TPS subsystems, which connect to the CA for token operations
  • The Windows auto-enrollment 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-enrolment 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. This Knowledgebase article contains configuration changes that will allow clients to successfully connect to updated servers.

Environment

Red Hat Certificate System uses TLS/SSL secure access to agent, administrative, and end-entities pages. Described updates and configuration changes are applicable to the following product versions:

  • Red Hat Certificate System 8.0
  • Red Hat Certificate System 7.3
  • Red Hat Certificate System 7.1

Resolution

Red Hat is addressing this issue by providing updated NSS packages which add support for RFC 5746, "Transport Layer Security (TLS) Renegotiation Indication Extension."

Red Hat Certificate System 8.0 uses the Red Hat Enterprise Linux 5 system nss packages. Red Hat Certificate System 7.3 shipped with its own dirsec-nss packages, which are replaced by Red Hat Enterprise Linux 4 system nss packages with this update. Along with updating the NSS packages, the RA and TPS packages must also be updated for Red Hat Certificate System 7.3.

The following errata contain these updated packages:

  • Errata RHSA-2010:0165 for Red Hat Certificate System 8.0 NSS packages
  • Errata RHBA-2010:0169 for Red Hat Certificate System 8.0 pki-ca, pki-selinux, redhat-pki-ca-ui, pki-setup, and pki-common packages
  • Errata RHSA-2010:0165 for Red Hat Certificate System 7.3 NSS packages
  • Errata RHBA-2010:0170 for Red Hat Certificate System 7.3 pki-tps and pki-ra packages

Red Hat Certificate System 7.1 uses NSS library files that are packaged within the Red Hat Certificate System 7.1 package. For Red Hat Certificate System 7.1, the updated NSS libraries, Certificate System packages, and dependencies will be provided as a hot fix from SEG.

When NSS packages are updated, any operations performed by Red Hat Certificate System subsystems which depend on TLS renegotiation will fail for all clients that are not updated to support RFC 5746. The additional configuration changes in this article configure the subsystems to avoid TLS session renegotiation by directing all requests requiring client certificate authentication to a separate port. In Certificate System 7.1 and 8.0, that port is the agent secure port. In Certificate System 7.3, no port is configured to require certificate authentication during the initial handshake. Therefore, instructions for Certificate System 7.3 also describe how to configure new agent secure port that always requires certificate authentication.

These changes are not required if all clients accessing Certificate Systems are upgraded to support RFC 5746.

The instructions here assume that Certificate System has been configured to use separate agent, end-entities, and admin ports. This is the default configuration in Certificate System 7.1 and 8.0 (thought the instances could still be configured manually to use a single SSL port). However, port separation is only available on Certificate System 7.3 if the server is updated to the latest version and when the subsystems are manually configured to use port separation.

Configuration changes to avoid TLS/SSL session renegotiation

Reconfiguring Red Hat Certificate System 8.0

Red Hat 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 RHSA-2010:0165.

An additional errata has to be applied to Certificate System 8.0 to include support for clients which aren't updated to support RFC 5746. Errata RHBA-2010:0169 requires the creation of a new port that requires client authentication. Whenever a user submits a request to an enrolment profile that requires client authentication, the request is directed to this port; this avoids renegotiation. All requests for regular profiles can continue to be processed over the standard end-entities port.

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.

On 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.

    • 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 below 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 -->
    • 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"
      sslOptions="ssl2=true,ssl3=true,tls=true"
      ssl2Ciphers="-SSL2_RC4_128_WITH_MD5,-SSL2_RC4_128_EXPORT40_WITH_MD5,-SSL2_RC2_128_CBC_WITH_MD5,-SSL2_RC2_128_CBC_EXPORT40_WITH_MD5,-SSL2_DES_64_CBC_WITH_MD5,-SSL2_DES_192_EDE3_CBC_WITH_MD5"
      ssl3Ciphers="-SSL3_FORTEZZA_DMS_WITH_NULL_SHA,-SSL3_FORTEZZA_DMS_WITH_RC4_128_SHA,+SSL3_RSA_WITH_RC4_128_SHA,-SSL3_RSA_EXPORT_WITH_RC4_40_MD5,+SSL3_RSA_WITH_3DES_EDE_CBC_SHA,+SSL3_RSA_WITH_DES_CBC_SHA,-SSL3_RSA_EXPORT_WITH_RC2_CBC_40_MD5,-SSL3_FORTEZZA_DMS_WITH_FORTEZZA_CBC_SHA,-SSL_RSA_FIPS_WITH_DES_CBC_SHA,+SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA,-SSL3_RSA_WITH_NULL_MD5,-TLS_RSA_EXPORT1024_WITH_RC4_56_SHA,-TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA"
      tls3Ciphers="-SSL3_FORTEZZA_DMS_WITH_NULL_SHA,-SSL3_FORTEZZA_DMS_WITH_RC4_128_SHA,+SSL3_RSA_WITH_RC4_128_SHA,-SSL3_RSA_EXPORT_WITH_RC4_40_MD5,+SSL3_RSA_WITH_3DES_EDE_CBC_SHA,+SSL3_RSA_WITH_DES_CBC_SHA,\-SSL3_RSA_EXPORT_WITH_RC2_CBC_40_MD5,-SSL3_FORTEZZA_DMS_WITH_FORTEZZA_CBC_SHA,-SSL_RSA_FIPS_WITH_DES_CBC_SHA,+SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA,-SSL3_RSA_WITH_NULL_MD5,-TLS_RSA_EXPORT1024_WITH_RC4_56_SHA,\-TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA"
      SSLImplementation="org.apache.tomcat.util.net.jss.JSSImplementation"
      serverCertNickFile="/var/lib/pki-ca/conf/serverCertNick.conf"
      passwordFile="/var/lib/pki-ca/conf/password.conf"

      passwordClass="org.apache.tomcat.util.net.jss.PlainPasswordFile"
      certdbDir="/var/lib/pki-ca/alias"/>
  4. Modify the /etc/init.d/ instance_name initialization script to read the new status definitions.

    • At line 242, replace the following lines. Replace all the lines with the exact excerpt 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 = "
    • 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`
      fi
      fi
      done

      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-mapping>
    <servlet-name> caProfileSubmitSSLClient </servlet-name>
    <url-pattern> /eeca/ca/profileSubmitSSLClient </url-pattern>
    </servlet-mapping>
    <servlet-mapping>      
    <servlet-name> caGetCertFromRequest </servlet-name>
    <url-pattern> /eeca/ca/getCertFromRequest </url-pattern>
    </servlet-mapping>
  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.

    • 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 1.3.6.1.4.1.1466.115.121.1.27 \
      SINGLE-VALUE X-ORIGIN 'user defined' )
      -
      dn:cn=schema
      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' )
      ^C
    • 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

      ^C
  9. Restart the CA.

    service pki-ca restart
    
Reconfiguring Red Hat Certificate System 7.3

In its initial release, Certificate System 7.3 used its own NSS packages, supplied with dirsec-nss. Errata RHSA-2010:0165 replaces the dirsec-nss package with the Red Hat Enterprise Linux 4 system nss packages, and the system nss packages are updated with the TLS renegotiation fix.  A second errata, RHBA-2010:0170, allows the TPS and RA subsystems to operate correctly with the updated NSS. Both RHSA-2010:0165 and RHBA-2010:0170 must be installed for Certificate System 7.3 deployments.

RA and TPS instances created after the erratas are installed will be correctly configured already. For existing TPS and RA instances, the initialization scripts used to start the instances need to be modified.

In addition, the Certificate Authority subsystem may be reconfigured to avoid TLS/SSL session renegotiation for the following client interfaces:

  • CA end-entities pages
  • DRM connectors
  • TPS connectors

These clients will use the secure agent port for client authentication.

The 7.3 subsystems have to be reconfigured for a couple of reasons:

  1. By default, no designated port for any subsystem requires client authentication. This means that if a browser which has not been updated attempts to connect to an enrollment profile that requires client authentication, the connection will fail because its renegotiation request fails.
  2. Browsers that are not updated with the TLS/SSL fix will fail to connect to the agent interface (which always requires client authentication) unless the agent secure port is designated as a client authentication port.
  3. All clients that try to access enrollment profiles that require client authentication must be redirected to the secure agent port to avoid renegotiation requests.

For these reasons, there has to be a separate client authentication port to which to direct traffic to avoid renegotiation, and these configuration changes are required.

Note: These instructions are only applicable to the 7.3 subsystems that were configured to use port separation. Since port separation was not required by default in Certificate System 7.3, deployments not using port separation first need to be re-configured to use it before applying these changes.

On the CA
  1. Update the NSS packages. On Red Hat Enterprise Linux, install the system nss packages. For example:

    up2date nss
    

    On Sun Solaris, stop the servers, and remove the old NSS and NSPR packages.

    /etc/init.d/instance_ID stop
    pkgrm RHATdirsec-nssx RHATdirsec-nsprx

    Then, install the RHATdirsec-nssx and RHATdirsec-nsprx packages and restart the servers. For example:

    pkgadd -d /path/to/RHATdirsec-nsprx-4.8.4.sparcv9.pkg
    pkgadd -d /path/to/RHATdirsec-nssx-3.12.6.sparcv9.pkg
    /etc/init.d/instance_ID start
  2. Before making any edits to the CA configuration, back up the following files:

    • /var/lib/ * *instance_name****/conf/server.xml**
    • /var/lib/ * *instance_name****/web-apps.ee/ca/ee/ca/ProfileSelect.template**
  3. Open the server.xml file.

    vim /var/lib/instance_name/conf/server.xml
    
  4. In the server.xml file, change the clientAuth directive in the agent connector to true.

<Connector port="9013" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="true" sslProtocol="SSL"
  1. Open the profile selection template.

    vim /var/lib/instance_name/web-apps.ee/ca/ee/ca/ProfileSelect.template
    
  2. Replace value in the uri line with the URL to the agent port. The original line is:

    uri = 'profileSubmitSSLClient';

    The updated line will look like the following:

    uri = 'https://server.example.com:9443/ca/ee/ca/profileSubmitSSLClient';
    
  3. Create a new end-entities web services directory to contain the files for the new URL referenced in the ProfileSelect.template file.

    mkdir -p /var/lib/instance_name/webapps/ca/ee/ca

    cp /var/lib/instance_name/webapps.ee/ca/ee/ca/ProfileSubmit.template /var/lib/instance_name/webapps/ca/ee/ca

    cp /var/lib/instance_name/webapps.ee/ca/ee/ca/ProfileSubmit.html /var/lib/instance_name/webapps/ca/ee/ca/ProfileSubmit.html

    chown -R pkiuser: /var/lib/instance_name/webapps/ca/ee
  4. Restart the CA. For example:

    /etc/init.d/rhpki-ca restart
On the DRM
  1. Update the NSS packages. On Red Hat Enterprise Linux, install the system NSS packages. For example:
up2date nss

On Sun Solaris, stop the servers, and remove the old NSS and NSPR packages.

<pre>/etc/init.d/<em><code>instance_ID</code></em> stop<br />pkgrm RHATdirsec-nssx RHATdirsec-nsprx

Then, install the `RHATdirsec-nssx` and `RHATdirsec-nsprx` packages and restart the servers. For example:

<pre>pkgadd -d /path/to/RHATdirsec-nsprx-4.8.4.sparcv9.pkg<br />pkgadd -d /path/to/RHATdirsec-nssx-3.12.6.sparcv9.pkg<br />/etc/init.d/<em><code>instance_ID</code></em> start

  1. On the CA, edit the CS.cfg file to contain the connector information with the agent's SSL port. For example:
vim /var/lib/rhpki-ca/conf/CS.cfg 

ca.connector.KRA.port=10443
  1. Then, for the DRM, open the server.xml file.

    vim /var/lib/rhpki-kra/conf/server.xml
    
  2. Change the clientAuth directive in the agent connector to true. For example:

    <Connector port="10443" maxHttpHeaderSize="8192"
    maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
    enableLookups="false" disableUploadTimeout="true"
    acceptCount="100" scheme="https" secure="true"
    clientAuth="true" sslProtocol="SSL"
  3. Restart the subsystem. For example:

    /etc/init.d/rhpki-kra restart
    
On the OCSP and TKS
  1. Update the NSS packages. On Red Hat Enterprise Linux, install the system NSS packages. For example:
up2date nss

On Sun Solaris, stop the servers, and remove the old NSS and NSPR packages.

<pre>/etc/init.d/<em><code>instance_ID</code></em> stop<br />pkgrm RHATdirsec-nssx RHATdirsec-nsprx

Then, install the `RHATdirsec-nssx` and `RHATdirsec-nsprx` packages and restart the servers. For example:

<pre>pkgadd -d /path/to/RHATdirsec-nsprx-4.8.4.sparcv9.pkg<br />pkgadd -d /path/to/RHATdirsec-nssx-3.12.6.sparcv9.pkg<br />/etc/init.d/<em><code>instance_ID</code></em> start

  1. Open the server.xml file.

    vim /var/lib/instance_name/conf/server.xml
    
  2. Change the clientAuth directive in the agent connector to true. For example:

    <Connector port="13443" maxHttpHeaderSize="8192"
    maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
    enableLookups="false" disableUploadTimeout="true"
    acceptCount="100" scheme="https" secure="true"
    clientAuth="true" sslProtocol="SSL"
  3. Restart the subsystem. For example:

    /etc/init.d/rhpki-ocsp restart
    
On the TPS
  1. Update the pki-tps packages and NSS packages. On Red Hat Enterprise Linux, install the NSS packages. For example:

    up2date nss pki-tps
    

    On Sun Solaris, stop the servers, and remove the old NSS, NSPR, and TPS packages.

    /etc/init.d/instance_ID stop
    pkgrm RHATdirsec-nssx RHATdirsec-nsprx RHATrhpki-tpsx

    Then, install the RHATdirsec-nssx and RHATdirsec-nsprx packages and restart the servers. For example:

    pkgadd -d /path/to/RHATdirsec-nsprx-4.8.4.sparcv9.pkg
    pkgadd -d /path/to/RHATdirsec-nssx-3.12.6.sparcv9.pkg
    pkgadd -d /path/to/RHATrhpki-tpsx-7.3.0-24.sol9.sparcv9.pkg
    /etc/init.d/instance_ID start
  2. On Linux systems only. For an existing subsystem, edit the init script to preload the system NSS library rather than dirsec-nss.

    vim /etc/init.d/instance_name
    
  3. On Linux systems only. Remove the line:

    LD_PRELOAD="/usr/lib64/dirsec/libssl3.so ${LD_PRELOAD}"
    

    Replace it with the following:

    LD_PRELOAD="/usr/lib64/libssl3.so ${LD_PRELOAD}"
    

    On 32-bit systems, the path is /usr/lib/.

  4. Restart the subsystem. For example:

    /etc/init.d/rhpki-tps restart
    
On the RA

Note: For systems which use a third party RA, NSS will need to be updated to use the new protocol.  If this is not possible, additional changes may need to be made on the RA and CA so that the RA can connect to an appropriate client auth port.

  1. Update the system nss and pki-ra packages. On Red Hat Enterprise Linux, install the system NSS packages. For example:

    up2date nss pki-ra
    

    On Sun Solaris, stop the servers, and remove the old NSS, NSPR, and RA packages.

    /etc/init.d/instance_ID stop
    pkgrm RHATdirsec-nssx RHATdirsec-nsprx RHATrhpki-rax

    Then, install the RHATdirsec-nssx and RHATdirsec-nsprx packages and restart the servers. For example:

    pkgadd -d /path/to/RHATdirsec-nsprx-4.8.4.sparcv9.pkg
    pkgadd -d /path/to/RHATdirsec-nssx-3.12.6.sparcv9.pkg
    pkgadd -d /path/to/RHATrhpki-rax-7.3.0-70.sol9.noarch.pkg
    /etc/init.d/instance_ID start
  2. On Linux systems only. For an existing subsystem, edit the init script to preload the system NSS library rather than dirsec-nss.

vim /etc/init.d/instance_name
  1. On Linux systems only. Remove the line:

    LD_PRELOAD="/usr/lib64/dirsec/libssl3.so ${LD_PRELOAD}"
    

    Replace it with the following:

    LD_PRELOAD="/usr/lib64/libssl3.so ${LD_PRELOAD}"
    

    On 32-bit systems, the path is /usr/lib/.

Reconfiguring Red Hat Certificate System 7.1

Certificate System 7.1 uses NSS libraries that are contained in the 7.1 package. Updated NSS and Certificate System packages and dependencies will be available as a hot fix from SEG. The build number for the hot fix is 20100317.1, and the three packages are:

  • RHCS 7.1 - RHDS 7.1 (SP 7) + RHDS 7.1 Patch + MITM
    
RHDS 7.1 - MITM
  • NES 6.2 (SP 1) - MITM
    

The Certificate Authority subsystem and its end-entities service may be reconfigured to avoid server-initiated TLS/SSL session renegotiations. This will allow all browsers to continue to work successfully with the updated Certificate System subsystems. Client requests for enrollment forms that require client authentication will be directed to the agent port, so renegotiations are avoided.

Note: File locations are slightly different on Red Hat Enterprise Linux systems than on Sun Solaris systems. These examples use the Linux locations. Use the file and directory locations for your specific installation and platform.

  1. Apply the NSS patch to the 7.1 server. The new file with the patch is libssl3.so, which replaces the existing libssl3.so file in several locations:

    • /opt/redhat-cs/bin/admin/lib/libssl3.so
    • /opt/redhat-cs/bin/https/lib/libssl3.so
    • /opt/redhat-cs/bin/slapd/lib/libssl3.so
    • /opt/redhat-cs/bin/cert/lib/libssl3.so
    • /opt/redhat-cs/shared/lib/libssl3.so
    • /opt/redhat-cs/clients/lib/libssl3.so
  2. Before making any edits to the CA configuration, back up the following files:

    • /opt/redhat-cs/instance_name/web-apps/ee/ra/ProfileSelect.template
    • /opt/redhat-cs/instance_name/web-apps/agent/WEB-INF/web.xml
  3. Open the profile selection template for the RA.
vim /opt/redhat-cs/instance_name/web-apps/ee/ra/ProfileSelect.template
  1. Replace the uri value for the RA services in the CA with the full URL to the agent interface. The original line reads:
uri = '/ra/profileSubmitSSLClient';
The new value will be something like the following

<pre>uri = 'https://server.example.com:9443/ra/profileSubmitSSLClient';

  1. Open the profile selection template for the CA.
vim /opt/redhat-cs/instance_name/web-apps/ee/ca/ProfileSelect.template
  1. Next, replace the uri value for the profile submission services with the full URL to the agent interface. The original line reads:
uri = '/ca/profileSubmitSSLClient';
The new value will be something like the following

<pre>uri = 'https://server.example.com:9443/ca/profileSubmitSSLClient';

  1. Open the web.xml file for the CA's agent services.
vim /opt/redhat-cs/instance_name/web-apps/agent/WEB-INF/web.xml
  1. Add these lines to the web.xml file:


    <servlet>
    <servlet-name> caProfileSubmitSSLClient </servlet-name>
    <servlet-class> com.netscape.cms.servlet.profile.ProfileSubmitServlet</servlet-class> <init-param>
    <param-name> GetClientCert </param-name>
    <param-value> false </param-value> </init-param>
    <init-param>
    <param-name> ACLinfo </param-name>
    <param-value> certServer.ee.profile:submit,read:allow(submit,read) user="anybody":Anybody may submit certificate profiles </param-value>
    </init-param>
    <init-param>
    <param-name> AuthzMgr </param-name>
    <param-value> BasicAclAuthz </param-value>
    </init-param>
    <init-param>
    <param-name> authorityId </param-name>
    <param-value> ca </param-value>
    </init-param>
    <init-param>
    <param-name> ID </param-name>
    <param-value> caProfileSubmitSSLClient </param-value>
    </init-param>
    <init-param>
    <param-name> templatePath </param-name>
    <param-value> /ca/ProfileSubmit.template</param-value>
    </init-param>
    <init-param>
    <param-name> resourceID </param-name>
    <param-value> certServer.ee.profile </param-value>
    </init-param>
    </servlet>

    <servlet-mapping> <servlet-name> caProfileSubmitSSLClient </servlet-name>
    <url-pattern> /ca/profileSubmitSSLClient </url-pattern>
    </servlet-mapping>
  2. Create the following symbolic links:

ln -s /opt/redhat-cs/instance_name/web-apps/ee/ca/ProfileSubmit.template /opt/redhat-cs/instance_name/web-apps/agent/ca/ProfileSubmit.template

ln -s /opt/redhat-cs/instance_name/web-apps/ee/ra/ProfileSubmit.template /opt/redhat-cs/instance_name/web-apps/agent/ra/ProfileSubmit.template

ln -s /opt/redhat-cs/instance_name/web-apps/ee/ca/ProfileSubmit.html /opt/redhat-cs/instance_name/web-apps/agent/ca/ProfileSubmit.html

ln -s /opt/redhat-cs/instance_name/web-apps/ee/ra/ProfileSubmit.html /opt/redhat-cs/instance_name/web-apps/agent/ra/ProfileSubmit.html
  1. Restart the CA and Directory Server instances.
/opt/redhat-cs/instance_db_name/restart-slapd
/opt/redhat-cs/instance_name/restart-cert

Was this helpful?

We appreciate your feedback. Leave a comment if you would like to provide more detail.
It looks like we have some work to do. Leave a comment to let us know how we could improve.
Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.