Aloaha Web Wallet · European Digital Identity Wallet ready

Cloud Signature Consortium v2

Sign a PDF in your browser.

Drop a PDF below. Your signing certificate is minted per user on our server — an EC P-256 leaf enriched from your OIDC profile (CN, given, family, e-mail with SAN rfc822Name) — and the raw PDF stays on your device. Each signature is PAdES-B-T and includes an RFC 3161 timestamp fetched from a trusted TSA. Encrypted PDFs (Standard security handler, RC4-128 or AES-128) can be signed without decrypting. Prior signatures are preserved through incremental save. The preview is rendered client-side by PDF.js — no browser plugin, no third-party PDF viewer. Only the SHA-256 hash of the signed byte-range and the resulting signature bytes are exchanged with our Cloud Signature Consortium (CSC) API v2 endpoint. This is the same architecture the European Digital Identity Wallet ecosystem uses for remote signature, minus the QSCD binding required for a Qualified Electronic Signature (QES).

Sign-in required. A CodeB account is needed before we can mint your signing certificate. New here? Create an account (free, takes a minute, activation e-mail is instant). Already have one? Sign in. Uploading a PDF below will detect a missing session automatically and redirect you into the sign-in flow before returning to this page.
This produces a PAdES-B-T baseline signature (ETSI EN 319 142-1) — a PAdES-B-B envelope plus an RFC 3161 timestamp from a trusted TSA embedded as an unsigned attribute — which is an Advanced Electronic Signature (AdES) per Regulation (EU) 910/2014 Art. 3(11). Trust anchor is a per-user self-signed certificate (AdES only). It is not a Qualified Electronic Signature (QES) — a QES requires a Qualified Signature Creation Device (QSCD) such as the Malta eID card, which is outside the current phase. AdES has legal weight in many jurisdictions but does not automatically equal a handwritten signature under Art. 25(2).

This signature is currently produced by a software-backed cryptographic module (per-user ECDsa P-256 signing certificate keyed on the OIDC subject, private key wrapped with DPAPI at LocalMachine scope). The signer sees only their own credential; user A never sees user B's cert. The Aloaha remote-signing service is designed to accept an HSM substitution as a future upgrade path via the Csc:CryptoModuleProvider configuration key; the CSC v2 API surface and audit trail remain unchanged. Today the shipped provider is software; the hsm-azurekv and hsm-pkcs11 values are reserved for future connectors and currently return crypto_module_not_configured.

1. Pick your PDF

Drop a PDF here

— or —

No file chosen.

2. Your signing certificate

Credential ID— Subject— Issuer—
Serial number— Valid from— Valid to—

3. Sign

Hash to sign (SHA-256, first/last 8 hex)—
PAdES conformance level (ETSI EN 319 142-1)
Open Web Wallet

Waiting for a PDF.

CSC v2 subset live at /csc/v2/… · PAdES assembly in your browser · Full API documentation · Cookbooks · What the Web Wallet is · Sign in with EU Wallet · Privacy

Frequently asked questions

What is the Aloaha Web Wallet PDF signer?

The Aloaha Web Wallet PDF signer (sign.html) signs a PDF in your browser against a Cloud Signature Consortium (CSC) API v2 hash-signing server run by CodeB. The PAdES signature is assembled client-side, the preview is rendered with PDF.js, and each user gets a personal signing certificate minted on the server. No browser plugin or third-party PDF viewer is needed.

What kind of electronic signature does sign.html create?

sign.html creates a PAdES-B-T baseline signature per ETSI EN 319 142-1 by default, which is an Advanced Electronic Signature (AdES) under Regulation (EU) 910/2014 Art. 3(11). The signature includes an RFC 3161 timestamp from a trusted TSA embedded as an unsigned attribute. You can also choose PAdES-B-LT or PAdES-B-LTA.

Is a signature from sign.html a Qualified Electronic Signature (QES)?

No. A signature from sign.html is an Advanced Electronic Signature (AdES) whose trust anchor is a per-user self-signed certificate, not a Qualified Electronic Signature (QES). A QES requires a Qualified Signature Creation Device (QSCD) such as the Malta eID card, which is outside the current phase. AdES has legal weight in many jurisdictions but does not automatically equal a handwritten signature under eIDAS Art. 25(2).

Does sign.html upload my PDF to the server?

No. With sign.html the raw PDF stays on your device. Only the SHA-256 hash of the signed byte range and the resulting signature bytes are exchanged with the CSC API v2 endpoint, and the preview is rendered locally by PDF.js.

Do I need an account to sign a PDF with sign.html?

Yes. A CodeB account is required before a signing certificate can be minted for you. Creating an account is free, takes about a minute and the activation e-mail is sent instantly; if you upload a PDF without a session, sign.html redirects you to sign-in and returns afterwards.

What information is in my signing certificate?

The sign.html signing certificate is a per-user EC P-256 leaf certificate enriched from your OIDC profile. It carries your common name, given name, family name and e-mail address, with the e-mail also included as a SAN rfc822Name. Each user sees only their own credential.

Where is the private signing key kept, and is it in an HSM?

The private key for sign.html is held on the server in a software-backed cryptographic module: a per-user ECDSA P-256 key wrapped with DPAPI at LocalMachine scope. It is not currently in an HSM. The service is designed to accept an HSM substitution later via the Csc:CryptoModuleProvider setting, but the hsm-azurekv and hsm-pkcs11 values are reserved and currently return crypto_module_not_configured.

What is the difference between PAdES-B-T, PAdES-B-LT and PAdES-B-LTA in sign.html?

PAdES-B-T is the default and adds an RFC 3161 signature timestamp to the baseline signature. PAdES-B-LT additionally stores the certificate chain and revocation data (OCSP responses or CRLs) in the PDF's Document Security Store (/DSS), so the signature can be checked offline years later. PAdES-B-LTA adds an archive document timestamp over the B-LT PDF. If the validation data cannot be completed, the PDF is delivered as PAdES-B-T and the log says so. The PDF stays in your browser; the server only supplies certificates and revocation responses.

Can sign.html sign password-protected or encrypted PDFs?

Yes. sign.html can sign encrypted PDFs that use the Standard security handler with RC4-128 or AES-128 without decrypting them. Server-side signing via the CSC v2 signDoc endpoint does not support encrypted PDFs, so the browser flow is the route for those files.

Does signing with sign.html keep earlier signatures on the PDF?

Yes. sign.html preserves prior signatures by writing the new signature as an incremental save, so existing signatures in the document are not overwritten.

Can I add a reason or location to the signature?

Yes. sign.html lets you optionally enter a reason, a location and contact information (e-mail, phone or URL). These values are embedded in the PDF signature (/Sig) dictionary.