Establecimiento de una comunicación segura entre la vista Perfiles de z/OS Debugger y el sistema z/OS para CICS

Nota:

Debug Profile Service API (DPS) API es el método preferido para gestionar perfiles DTCN. Si la API DPS no se está ejecutando o no se puede acceder a ella, la interfaz de usuario Eclipse vuelve a la interacción directa con la API DTCN en la región de destino CICS. Este fallo se produce cuando se permite a los usuarios introducir manualmente el número de puerto para la API DTCN de destino. De lo contrario, cuando la API DPS está disponible, Eclipse UI consulta la API DPS para mostrar una lista de regiones CICS compatibles entre las que elegir.

Siga los siguientes pasos para asegurar la comunicación entre UI y DTCN API sin DPS API. Para proteger la propia API DPS, consulte la sección Activación de la comunicación segura en "Configuración del servidor" > "Definiciones de seguridad del servicio de perfiles de depuración".

Estos pasos le ayudarán a habilitar la comunicación segura a través de Secure Sockets Layer (SSL) entre la vista z/OS Debugger Profiles con Eclipse y su sistema z/OS®. La comunicación entre el cliente y el servidor utiliza el protocolo HTTP. Z Open Debug proporcionado con Wazi para Dev Spaces o Wazi para VS Code no soporta la comunicación directa entre el cliente y la API DTCN.

Configuración del lado del servidor

Para habilitar la comunicación SSL, efectúe las siguientes tareas en el lado del servidor:
  • Genere el par de claves y el certificado firmado automáticamente
    1. Utilice el mandato RACF GENCERT para crear una entrada de clave para el propietario de la región CICS® . La entrada de claves contiene el par de claves y el certificado firmado automáticamente.
      Nota: El ejemplo siguiente muestra los mandatos RACF tal como se codificarían en un ejecutable REXX. Se recomienda esta opción debido a la longitud de los mandatos.
      Ejemplo (Crear una entrada de clave para el usuario USERID con la etiqueta: USERID-DTCNPLG-CERT):
      /* generate key entry */ 
"RACDCERT ID(USERID) GENCERT", 
" SUBJECTSDN(CN('your_host_name.com' )", 
"T ('USERID-DTCNPLG-CERT' ) ", 
"OU('IBM' ) ", 
"O ('IBM' ) ", 
"L ('San Jose' ) ", 
"SP('CA' ) ", 
"C ('US' ))", 
" NOTBEFORE(DATE(2011-02-28) TIME(20:00:00) )", 
" NOTAFTER (DATE(2031-12-31) TIME(19:59:59) )", 
" WITHLABEL(‘USERID-DTCNPLG-CERT’ )", 
" SIZE (1024 )"
      El nombre común del DSN del asunto debe ser el nombre de host del servidor que el cliente utiliza para conectarse al host.
    2. Conecte la entrada de clave a un conjunto de claves que pertenezca al ID de propietario de región CICS .
      Ejemplo (Conéctese a un conjunto de claves denominado USERID):
      /* connect key entry to key ring */ 
"RACDCERT ID(USERID )”, 
“CONNECT( RING(USERID ) ", 
" LABEL(‘USERID-DTCNPLG-CERT’ ))"
    3. Exporte el certificado y almacénelo en el conjunto de datos utilizando el formato de codificación definido por el estándar RFC 1421 de Internet.
      Ejemplo (Exportar el certificado a un conjunto de datos: USERID.DTCNPLG.CERT):
      /* export certificate to a data set */ 
"RACDCERT EXPORT(LABEL(‘USERID-DTCNPLG-CERT’ ) ", 
" ID(USERID ) ", 
" DSN('USERID.DTCNPLG.CERT' ) ", 
" FORMAT(CERTB64 ) "
  • Actualice los parámetros de inicialización del sistema en la región CICS .
    1. Añada un parámetro de inicialización del sistema KEYRING al trabajo de región CICS y apunte al conjunto de claves creado para el ID de propietario de región.
    2. El ejemplo siguiente añade KEYRING a los parámetros de inicialización del sistema de la región CICS :
      SIT=6$,               
START=INITIAL,        
RENTPGM=PROTECT,      
...
TRANISO=YES,   
KEYRING=key-ring-name,
EDSALIM=132M,           
        ...
  • Modifique el TCPIPSERVICE que ha definido anteriormente para establecer dos atributos:
    • SSl : Yes Yes | No | Clientauth
    • CErtificate : USERID-DTCNPLG-CERT

Configuración del lado del cliente

Para habilitar la comunicación SSL, realice las siguientes tareas en el lado del cliente. Para los usuarios de la vista Perfiles de z/OS Debugger con Eclipse, las tareas siguientes no son necesarias porque a los usuarios se les solicitará que acepten o rechacen cualquier certificado que no esté instalado cuando utilicen la vista.
  • Instale el certificado de cliente.

    Dado que el certificado de servidor generado no procede de una CA autorizada, deberá instalar el certificado en el almacén de claves que IBM® Developer for z/OS utiliza.

    1. Obtenga el certificado de cliente descargando una copia del certificado de servidor exportado (utilizando la modalidad de texto) que se ha creado en el paso 3 de la configuración del lado del servidor para la estación de trabajo.
    2. Importe el certificado de cliente en el almacén de claves. A continuación se muestra un ejemplo de cómo importar el certificado en el almacén de claves utilizando la herramienta de claves proporcionada por Java™.

      Para Java versión 1.7: keytool –importcert –alias myprivateroot –keystore

      C:\YOUR_WORKSPACE_DIRECTORY\.metadata\.plugins\com.ibm.cics.core.comm\explorer_keystore.jks –file dtcnplg.cer

      dtcnplg.cer es el certificado de cliente. La contraseña inicial para el almacén de claves es changeit.

    Notas:
    • Para Java versión 1.7, el almacén de claves predeterminado es: C:\YOUR_WORKSPACE_DIRECTORY\.metadata\.plugins\com.ibm.cics.core.comm\explorer_keystore.jks
    • Para IBM Developer for z/OS, el programa de utilidad keytool se puede encontrar en este directorio bin de instalación de Java, C:\DEVELOPER_FOR_Z_SYSTEMS\jdk\jre\bin.