Esta publicación de blog intenta brindarle pasos paso a paso sobre cómo configurar la autenticación basada en certificados de cliente desde su sistema SAP Netweaver hacia SAP BTP, a veces denominada conexión entrante en la integración en la nube mediante la autenticación basada en certificados de cliente.

Sé que hay muchas publicaciones de blog disponibles y un par de KBA de SAP también disponibles. Pero me encontré con una situación única en nuestro paisaje y esa es la razón por la que quería compartir esa información/experiencia con todos ustedes.

En primer lugar, aclaremos lo básico primero.

En este caso, el cliente es mi sistema back-end SAP Netweaver ABAP On-Premise y el servidor es mi plataforma SAP BTP. Eso significa que tenemos que enviar un certificado al servidor.

Antes de seguir adelante con la autenticación basada en el certificado del cliente, me aseguré de que la prueba de la conexión con la autenticación básica fuera exitosa desde mi sistema Netweaver ABAP backend al crear una RFC simple de tipo ‘G’: conexión HTTP a un servidor externo.

¿Qué tenía de especial nuestro caso?

Se puede acceder a todas nuestras aplicaciones solo a través de Intranet y no están expuestas a Internet y sin mencionar que, como cualquier otra organización empresarial, nuestro entorno está conectado a cientos de otros sistemas internos, ya sea directamente o a través de diferentes middleware como SAP PO, BizTalk, IBM MQ etc.

La mayoría de esas integraciones también usan autenticación basada en certificados y tenemos nuestras CA internas para firmar nuestros certificados internos.

Ahora, cuando inicialmente comencé mi configuración, estaba preocupado por esto porque había creado la conexión RFC (tipo G) e intenté conectarme al arrendatario SAP BTP y siempre pedía credenciales de usuario.

Para solucionar este problema aún más, aumenté el nivel de seguimiento de ICM a 3 de esa instancia de aplicación específica e intenté averiguar qué estaba mal y adivinar qué es lo que noté.

[Thr 3232] CCL[SSL]: Cli-0001D1E1: Cannot perform client authentication: Have no certificate fitting to CA names received from server [ssl3_send_client_certificate]
[Thr 3232] Wed Dec 14 11:07:05:502 2022
[Thr 3232] CCL[SSL]: Cli-0001D1E1: Sending message with empty certificate list [ssl3_send_client_certificate]
[Thr 3232] CCL[SSL]: Cli-0001D1E1: Sending empty Certificate message. [tls1_empty_cert_list]

Entonces descubrí esta interesante información.

“el certificado de cliente de su sistema emisor debe estar firmado por una CA en la que confíe nuestro balanceador de carga (enumerado en la nota 2801396) para que este certificado pueda usarse para comunicarse con CPI.”

Eso significa que debo asegurarme de que estoy enviando un certificado de cliente firmado por CA aprobado por SAP para que este certificado se pueda usar para comunicarme con CPI / BTP.

Ahora tenía esta pregunta en mente, como mencioné anteriormente.

Si veo el propio certificado de mi sistema SAP ECC NW, ese es un certificado firmado por una CA interna y ese certificado se usa con todos los demás sistemas interconectados dentro de nuestra organización. Ahora, si obtengo un nuevo certificado externo, ¿todas mis conexiones existentes fallarán? ¿Tengo que cambiar ese certificado a todos los propietarios de mis sistemas interconectados? Cómo reaccionarán los demás porque es posible que otros propietarios de aplicaciones internas no acepten tener un certificado externo firmado para aplicaciones internas.

Con todas estas preguntas en mi mente, pensé que debía haber una manera por la cual no necesitaría cambiar el certificado de cliente actual.

Luego creé un PSE dedicado solo para este propósito y creé un CSR, lo firmé por las CA externas aprobadas por nuestra compañía (por cierto, afortunadamente, también fue una CA aprobada por SAP), lo cargué en el sistema back-end a través de la transacción STRUST. Pero no lo hizo predeterminado. Por lo tanto, todas las conexiones predeterminadas no se vieron afectadas y pude usar este nuevo certificado/PSE solo para la conexión CPI/BTP. De esta manera, nuestras conexiones internas aún usan el certificado interno predeterminado y la conexión CPI/BTP saliente usa el certificado recién firmado, no ocurrió ningún conflicto.

Estoy seguro de que todos ustedes saben cómo lograrlo, pero aún así, como guía a continuación, SAP KBA puede ser útil para crear un nuevo PSE.

2148372: cómo crear una identidad de PSE de cliente SSL propia

Una vez que se ha creado el PSE, debe crear la respuesta del certificado, es decir, CSR, que luego debe enviarse a la CA para que lo firme.

Captura de pantalla tomada de ECC: SAPBTP Dedicated PSE

Una vez que haya firmado el CSR, vuelva al código de transacción STRUST nuevamente y seleccione ese PSE dedicado que se creó anteriormente e importe esa respuesta de certificado (la cadena completa).

Una vez que se le devuelve el certificado firmado, en nuestro caso nos habían proporcionado las cadenas por separado: raíz, intermedio y el certificado principal.

Los abrí en un bloc de notas y pegué el contenido de los tres y luego en STRUST mientras importaba pegué todo el contenido. Después de eso, agréguelo a la Lista de certificados y guárdelo.

Una vez hecho esto, volvamos a SAP BTP Tenant y para que Cloud Integration admita la autenticación del certificado del cliente, debemos crear una instancia y generar una clave de servicio para el certificado.

Regrese a SAP BTP Cockpit, haga clic en Instancias y suscripción y haga clic en Crear

Captura de pantalla tomada de SAPBTP: Crear nueva instancia

Asigne un nombre a su instancia como se muestra a continuación, por ejemplo certificado de cliente y asegúrese de que el Servicio sea «Tiempo de ejecución de integración de procesos»

Haga clic en Siguiente y cree una instancia de servicio con Tipos de subvenciones ajustado a Credenciales del cliente.

Captura de pantalla tomada de SAPBTP: parámetro de instancia de servicio

Consulte 3171264: Nuevos pasos de configuración para configurar la autenticación del certificado del cliente (plan de flujo de integración)

Si todo va bien, se creará una nueva instancia de servicio; esto puede llevar algún tiempo.

Después de eso, debemos crear una clave de servicio como se muestra a continuación y debemos proporcionar el certificado de cliente X509 a la clave de servicio.

Haga clic en los tres puntos junto a la instancia que se creó anteriormente y seleccione Crear clave de servicio

Captura de pantalla tomada de SAPBTP: parámetro de instancia de servicio

En el campo Certificado externo (resaltado en ROJO), necesitamos copiar el contenido del certificado X.509 del certificado recién firmado.

Ingrese el certificado que le proporcionó la CA externa.

Introduzca el certificado X.509 con codificación PEM.

PEM representa Correo con privacidad mejorada y es un formato común para los certificados X.509. Contiene contenido de texto codificado en base64 con la cadena —–INICIAR CERTIFICADO—– al principio y la cadena —–FINALIZAR CERTIFICADO—– al final de la secuencia de caracteres.

Ejemplo:

—–INICIAR CERTIFICADO—–MIIHyDCCBrCgAwIB[…]CAq8Tn7kSFDmVnrXe6v8hcQ==—–FIN DEL CERTIFICADO—–

No ingrese toda la cadena de certificados, ingrese el certificado del servidor principal.

Mantenga el resto de la configuración como está:

Validez en días : 365

Tamaño de la clave: 2048

Ahora regrese al sistema Netweaver backend y cree un nuevo RFC (tipo G) como se muestra a continuación

Captura de pantalla tomada de ECC: Configuración RFC

Captura de pantalla tomada de ECC: Configuración RFC

Asegúrese de haber seleccionado el PSE dedicado correcto para el Certificado SSL Opción que se creó anteriormente.

Ahora el momento de la verdad: presione el botón «Prueba de conexión» y eso debería ser todo. Debería funcionar. Si no es así, vuelva a lo básico: aumente el ICM Trace y vea qué está fallando.

Dos cosas que tal vez quieras tener en cuenta

• Es posible que desee reiniciar ICM una vez desde el código de transacción SMICM antes de probar el RFC.
• La firma del certificado por parte de CA externas implicará un costo.

Ya hay un documento técnico en el siguiente WiKi al que me referí: