Hi @Tomasz Kot ,

Hope you have already installed Java Development Kit (JDK). If not you have to install it and set the environmental variables in your windows machine. And refer below link which shows how to set up client certificate on https request for a wsdl endpoint with SoapUI.

https://www.soapui.org/docs/functional-testing/sending-https-requests/

Best Regards,

Kavindu Gunathilake

Hi @kavinduxo ,

Thank you for your help.

I may have described what I meant poorly.

I don't have a problem with certificates in Windows and SoupUI. That service works as I described. The WSDL is being retrieved in the web browser and SoupUI.

The issue relates to certificates in IFS Aurena. I can't configure the Routing Address connection to retrieve the list of WSDLs and any service endpoints.

Best Regards,

Tomasz Kot

Hi @Tomasz Kot 

You need to create a pfx using the key and the certificate received by the bank and create a keystore.

Here are the steps to do that using OpenSSL (in windows)

Download and install OpenSSL full version (I used https://slproweb.com/products/Win32OpenSSL.html)

Check if the key and the certificate are in valid format

Sample key

Sample certificate

Copy the key and the certificate into the openssl bin directory

Open command prompt from openssl bin folder and type following

openssl pkcs12 -export -in cert.pem -inkey "privateKey.pem" -certfile cert.pem -out myProject_keyAndCertBundle.p12

give a password when prompted

Go to keystores page in IFS, Import file exported

name your keystore, upload the file and provide the same password you used above. After import, it should look like following

Now in your routing address (REST or HTTP), provide the keystore and keystore type in additional headers

ssl:KeyStoreId=test

ssl:KeyStoreType=PKCS12

This is tested in 22R2 and worked for me :)

Hope it helps!

Damith

I have been running into issues with the implementation in 22R2 and 23R1.  We are implementing a hardened trust pattern.  Mutual SSL that requires use of importing the certificate to the routing address and setup of a keystore. 

In Mutual SSL there are essentially 4 main steps in the trust chain to establish communication (that show up in connect that I’ve experienced so far).

OUTBOUND REST:

1. Client makes request of the server.  (for this step you need to have the servers valid certificate loaded in to your routing address that must be able to establish a trust chain with a certificate authority in the IFS TrustStore.  In managed you don’t have direct access to this.  If you don’t have this uploaded then you will usually get a step one error:

ifs.fnd.connect.senders.ConnectSender$TemporaryFailureException: Exception while sending data Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed:

2. Server Sends back its certificate for you to validate against the clients Keystore.  For this step you will need to have a Keystore setup in the Keystores Page.  The keystore must include the Client Signed Certificate with the entire trust chain including CA Certificate an the private key.

Connect will do the heavy lifting here as long a everything is in the Keystore is there and you have additional headers that have at least one line that says ssl:KeyStoreId=<keystore name>

If you get a malformed message or unable to read error from the server then this is a step 2 error.

3.  Connect sends the certificate from the Keystore to the server for verification.  Again, connects pulls your certificate from the keystore and send it.    

If your certificate is valid and verifiable by the server then you should not have an issue here

Most likely you will get any variety of responses from the server (invalid certificate, malformed, or invlaid) if this is the problem

4.  Oauth Mediated Communication Commences and you send your actual  request to the server.  

This step is the final step but actually includes a few communications when using Oauth:

1.  Authentication Step

In this step you will be sending whatever Authentication method you chose in your Routing Address (Client Credential/ROPC/Bearer).  

When using Bearer token I have no difficulty… Client Credential is still buggy however:

It is with CCF that I am currently awaiting bugs to be resolved by IFS.  When using client credential flow I would originally get a Java error that said that String out of bounds error.     That error has been resolved in 23R1.5, I think.

Now the current limitation with Mutual SSL CCF is producing the following error:   (ifs.fnd.connect.senders.ConnectSender$TemporaryFailureException: Error while trying to get the Oauth access token Caused by: ifs.fnd.connect.http.HTTPClient$UnauthorizedAccessException: POST error #401: Unauthorized access)

* Also notice the POST in the error, my message is a GET so this is clearly the OAUTH  Authentication POST step.

Regardless of the error though… if you see OAUTH you made it to step 4 and you successfully completed Mutual SSL.   

2.  Message Request / Response Step

If you get through all of this you  can expect a valid response message and maybe even some data.

I hope this helps anyone struggling with advanced Connect Security setup.