Feature Request: Support more certificate formats [other than .pem] for TrustStore

[HemanthShettyM]

Describe the bug SAP BTP subaccount has a destination which is of authentication type Basic authentication. Destination also has a trust store certificate uploaded in it. When this destination is used for making API calls, server is returning the error "unable to verify the first certificate"

Expected behavior I have been using both cloud-sdk-java and cloud-sdk-js for fetching destination details and for API execution. When destination has truststore certificate in .crt format, API call was executing successfully. But cloud-sdk-js throws the error 'unable to verify the first certificate' when the destination has truststore certificate in .crt format Upon debugging I found out that cloud-sdk-js supports only pem format for certificates. When I used the certificate in pem format in the destination, cloud-sdk-js still throws the same error. Can you please check if the trust store certificate from any destination is getting used correctly while making API calls?

Few more things observed: For certificates in destination, cloud-sdk-java supports formats [jks, crt, cer and der] but cloud-sdk-js supports only pem format. Cloud-sdk-java throws exception when certificate format isn't a supported one but cloud-sdk-js doesn't. When destination has truststore certificate in .pem format, cloud-sdk-js uses the certificate to form httpsAgent. The certificate would be added to ca attribute of httpsAgent. Before putting the certificate into this ca attribute, cloud-sdk-js is decoding the certificate content using the statement Buffer.from(destination.trustStoreCertificate.content, 'base64').toString('utf8'); is this conversion from base64 to utf-8 needed?

Screenshots If applicable, add screenshots to help explain your problem.

Used Versions: 3.13.0

• node version via node -v 20.11.0
• npm version via npm -v
• SAP Cloud SDK version you used as dependency 3.13.0

Code Examples If applicable, add code snippets as examples to help explain your problem. Please remove sensitive information.

Log file If applicable, add your log file or related error message. Again, please remove your sensitive information.

Impact / Priority High

Code has already been live and customer is unable to use the destination that has certificates in it.

Affected development phase: e.g. Getting Started, Development, Release, Production Production

Impact: e.g. No Impact, Inconvenience, Impaired, Blocked Blocked

Timeline: e.g. Go-Live is in 12 weeks.

Additional context Add any other context about the problem here.

[tomfrenken]

Hi @HemanthShettyM,

thanks for raising this feature request. Looking at our documentation and code, we don't support these file formats yet because there was no demand for them, though technically supporting them should be possible.

Looking at our current priorities, it is unlikely that we will be adding this feature soon. I have created a backlog item in our project to reflect and review this feature request in the future. If this feature request is urgent, feel free to create a contribution.

In the meantime, you should be able to change the format in your CLI to follow the pem format.

[HemanthShettyM]

Hi @tomfrenken, pem format certificate was used, but it was still resulting in the error "unable to verify the first certificate". Whenever pem format certificate is read by cloud-sdk-js, the certificate content is getting modified using the statement Buffer.from(destination.trustStoreCertificate.content, 'base64').toString('utf8');

Is this conversion needed? will the server be able recognise the modified certificate content?

[tomfrenken]

Hi @HemanthShettyM,

The type string matches the required type by the HTTP client. The conversion here is to toString, and utf8 is the default. We are simply explicit about the encoding and not making any major changes.

The reason it's read from base64 is because Cloud Foundry encodes the certificate when you upload it.

If you get an "unable to verify the first certificate" error with a .pem file, your setup is likely the cause. Please make sure that your certificate is valid and properly uploaded/set up in the destination.