The certificate identifies the service, not just a hostname.
OpenMesh expects a workload certificate to carry a URI SAN such as spiffe://mesh.example.internal/service/payments. The configured local service name and trust domain are validated against that identity before the runtime begins serving protected traffic.
const payments = openmesh({
service: 'payments',
identity: {
trustDomain: 'mesh.example.internal',
ca,
cert,
key,
allow: ['gateway']
}
});The identity is an application boundary: the Node.js runtime knows which service it claims to be and can reject certificate material that does not match that claim.
Inbound connections must authenticate as trusted workloads.
When workload identity is enabled, the server requires a trusted client certificate. OpenMesh extracts the caller's SPIFFE-style service identity into request state. An optional allow-list can restrict inbound calls to named services such as gateway or billing-worker.
This is service authentication and authorization at the runtime layer. It does not replace business-level user authorization inside the route.
Outbound mesh calls verify the expected destination service.
An outbound app.mesh('payments') call automatically presents the caller's workload certificate when identity is configured. The TLS connection verifies both the trust chain and that the destination certificate identifies the expected service.
That closes an important gap in generic HTTPS: a certificate signed by the right CA is not enough if the connection reached the wrong workload.
Rotate certificate material without restarting the process.
app.workload.rotate(...) can replace already-issued workload certificate material. New inbound connections use the replaced server secure context; outbound service pools rotate their TLS agents and can drain old agents with a grace period.
Rotation is deliberately separate from issuance. OpenMesh consumes certificate material; it does not run a certificate authority or decide how revocation is distributed.
Know what the runtime does not claim.
- It does not issue workload certificates.
- It does not distribute certificate revocation state.
- It does not govern a trust domain for you.
- It does not transparently intercept arbitrary process traffic.
- It does not replace Kubernetes network policy or a CNI.
The model is useful when Node.js applications want explicit service identities and mTLS inside the same runtime that owns service-to-service calls. See the workload identity reference for the exact supported configuration.