Resident Portal stuck on loading after Get My UIN — PMS OAuth client creation fails due to missing Auth_Partner certificate_alias

shashwat · July 1, 2026, 6:58am

Hi MOSIP Community,

I am deploying MOSIP v3 on-prem without DNS in my own data center for a demo / POC environment.

Most of the core flow is working now:

Backend services are running.
Registration Client flow is working.
UIN is getting generated successfully in the backend.
Pre-registration and registration-related flow is working.
Resident Portal UI is opening.

However, I am stuck at the Resident Portal login / profile flow.

When I open the Resident Portal and click on “Get My UIN”, the page remains stuck on a loading screen.

In the browser console, I see these errors:

GET https://api.sandbox.xyz.net/resident/v1/profile?languageCode=eng 401 (Unauthorized)

GET https://resident.sandbox.xyz.net/null 404 (Not Found)

Current Understanding

From our debugging, it looks like the Resident Portal is not completing the intended eSignet login flow because the Resident OIDC / OAuth client is not getting created successfully in PMS / eSignet.

We verified that Resident is intended to redirect to eSignet in this setup.

Resident service has the following configuration:

mosip.iam.module.clientID=mosip-resident-client
mosip.iam.base.url=https://esignet.sandbox.xyz.net/v1/esignet
mosip.iam.authorization_endpoint=https://esignet.sandbox.xyz.net/authorize

So the expected design seems to be:

Resident Portal → eSignet login → token/session → Resident profile API

But currently, Resident Portal is calling:

https://api.sandbox.xyz.net/resident/v1/profile?languageCode=eng

and receiving:

401 Unauthorized

Then the UI also tries to access:

https://resident.sandbox.xyz.net/null

which returns:

404 Not Found

What We Have Verified

1. PMS OAuth client API path

We found that the correct PMS endpoint for OAuth client creation is:

POST /v1/partnermanager/oauth/client

The older /oidc/client endpoint appears to be deprecated / not used in this flow.

2. PMS authentication behavior

In our setup, PMS did not accept the token when passed as a normal Bearer token header.

This failed:

Authorization: Bearer <jwt>

PMS log:

2026-06-30T13:38:40.281Z
Exception : Authorization token not present > http://pms-partner/v1/partnermanager/oauth/client
logger: io.mosip.kernel.auth.defaultadapter.filter.AuthFilter

But passing the token as a cookie worked:

Cookie: Authorization=<jwt>

After using cookie-based auth, PMS accepted the request and returned PMS roles such as:

AUTH_PARTNER
PARTNER_ADMIN

So PMS authentication seems to work only through the cookie format in our current setup.

3. OAuth client creation reaches PMS business logic but fails during publish

When calling:

POST /v1/partnermanager/oauth/client

PMS enters the OAuth client creation flow, but fails while publishing client data because it tries to fetch the partner certificate from Keymanager.

PMS response:

{
  "id": "mosip.partnermanagement",
  "version": "1.0",
  "errors": [
    {
      "errorCode": "PMS_KKS_001",
      "message": "Error while accessing the API.Please check the logs."
    }
  ]
}

Relevant PMS server-side log:

2026-06-30T13:45:55.383Z
Error occurred while calling http://keymanager.keymanager/v1/keymanager/getPartnerCertificate/
logger: io.mosip.pms.common.util.RestUtil

org.springframework.web.client.HttpClientErrorException: 404 Not Found

at io.mosip.pms.oauth.client.service.impl.ClientManagementServiceImpl.getPartnerCertificate(ClientManagementServiceImpl.java:480)
at io.mosip.pms.oauth.client.service.impl.ClientManagementServiceImpl.publishClientData(ClientManagementServiceImpl.java:470)
at io.mosip.pms.oauth.client.service.impl.ClientManagementServiceImpl.createOAuthClient(ClientManagementServiceImpl.java:174)

Current Resident Auth Partner State

The configured Resident Auth Partner is:

partnerId = mpart-res-oidc-auth
partner_type_code = Auth_Partner

Database query:

select id, name, certificate_alias, approval_status, is_active, upd_dtimes
from pms.partner
where id='mpart-res-oidc-auth';

Result:

id                 = mpart-res-oidc-auth
name               = Resident OIDC Auth Partner
certificate_alias  = NULL
approval_status    = approved
is_active          = true

Extended DB state:

id                  = mpart-res-oidc-auth
name                = Resident OIDC Auth Partner
partner_type_code   = Auth_Partner
certificate_alias   = NULL
approval_status     = approved
is_active           = true
policy_group_id     = mpolicygroup-default-auth

So the Resident Auth Partner is approved and active, but it does not have a certificate alias.

Our understanding is that PMS fails during OAuth client creation because partner.certificate_alias is empty for this Auth Partner, so PMS / Keymanager cannot retrieve the partner certificate while publishing the OAuth client.

Certificate Upload Attempts

We tried the intended PMS certificate onboarding flow.

AUTH CA upload

We uploaded AUTH root CA using:

/v1/partnermanager/partners/certificate/ca/upload

Response:

{
  "response": {
    "status": "Upload Success."
  },
  "errors": []
}

AUTH sub-CA upload

We uploaded AUTH sub-CA using the same API.

Response:

{
  "response": {
    "status": "Upload Success."
  },
  "errors": []
}

Partner certificate upload

However, uploading the partner certificate still fails with:

{
  "errors": [
    {
      "errorCode": "KER-PCM-006",
      "message": "Root CA/Intermediate CA Certificates not found."
    }
  ]
}

This happens even after uploading the AUTH root CA and AUTH sub-CA.

So it looks like the partner certificate we are trying to upload is not chaining to the AUTH CA chain recognized by PMS / Keymanager.

Attempt to register existing self-signed AUTH partner certificate as CA

We also tried to register the existing self-signed AUTH partner certificate as CA, but that failed with:

{
  "errors": [
    {
      "errorCode": "KER-PCM-005",
      "message": "Root CA Certificate not found."
    }
  ]
}

Existing AUTH-domain Certificate Found in Keymanager

We found one existing AUTH-domain certificate in Keymanager:

cert_id             = fedfbac5-981c-4617-955b-1b82afb1dd9a
partner_domain      = AUTH
organization_name   = mpartner-default-abis
cert_subject        = CN=mpartner-default-abis,...
cert_issuer         = CN=mpartner-default-abis,...

This certificate belongs to:

partner_id          = mpartner-default-abis
partner_type_code   = ABIS_Partner
certificate_alias   = fedfbac5-981c-4617-955b-1b82afb1dd9a

So the only existing AUTH-domain certificate we found is tied to an ABIS_Partner, not the Resident Auth Partner.

Actual Issue

The Resident Portal is stuck on the loading page after clicking Get My UIN.

Browser console errors:

GET https://api.sandbox.xyz.net/resident/v1/profile?languageCode=eng 401 (Unauthorized)

GET https://resident.sandbox.xyz.net/null 404 (Not Found)

From backend debugging, the likely root cause is:

Resident OAuth/OIDC client is not created successfully in PMS/eSignet because the backing Auth_Partner mpart-res-oidc-auth does not have a valid partner certificate / certificate_alias.

PMS OAuth client creation fails in:

ClientManagementServiceImpl.publishClientData()

while trying to retrieve the partner certificate from Keymanager:

http://keymanager.keymanager/v1/keymanager/getPartnerCertificate/

Questions

For Resident Portal with eSignet, when creating the Resident OAuth client through:

POST /v1/partnermanager/oauth/client

does the backing Auth_Partner always need a partner certificate uploaded first through PMS?

What is the exact intended onboarding sequence for Resident / eSignet OAuth client setup in a sandbox deployment?

Is it supposed to be:

1. Create Auth_Partner
2. Upload AUTH root CA
3. Upload AUTH intermediate/sub-CA
4. Upload Auth Partner certificate
5. Create OAuth client through /v1/partnermanager/oauth/client
6. Resident Portal uses this client ID for eSignet login

For the Resident Auth Partner:

partnerId = mpart-res-oidc-auth
partner_type_code = Auth_Partner
certificate_alias = NULL

what certificate should be uploaded and linked?

Is there any standard sandbox/sample certificate material for the Resident/Auth Partner flow?
Why would partner certificate upload still return this error even after AUTH root CA and AUTH sub-CA upload succeeded?

KER-PCM-006: Root CA/Intermediate CA Certificates not found.

Is the browser-side issue:

GET /resident/v1/profile 401 Unauthorized
GET /null 404 Not Found

expected when the Resident OIDC/eSignet client is missing or not properly created?

Any guidance on the correct Resident Portal + eSignet + PMS OAuth client onboarding flow would be very helpful.

Thanks.

mrudula · July 2, 2026, 5:46am

Hi Shashwat,

Thank you for reaching out to us.

Our team will look into the issue and get back to you shortly.

Regards,
Mrudula
on behalf of Team MOSIP

Kamesh · July 2, 2026, 10:17am

Hi Shashwat,

Thanks for the detailed debugging notes — your root-cause analysis is correct. The OAuth client creation fails in publishClientData() because the backing Auth_Partner has no partner certificate (certificate_alias = NULL), so Keymanager’s getPartnerCertificate returns 404. And yes, the browser-side 401 on /resident/v1/profile and the /null 404 are expected symptoms when the Resident OIDC client is missing — the eSignet login flow never completes, so the portal has no session. The /null in the URL is the UI receiving a null authorization/redirect URL because the client isn’t configured.

The issue with your certificate uploads (KER-PCM-006) is that you’re uploading externally generated / self-signed certificates that don’t chain to any CA known to PMS. For the Resident OIDC client, you should not generate your own certificates — the intended flow uses certificates already issued by MOSIP’s Keymanager, which chain correctly by design.

Please follow the documented procedure here:

In summary, the correct onboarding sequence is:

Create a policy group and Auth policy for the Resident OIDC client, then publish the policy (policymanager APIs).
Self-register the Auth Partner (partnerType: Auth_Partner).
Get the ROOT certificate from Keymanager (getCertificate with AppID: ROOT, refID: "") and upload it as a CA certificate with partnerDomain: Auth.
Get the RESIDENT certificate from Keymanager (AppID: RESIDENT, refID: "") and upload it also as a CA certificate with partnerDomain: Auth.
Get the RESIDENT : IDP_USER_INFO certificate from Keymanager (AppID: RESIDENT, refID: IDP_USER_INFO) and upload it as the Partner certificate for your Auth Partner with partnerDomain: Auth. This is what populates certificate_alias for the partner.
Map the policy to the partner and approve the mapping.
Prepare the JWKS public key JSON from the RESIDENT certificate (with the correct kid from the getAllCertificates API) and create the OIDC client via the client management createClient API, with authPartnerId set to your Auth Partner.
Set the returned clientId in resident-default.properties as mosip.iam.module.clientID and restart the resident service.

Answering your specific questions:

Yes — the Auth Partner must have a partner certificate uploaded before OAuth/OIDC client creation; publish fetches it from Keymanager.
The sequence above (from the linked doc) is the intended one — your proposed sequence was close, but the certificates must be the Keymanager-issued ones, not external ones.
Upload the RESIDENT : IDP_USER_INFO certificate from Keymanager as the partner certificate.
No separate sample certificate material is needed — Keymanager in your own deployment already has the required certs.
KER-PCM-006 occurs because your partner certificate’s issuer chain doesn’t match the CA certs registered in PMS. Using the Keymanager ROOT + RESIDENT certs as the CA chain resolves this.
Yes, expected — once the OIDC client is created and configured, the login flow should complete and those errors should go away.

Alternative — automated onboarding: Instead of running these steps manually, you can use the partner-onboarder Helm chart from the eSignet repo, which automates the entire resident-oidc onboarding (partner registration, certificate upload from Keymanager, policy mapping, and OIDC client creation). Enable the resident-oidc module in its values.yaml:

github.com/mosip/esignet

partner-onboarder/values.yaml

4a1055b70


      
          - name: abis
            enabled: false
          - name: resident
            enabled: false
          - name: mobileid
            enabled: false
          - name: digitalcard
            enabled: false
          - name: esignet
            enabled: true
          - name: resident-oidc
            enabled: true
          - name: demo-oidc
            enabled: false
          - name: mimoto-keybinding
            enabled: false

- name: resident-oidc
  enabled: true

The underlying onboarding scripts live in the mosip-onboarding repo, which can also be used standalone (Docker-based, with shell scripts and Postman collections, plus HTML result reports):

Since your environment uses self-signed SSL certificates, set ENABLE_INSECURE=true when running the onboarder so the scripts can work with your certificates.

Run the onboarder job against your environment, then check the job’s output/report for the generated clientId and set it in resident-default.properties (mosip.iam.module.clientID). This is usually the easier path for a sandbox/POC deployment and avoids manual certificate-chain mistakes like the KER-PCM-006 you hit.

Module version compatibility: Also, please make sure you are using compatible module versions. The latest Resident Services release is v0.9.1 (resident-services 1.2.1.1 with resident-ui 0.9.1), and its tested/certified compatibility matrix is here:

Key ones relevant to this issue: partner-management-service and policy-management-service 1.2.1.0, kernel-keymanager-service 1.2.0.1, mosip-config 1.2.3.1. Could you share which versions of resident-services, resident-ui, PMS, keymanager, and eSignet you have deployed? Version mismatches between these modules can also cause failures in the partner/certificate/OIDC flow.

A note for your no-DNS setup: the errors you’re seeing are HTTP 401/404 responses, not DNS failures, so hostname resolution itself is working. However, when you create the OIDC client, make sure redirectUris and logoUri in the client creation request, and the mosip.iam.* properties in resident config, all use the exact hostnames your environment actually resolves (hosts file / internal DNS). A mismatch there will break the redirect back from eSignet after login even once the client is created correctly.

If you prefer starting clean, you can register a fresh Auth Partner per the doc instead of reusing mpart-res-oidc-auth.

Hope this helps — let us know how it goes.

Regards,
Kamesh
on behalf of Team MOSIP

Topic		Replies	Views
Resident Portal UI not able to hit the services eSignet	3	290	December 4, 2023
Auth Partner certificate not matching with signature header during esignet send otp Support esignet , partner_management	12	264	September 25, 2025
Partner Management Portal - Doesn't show dashboard, Can't create Device nor SBI	18	827	May 2, 2023
IDA-MPA-001 Signature Verification Failure Support	32	397	November 20, 2025
Packets-failing-during-biometric-verification-with-system-exception Support	4	60	May 29, 2026