Skip to content

Signing Certificate & Regulatory Compliance

GxPSign signs every completed PDF with a cryptographic digital signature using the GxPSign platform root certificate. As an organisation admin, your two responsibilities are:

  1. Understanding what the certificate proves and why it satisfies health authority regulations.
  2. Distributing the certificate to your team so signed PDFs display as trusted in PDF readers.

What the Certificate Proves

When a signature request is completed, GxPSign calculates a SHA-256 hash of the exact document bytes and seals it using the GxPSign root certificate. This creates a permanent, tamper-evident record. If even a single character is altered after signing — whether accidental or deliberate — the hash no longer matches and any PDF reader immediately reports the signature as invalid.

The GxPSign root certificate is embedded inside every signed PDF as part of the PAdES signature structure. This means:

  • The reference certificate is permanently attached to the document — it travels with the file
  • No network connection or GxPSign account is needed to verify a signature
  • Signatures can be verified years later, even without access to GxPSign
  • Auditors, inspectors, and courts have direct access to the reference certificate from the file itself

Regulatory Compliance

Fully compliant for GxP production use

The GxPSign platform root certificate meets all applicable requirements of 21 CFR Part 11 and EU GMP Annex 11. A commercially issued CA certificate is not required for regulatory compliance.

21 CFR Part 11

Requirement Reference How GxPSign satisfies it
Signatures shall be unique to one individual §11.100(a) Each signature field is linked to a verified user identity (email + authentication) recorded in the audit trail
Signatures shall be linked to their respective electronic records §11.70 The PAdES/CMS digital signature cryptographically binds the signer identity and timestamp to the exact document bytes via SHA-256 hash
Signature manifestation shall include name, date/time, and meaning §11.50(b) The visible signature block includes full name, UTC timestamp, and signature meaning; all three are also embedded in the cryptographic signature
Computer-generated, time-stamped audit trails §11.10(e) Immutable audit log records every signing event with user identity, IP address, and UTC timestamp
Records must be protected against unauthorised alteration §11.10© Tamper detection is enforced cryptographically — any post-signature modification invalidates the embedded digital signature

EU GMP Annex 11

Requirement Reference How GxPSign satisfies it
Electronic records must be protected against unauthorised modification Clause 7 SHA-256 cryptographic binding; any post-signature modification invalidates the digital signature
Audit trails must record who did what and when Clause 9 Immutable per-event audit log with user identity, timestamp, and action
Electronic signatures must be equivalent to handwritten signatures Clause 12 PAdES format with visible signature block (name, date, meaning) and cryptographic non-repudiation

Understanding "Untrusted" Warnings

When a user opens a signed PDF and sees a yellow banner such as "The document has been signed but the certificate is not trusted", this is not a statement about whether the document is intact. It simply means the GxPSign root certificate is not yet in the OS trust store on that machine.

What the reader shows What it means
Signature valid, certificate not trusted Document is intact and unaltered; the GxPSign cert needs to be installed locally
Signature invalid Document has been altered after signing — this is the critical failure mode

For regulatory inspections, auditors look at signature validity (has the document been tampered with?), not OS trust status. The certificate embedded in the PDF is all that is needed to make that determination. To eliminate the warning for day-to-day use, distribute the certificate to your team as described below.

Distributing the Certificate to Your Organisation

GxPSign publishes the active platform root certificate at a stable public URL:

https://gxpsign.app/certificates/download/

When users visit this link, their browser downloads gxpsign-signing-cert.crt and the OS prompts them to install it. You can share this link directly or include it in your onboarding instructions.

The certificate policy page shows the current certificate fingerprints — useful for confirming the correct certificate has been installed.

Step-by-step installation

  1. Download the certificate from the link above.
  2. Double-click gxpsign-signing-cert.crt — the Certificate dialog opens.
  3. Click Install Certificate… and select Local Machine, then Next.
  4. Choose Place all certificates in the following store, click Browse, and select Trusted Root Certification Authorities.
  5. Click Next → Finish. Accept the security prompt.
  1. Download the certificate from the link above.
  2. Double-click gxpsign-signing-cert.crt — Keychain Access opens automatically.
  3. Select the System keychain (requires admin password) and click Add.
  4. In Keychain Access, find the GxPSign certificate under Certificates and double-click it.
  5. Expand Trust, set When using this certificate to Always Trust, and close the dialog.
  6. Enter your password to save the change.
sudo cp gxpsign-signing-cert.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

For Chrome: Settings → Privacy and security → Security → Manage certificates → Authorities → Import → select the file and check Trust this certificate for identifying websites.

  1. Go to Edit → Preferences → Signatures → Identities & Trusted Certificates → More…
  2. Select Trusted Certificates in the left panel, then click Import.
  3. Browse to gxpsign-signing-cert.crt and click Open.
  4. Select the certificate, click Trust, check Use this certificate as a trusted root, and click OK.

Enterprise deployment

For organisations with many machines, deploy the certificate centrally rather than asking each user to install it manually:

  • Windows: Distribute via Group Policy (Computer Configuration → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities).
  • macOS: Push a configuration profile (.mobileconfig) via your MDM (Jamf, Kandji, etc.) that includes the certificate in the System keychain.
  • Linux: Include the .crt in your provisioning scripts or configuration management (Ansible, Chef, Puppet) alongside update-ca-certificates.