I have setting up the Inji Wallet stack using Certify + Mimoto + Inji-Web on a single VM (Docker-based setup). While configuring Mimoto v0.19.2 with issuer configuration provided via local filesystem (mimoto-issuers-config.json mounted inside the container), the application fails during startup. During startup issuer validation, Mimoto attempts to read the issuer config using RestApiClient, even when the issuer config path points to a local file. This results in the following error and the application exits with code 1.
Could you please confirm whether this is a known limitation in Mimoto v0.19.2 and advise the recommended approach for local or VM-based setups?
I re-ran Mimoto v0.19.2 using the inji-certify docker-compose on a single VM. The startup still fails when issuer configuration is provided via a local file mounted inside the container.
Key log lines:
“Validation for mimoto-issuers-config.json STARTED”
“I/O error on GET request for “/home/mosip/mimoto-issuers-config.json”: Target host is not specified”
“Validation failed in Mimoto-issuers-config.json:”
“Application run failed”
This indicates the local file path is being treated as an HTTP URL by RestApiClient, so startup issuer validation fails even in the docker-compose setup.
Customizations made (mimoto-default.properties):
Set public URLs/ports for my VM (e.g., server.port=8099, server.servlet.context-path=/v1/mimoto, mosip.api.public.url=http://<vm-ip>:8099 etc.)
Config server path aimed to local FS: config.server.file.storage.uri=/home/mosip/
Issuer list file configured: mosip.openid.issuers=mimoto-issuers-config.json (the JSON is mounted at /home/mosip/mimoto-issuers-config.json)
Other service URLs (resident/esignet/masterdata/redis/db) were adjusted for this VM.
Observation:
Despite the above, issuer validation still runs on startup and the code path uses RestApiClient for /home/mosip/mimoto-issuers-config.json, which causes the failure. So either:
local-file based issuer config isn’t supported in 0.19.2 during startup validation, or
I’m not using the correct property names / expected location, so the ResourceLoader path isn’t taken, or
the inji-certify compose expects a different variable for issuers config resolution.
Requests for clarification:
What is the recommended way in v0.19.2 to load issuer config from the local filesystem in docker-compose? (Property name / expected path / scheme, e.g., file:///...?)
What is the correct flag to completely bypass startup issuer validation in air‑gapped/local setups?
In the inji-certify docker-compose, which env var drives issuer config resolution so that ResourceLoader is used rather than RestApiClient?
I can share the Mimoto service environment and volumes block from docker-compose.yaml if needed.
Recommended way in v0.19.2 to load issuer config from the local filesystem in docker-compose
The issuers configuration file is mounted from the local path:
into the container at runtime. Since this is a bind mount, the Mimoto service reads the configuration directly from the host machine. Therefore, any updates made to the file locally will be reflected in the container upon restarting the Mimoto service.
Note:
For any changes made in the mimoto-issuers-config.json (path - docker-compose/docker-compose-injistack/config/mimoto-issuers-config.json), mimoto service restart is required to get the latest changes
bypass startup issuer validation
Issuer Configuration validation is a mandatory step
In the docker-compose, which env var drives issuer config resolution so that ResourceLoader is used rather than RestApiClient?
Issuer configuration is resolved through RestApiClient for docker compose
# Properties file location - docker-compose/docker-compose-injistack/config/mimoto-default.properties
# Host for the rest API call
config.server.file.storage.uri=http://inji-web:3004/
# issuers configuration path
mosip.openid.issuers=mimoto-issuers-config.json
Actions
We kindly request that you share the relevant Mimoto service logs related to the issuers configuration validation failure. The logs should provide specific details about the cause of the issue.
For reference, an example scenario would be a validation failure occurring when an issuerId is not present in the issuers configuration file.
Validation failed in Mimoto-issuers-config.json:
Errors for issuer at index: 0 with issuerId - null
- issuer_id must not be blank
- TokenEndpoint does not match with the credential issuerId
","logger_name":"io.mosip.mimoto.config.IssuersValidationConfig","thread_name":"main","level":"ERROR","level_value":40000,"appName":"mimoto"}
{"@timestamp":"2026-03-04T14:36:05.204Z","@version":"1","message":"Application run failed","logger_name":"org.springframework.boot.SpringApplication","thread_name":"main","level":"ERROR","level_value":40000,"stack_trace":"java.lang.RuntimeException:
Validation failed in Mimoto-issuers-config.json:
Errors for issuer at index: 0 with issuerId - null
- issuer_id must not be blank
- TokenEndpoint does not match with the credential issuerId
Attaching such log output will help in diagnosing the problem more effectively.
I followed your suggestion. The trick was to serve the config file through HTTP endpoint instead of direct file mount. Now mimoto starts properly and validation passes.
Thank you for confirming. We’re glad the issue has been resolved. Please feel free to reach out if you need any further assistance. Have a great day!