1

I've an endpoint which can be reached only through SSL validation. E.g. to reach it by Google Chrome, I've installed xxxx.p12 certificate. On other implementations, such as python, I can reach the endpoint by expliciting the cert part in the request, i.e.:

import requests

response = requests.get(request_URL, data=data, headers=self.headers, cert=(self.cert_prod,self.key_prod), verify=False)

where self.cert_prod and self.key_prod are initialised by referencing the two files:

  • self.cert_prod = 'SSLCerts/xxxx.crt' (got from openssl pkcs12 -in xxxx.p12 -out xxxx.crt -nodes -nokeys)
  • self.key_prod = 'SSLCerts/xxxx.key' (got from openssl pkcs12 -in xxxx.p12 -out xxxx.key -nodes -nocerts)

My intent is to implement an API call in wso2 Micro Integrator which, after some mediations, ultimately calls the request_url (requiring SSL). I'd expect there's a way to refer the certificates (xxxx.p12 or xxxx.crt/xxxx.key) in within the

<endpoint>
    <http method="post" uritemplate="request_url">
    .....
    </http>
  .....
</endpoint>

statement. But I wasn't able to find applicable examples. Any suggestion?

Cristiano
  • 51
  • 5

1 Answers1

1

I believe what you are trying to achieve is Mutual SSL or two-way SSL verification. You can accomplish this with Dynamic SSL profiled in WSO2. Take a look at this document.

This may also come in handy, but just read this to understand the concept and configs. This is written for an older version of WSO2.

ycr
  • 12,828
  • 2
  • 25
  • 45
  • You're amazing. I was just getting to the point, after many other searches. I understand that ssl certificates cannot directly linked to the endpoint/http placeholders in the ESB xml statement, but rather "statically" configure mi (or axis2??) to lookup the ssl files (which need to be converted in JKS format, via keytool) for a given hostname, as declared in the configuration file. Now I'm not sure what it is more convenient to modify, MI_HOME conf files as suggested in the first link, or axis2.xml, as suggested in the second link. I'll try both and I'll let you. Thanks ag for the time being! – Cristiano May 11 '23 at 12:34
  • Tried to modify deployment.toml as for first link and then add the senderprofiles.xml file in the appropriate directory. Since editing deployment.toml micro-integrator fails to startup. The system dyes with "FATAL {org.wso2.micro.integrator.server.Main} - Error while performing configuration changes org.wso2.config.mapper.ConfigParserException: Error while deleting carbon.xml". By the way modified deployment.toml is copied to deployment.temp.toml and the original version is restored. Even when removing the newly added directory sslprofiles and the new xml file, wso2mi fails. – Cristiano May 11 '23 at 13:57
  • N.B.: I'm working on conf files under wsointegrationstudio/runtime/microesb/conf .. not sure I'm doing right! Finally, let me abuse of your patience. At start up (even when everything was working fine) Consolle thrown a number of exceptions as ${sys:logfiles.home} can't be found. I set logfile.home in Windows System Environment Variables (tried different names too) and changed all log4j2.properties files removing variable and replacing with a fixed path, but the error pops out anyway, even if (before this FATAL now occurring), the system worked fine :-( – Cristiano May 11 '23 at 13:58
  • 1
    @Cristiano your path is correct. You shouldn't be editing the axis2.xml. With the release of MI the old config model was replaced by the `deployment.toml` so users can do the config changes in a single place. But eventually, the configs you add to the deployment.toml will be added to the `axis2.xml` and other relevant config files automatically. If you are directly adding the configs to the deployment.toml you shouldn't be starting the server through Integration Studio. Because integration Studio has a mechanism to update server configs via the UI. So start the server by going to MI/bin dir. – ycr May 12 '23 at 00:56
  • 1
    thanks again! I'll try harder :-). By the way FATAL error while boosting embedded MI instance was due to a backup/carbon.xml file blocked somehow, which impeded its deletion. Solution was reboot Windows OS :-). I still have initial "ERROR Unable to create file ${sys:logfiles.home}/wso2carbon.log", but then logs are correctly placed in the c:\wso2logs directory which I created and indicated in some of the conf files... – Cristiano May 12 '23 at 07:18