Certificados SSL de direccionamiento dinámico

Tres tipos de certificados SSL son relevantes para el direccionamiento dinámico para Liberty, el certificado de miembro, el certificado del controlador y el certificado de direccionamiento dinámico. Cada uno de los tres tipos de certificado tiene un certificado de firmante SSL asociado. Un certificado de firmante SSL garantiza la validez del certificado que firma.

Cada uno del os tres tipos siguientes de certificados tiene un certificado de firmante asociado:
Certificado de miembro
El certificado que presenta un miembro de colectivo cuando el servidor web intenta realizar una solicitud de cliente con proxy a un miembro mediante SSL.
Certificado de controlador
El certificado que presenta un controlador de colectivo al plug-in cuando el plug-in intenta conectarse al servicio de direccionamiento dinámico en un controlador de colectivo.
Certificado de direccionamiento dinámico
El certificado que presenta el plug-in al controlador cuando el plug-in intenta conectarse al servicio de direccionamiento dinámico en un controlador de colectivo.

Para la comunicación SSL de solicitudes con proxy a miembros de colectivo, el servidor web debe confiar en que el certificado de miembro es válido. Para que el servidor web confíe en que el certificado de miembro es válido, el certificado de firmante de miembro debe estar en el almacén de claves del servidor web.

El almacén de claves es el archivo .kdb al que se hace referencia con el elemento <Property Name="Keyfile" value=…/> xml en el archivo plugin-cfg.xml.

Para la comunicación SSL entre el plug-in y el servicio de direccionamiento dinámico, se deben cumplir las condiciones siguientes:
  • El plug-in debe confiar en que el certificado de controlador es válido.
  • El controlador debe confiar en que el certificado de direccionamiento dinámico es válido.
  • El certificado de direccionamiento dinámico debe estar autorizado a acceder al servicio de direccionamiento dinámico.
El certificado de direccionamiento dinámico debe satisfacer una de las condiciones siguientes para estar autorizado:
  • El sujeto de certificado coincide con el sujeto de certificado predeterminado que utiliza el direccionamiento dinámico. El sujeto de certificado predeterminado se crea de forma predeterminada cuando se utilizan las opciones setup o genKeystore del mandato dynamicRouting. A continuación se muestra el sujeto de certificado predeterminado:
    DC=com.ibm.ws.dynamic.routing,OU=dynamicrouting,CN=WebServer
  • [17.0.0.1 and later]El sujeto de certificado coincide con el valor del atributo certificateSubject del elemento XML <dynamicRouting> en el archivo server.xml del controlador de colectivo. Si se especifica, se utiliza este sujeto de certificado, en lugar del predeterminado, se utilizan las opciones dynamicRouting setup o genKeystore del mandato. Consulte el ejemplo siguiente:
    <dynamicRouting certificateSubject=”CN=Plugin,OU=ops,O=MyCompany,L=Raleigh,ST=NC,C=US”/>
  • El sujeto de certificado corresponde a un usuario del registro de seguridad que tiene asignado el rol de administrador. Un certificado de direccionamiento dinámico que tiene un sujeto con el rol de administrador permite el acceso a funciones administrativas en el colectivo desde la DMZ. Si se utiliza este tipo de certificado para acceder al servicio de direccionamiento dinámico, aparece un mensaje de error en el registro, pero la comunicación se realiza correctamente.

Las opciones setup y genKeystore del mandato dynamicRouting generan almacenes de claves con todos los certificados necesarios para garantizar la comunicación de red segura entre el servidor web y los servidores de un colectivo. Si desea utilizar la configuración de seguridad predeterminada, no es necesario realizar ninguna modificación.

Para utilizar certificados que no hayan sido creados por las opciones setup o genKeystore del mandato dynamicRouting, se deben cumplir las condiciones siguientes:
  1. Los certificados de firmante de miembro para todos los colectivos se encuentran en el archivo .kdb referenciado con el elemento XML <Property Name="Keyfile" value=…/> en el archivo plugin-cfg.xml.
    Nota: Solo es necesario si el plug-in utiliza SSL con solicitudes de cliente con proxy.
    <Property Name="Keyfile" Value="/opt/IBM/WebSphere/Plugins/config/webserver1/plugin-key.kdb"/>
  2. El certificado de firmante de controlador debe estar en el archivo .kdb referenciado con el elemento XML <Property name="keyring" value=…/> del elemento <Connector> para el controlador en el archivo plugin-cfg.xml.
    <Property name="keyring" value="/opt/IBM/WebSphere/Plugins/config/webserver1/plugin-key-collective1.kdb"/>
  3. El certificado de firmante de direccionamiento dinámico debe estar en el directorio siguiente de todos los controladores:

    ${server.output.dir}/resources/ collective/collectiveTrust.jks)

  4. El certificado de direccionamiento dinámico de un colectivo debe estar en el archivo .kdb referenciado con el elemento XML <Property name="keyring" value=…/> del elemento <Connector> para el controlador en el archivo plugin-cfg.xml. Consulte el ejemplo siguiente:
    <Property name="keyring" value="/opt/IBM/WebSphere/Plugins/config/webserver1/plugin-key-collective1.kdb"/>
  5. El sujeto de certificado en el certificado de direccionamiento dinámico es una de las opciones siguientes:
    • “DC=com.ibm.ws.dynamic.routing,OU=dynamicrouting,CN=WebServer”
    • [17.0.0.1 and later]El valor del atributo certificateSubject del elemento XML <dynamicRouting> en los archivos server.xml de los controladores en un colectivo.
    • Un usuario que tiene asignado el rol de administrador en el colectivo, lo que no se recomienda.

Icono que indica el tipo de tema Tema de concepto

Nombre de archivo: cwlp_wve_dynroute_cert.html