hyperledger/fabric · error
The identity is not a [%s] under this MSP [%s]
Error message
The identity is not a [%s] under this MSP [%s]
What it means
Raised after a successful msp.Validate(id) when msp.hasOURole(id, mspRole.Role) fails: the identity is cryptographically valid under the MSP but does not hold the specific OU-based role (CLIENT, PEER, MEMBER, or ADMIN) demanded by the principal. The message names the missing role and MSP.
Source
Thrown at msp/mspimpl.go:528
return msp.Validate(id)
case m.MSPRole_ADMIN:
mspLogger.Debugf("Checking if identity satisfies ADMIN role for %s", msp.name)
// in the case of admin, we check that the
// id is exactly one of our admins
if msp.isInAdmins(id.(*identity)) {
return nil
}
return errors.New("This identity is not an admin")
case m.MSPRole_CLIENT:
fallthrough
case m.MSPRole_PEER:
mspLogger.Debugf("Checking if identity satisfies role [%s] for %s", m.MSPRole_MSPRoleType_name[int32(mspRole.Role)], msp.name)
if err := msp.Validate(id); err != nil {
return errors.Wrapf(err, "The identity is not valid under this MSP [%s]", msp.name)
}
if err := msp.hasOURole(id, mspRole.Role); err != nil {
return errors.Wrapf(err, "The identity is not a [%s] under this MSP [%s]", m.MSPRole_MSPRoleType_name[int32(mspRole.Role)], msp.name)
}
return nil
default:
return errors.Errorf("invalid MSP role type %d", int32(mspRole.Role))
}
case m.MSPPrincipal_IDENTITY:
// in this case we have to deserialize the principal's identity
// and compare it byte-by-byte with our cert
principalId, err := msp.DeserializeIdentity(principal.Principal)
if err != nil {
return errors.WithMessage(err, "invalid identity principal, not a certificate")
}
if bytes.Equal(id.(*identity).cert.Raw, principalId.(*identity).cert.Raw) {
return principalId.Validate()
}
return errors.New("The identities do not match")View on GitHub (pinned to 2736b63f8f)
Solutions
- Verify the identity certificate's OU matches the required role (decode the cert and check FabricNodeOUs mapping: client, peer, admin, orderer).
- Re-enroll the identity from fabric-ca with the correct type/OU (e.g. --enrollment.profile or proper affiliation/type for peer vs client).
- Align NodeOUs config (Enable: true and OUIdentifiers) in the MSP config with the OUs actually present in issued certificates.
- Or change the policy principal to a role the identity actually holds (e.g. MEMBER instead of CLIENT).
Example fix
// before: client cert used against PEER principal
peerPrincipal := rolePrincipal("Org1MSP", MSPRole_PEER) // evaluated with a client cert
// after: enroll the node as a peer so its OU maps to PEER
fabric-ca-client register --id.name peer1 --id.type peer
fabric-ca-client enroll -u https://ca.example.com:7054 -M msp // cert now carries peer OU Defensive patterns
Strategy: validation
Validate before calling
// verify the certificate's OU maps to the required role before evaluation
def hasRoleOU(certPEM []byte, requiredOU string) bool {
cert, _ := x509.ParseCertificate(pemToDER(certPEM))
for _, ou := range cert.Subject.OrganizationalUnit {
if ou == requiredOU { // e.g. "peer", "client"
return true
}
}
return false
} Type guard
func satisfiesRole(certPEM []byte, role msp.MSPRole_MSPRoleType) bool {
ou := map[int]string{
int(msp.MSPRole_PEER): "peer",
int(msp.MSPRole_CLIENT): "client",
}[int(role)]
return ou != "" && hasRoleOU(certPEM, ou)
} Try / catch
err := policy.Evaluate(id)
if err != nil && strings.Contains(err.Error(), "is not a [") {
return fmt.Errorf("identity lacks required OU role; re-enroll with correct node type or relax the policy: %w", err)
} Prevention
- Set the correct --id.type (peer/client/admin/orderer) when registering identities in fabric-ca.
- Keep NodeOUs Enable + OUIdentifiers consistent across all orgs in the channel.
- Decode issued certs and verify OUs match the roles your policies demand before deployment.
- Use MEMBER principals where any valid identity is acceptable instead of over-constraining to CLIENT/PEER.
When it happens
Trigger: Policy requires MSPRole_CLIENT or MSPRole_PEER (or MEMBER) and NodeOUs/OUIdentifiers classify the identity's OU as a different type — e.g. a client cert evaluated against a PEER principal, or a peer whose certificate lacks the peer OU when FabricNodeOUs is enabled.
Common situations: fabric-ca enrollment without the right OU/type attributes so the cert's OU doesn't map to the required node type; NodeOUs enabled in one org's config but the identity was issued under a different OU structure; mixing legacy admincerts-based MSPs with OU-based role checks; using a peer identity for a client-only policy.
Related errors
- Failed getting local MSP principal during channelless check
- failed verifying that the signed data identity satisfies loc
- MSP Principal role [%s] not recognized
- No principals in CombinedPrincipal
- could not unmarshal MSPRole from principal
AI-assisted analysis of hyperledger/fabric@2736b63f8f (2026-09-04).
Data as JSON: /api/errors/d1816e82fd0e3fce.
Report an issue: GitHub.