starred/documenso

Fork 0

mirror of https://github.com/documenso/documenso.git synced 2026-04-24 21:36:01 +03:00

[GH-ISSUE #2426] After upgrading Documenso from v2.4.0 to v2.5.0, document sealing/signing using Google Cloud KMS (HSM) stopped working. #681

New issue

Open

opened 2026-02-26 18:48:02 +03:00 by kerem · 3 comments

kerem commented

2026-02-26 18:48:02 +03:00

Owner

Originally created by @Dailson-Allves on GitHub (Jan 28, 2026).
Original GitHub issue: https://github.com/documenso/documenso/issues/2426

Issue Description

The same configuration works correctly on v2.4.0.
Rolling back to v2.4.0 immediately restores functionality.

Environment:

Documenso: 2.5.0 (broken), 2.4.0 (working)
Signing transport: Google Cloud KMS (HSM)
KMS key: Asymmetric signing key (HSM)
Auth method: GOOGLE_APPLICATION_CREDENTIALS (service account JSON)
Runtime: Docker Compose

Error observed:
KmsSignerError: KMS: Permission denied for key
Permission 'cloudkms.cryptoKeyVersions.get' denied
Permission 'cloudkms.cryptoKeyVersions.useToSign' denied

Important:

The service account has the correct IAM role applied directly to the CryptoKey:
roles/cloudkms.cryptoKeySignerVerifier
IAM was double-checked and validated
The same service account and key work without any issue on v2.4.0

Expected Behavior

Google Cloud KMS signing should work as in v2.4.0

Current Behavior

Signing fails with PERMISSION_DENIED even with correct IAM

Please check the boxes that apply to this issue report.

I have searched the existing issues to make sure this is not a duplicate.
I have provided steps to reproduce the issue.
I have included relevant environment information.
I have included any relevant screenshots.
I understand that this is a voluntary contribution and that there is no guarantee of resolution.
I want to work on creating a PR for this issue if approved

Originally created by @Dailson-Allves on GitHub (Jan 28, 2026). Original GitHub issue: https://github.com/documenso/documenso/issues/2426 ### Issue Description The same configuration works correctly on v2.4.0. Rolling back to v2.4.0 immediately restores functionality. Environment: - Documenso: 2.5.0 (broken), 2.4.0 (working) - Signing transport: Google Cloud KMS (HSM) - KMS key: Asymmetric signing key (HSM) - Auth method: GOOGLE_APPLICATION_CREDENTIALS (service account JSON) - Runtime: Docker Compose Error observed: KmsSignerError: KMS: Permission denied for key Permission 'cloudkms.cryptoKeyVersions.get' denied Permission 'cloudkms.cryptoKeyVersions.useToSign' denied Important: - The service account has the correct IAM role applied directly to the CryptoKey: roles/cloudkms.cryptoKeySignerVerifier - IAM was double-checked and validated - The same service account and key work without any issue on v2.4.0 ### Expected Behavior Google Cloud KMS signing should work as in v2.4.0 ### Current Behavior Signing fails with PERMISSION_DENIED even with correct IAM ### Please check the boxes that apply to this issue report. - [x] I have searched the existing issues to make sure this is not a duplicate. - [x] I have provided steps to reproduce the issue. - [x] I have included relevant environment information. - [x] I have included any relevant screenshots. - [x] I understand that this is a voluntary contribution and that there is no guarantee of resolution. - [ ] I want to work on creating a PR for this issue if approved

kerem added the

status: triage

label

2026-02-26 18:48:02 +03:00

kerem commented

2026-02-26 18:48:02 +03:00

Author

Owner

@Mythie commented on GitHub (Jan 28, 2026):

Hey there,

This should just continue to work, we had swapped signing libraries from @documenso/pdf-sign to @libpdf/core but retained the same env vars etc for doing this.

One thing that tripped me up with google was that the given crypto key had to be associated with the service account even if the service account has the role attached. I swear I never used to have to do this though, so it may be a difference between the Rust libraries Google SDK vs the native Node.js SDK.

@Mythie commented on GitHub (Jan 28, 2026): Hey there, This should just continue to work, we had swapped signing libraries from `@documenso/pdf-sign` to `@libpdf/core` but retained the same env vars etc for doing this. One thing that tripped me up with google was that the given crypto key had to be associated with the service account even if the service account has the role attached. I swear I never used to have to do this though, so it may be a difference between the Rust libraries Google SDK vs the native Node.js SDK.

kerem commented

2026-02-26 18:48:02 +03:00

Author

Owner

@Dailson-Allves commented on GitHub (Feb 1, 2026):

@Mythie

Yes that was our initial suspicion too (key-level binding vs project-level IAM), so we validated it thoroughly.

We confirmed:

The service account is explicitly granted Signer/Verifier on the CryptoKey (key-level IAM).
The Documenso container is using the intended service account JSON via GOOGLE_APPLICATION_CREDENTIALS.

To rule out GCP/IAM and “Rust vs Node SDK” differences, we ran a direct signing call
from inside the same Documenso v2.6.0 container, bypassing Documenso/libpdf entirely,
using the official Node.js KMS SDK (@google-cloud/kms) and asymmetricSign().

Result from inside the container:
KMS SIGN OK 256

So from the same runtime + same credentials, the Node SDK can sign successfully,
yet Documenso’s sealing job still fails with:

cloudkms.cryptoKeyVersions.get denied
cloudkms.cryptoKeyVersions.useToSign denied

Given that 2.4.0 works and 2.5.0+ fails, this strongly points to an issue in the
Documenso/libpdf signing path (resource naming / permission check / client init),
not an IAM or SDK access issue.

@Dailson-Allves commented on GitHub (Feb 1, 2026): @Mythie Yes that was our initial suspicion too (key-level binding vs project-level IAM), so we validated it thoroughly. We confirmed: - The service account is explicitly granted Signer/Verifier on the CryptoKey (key-level IAM). - The Documenso container is using the intended service account JSON via GOOGLE_APPLICATION_CREDENTIALS. To rule out GCP/IAM and “Rust vs Node SDK” differences, we ran a direct signing call from inside the same Documenso v2.6.0 container, bypassing Documenso/libpdf entirely, using the official Node.js KMS SDK (`@google-cloud/kms`) and `asymmetricSign()`. Result from inside the container: `KMS SIGN OK 256` So from the same runtime + same credentials, the Node SDK can sign successfully, yet Documenso’s sealing job still fails with: - `cloudkms.cryptoKeyVersions.get` denied - `cloudkms.cryptoKeyVersions.useToSign` denied Given that 2.4.0 works and 2.5.0+ fails, this strongly points to an issue in the Documenso/libpdf signing path (resource naming / permission check / client init), not an IAM or SDK access issue.

kerem commented

2026-02-26 18:48:02 +03:00

Author

Owner

@Dailson-Allves commented on GitHub (Feb 8, 2026):

@Mythie , is there anything I can do to help resolve this? I understand this is a very critical point.

@Dailson-Allves commented on GitHub (Feb 8, 2026): @Mythie , is there anything I can do to help resolve this? I understand this is a very critical point.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/documenso#681

No description provided.

Rows
Columns