This page provides background on document-signing certificates: what they are, how they differ from code-signing certificates, which extended key usages Signotaur accepts, and where the certificates can live on the server.
For the administrative interface used to register and manage certificates, see Signing Certificates. To actually sign a document, see Signing Documents.
Registering a document-signing certificate, issuing one, and signing with one all require an Enterprise licence: the same licence that unlocks the Managed CA features. Code signing works under a Standard licence, but document signing does not.
Without one:
A certificate that can do both code signing and document signing stays usable for code signing throughout. See Editions & Licensing.
A document-signing certificate is an X.509 certificate issued for digitally signing documents (PDFs, Microsoft Office files, and XML) rather than executable software. A valid signature lets a viewer such as Adobe Acrobat or Microsoft Office confirm who signed the document and that its contents have not changed since signing.
Where a code-signing certificate carries the Code Signing extended key usage, a document-signing certificate carries one or more document-signing extended key usages. The relevant OIDs are:
| Extended Key Usage | OID | Used by |
|---|---|---|
| Microsoft Document Signing | 1.3.6.1.4.1.311.10.3.12 |
Microsoft Office |
| Adobe Authentic Documents | 1.2.840.113583.1.1.5 |
Adobe Acrobat / Reader |
| Document Signing (RFC 9336) | 1.3.6.1.5.5.7.3.36 |
The standards-track, vendor-neutral document-signing EKU |
When Signotaur issues a document-signing certificate (from the Internal CA), it includes all three of these EKUs plus the Digital Signature and Non-Repudiation key usages, so the certificate is accepted by the widest range of document viewers.
Signotaur accepts a document-signing certificate from any issuer, provided the certificate:
1.3.6.1.5.5.7.3.4), or the Any Purpose usage. A certificate with no EKU extension at all also qualifies, provided its key usage includes Digital Signature or Non-Repudiation.Two common shapes are accepted even though they carry none of the three OIDs above.
Email Protection was the usual way to mark a document-signing certificate for years before RFC 9336 defined a dedicated usage, and it remains one of the usages Adobe Acrobat accepts from a signer. Many personal certificates carry it instead of a document-signing usage, or alongside one.
Many European qualified certificates carry no extended key usage at all and set only the Non-Repudiation key usage. ETSI EN 319 412-2 recommends exactly that for certificates used to sign documents, so Signotaur accepts it.
Certificates that Signotaur issues itself take neither shape: they always carry the document-signing usages.
A document signature only shows as trusted when the signing certificate chains to a root the viewer trusts. Adobe Acrobat trusts certificates on the Adobe Approved Trust List (AATL) or roots you add to Acrobat's Trusted Identities; Office uses the Windows trust store. A certificate issued by Signotaur's Internal CA is suited to internal document signing, where that CA root can be distributed to the machines that need to verify the signatures. It is not a substitute for an AATL-enrolled certificate when distributing signed documents publicly.
Note that a trusted certificate is not the same as a qualified one. Buying from a publicly trusted CA changes how viewers display the signature; it does not confer qualified status under eIDAS. See Trust and Qualified Status.
The public-key algorithms Signotaur recognises in document-signing certificates are the same as for code signing: only RSA (2048, 3072, 4096) and ECDSA (NIST P-256, P-384, P-521) are supported. DSA and ECDH are rejected at registration. Supported file digest algorithms are SHA-256, SHA-384, and SHA-512.
Unlike code signing, document signing has no RSA-only constraints: the AdES document formats (PAdES, CAdES, XAdES) sign with RSA or ECDSA. As with any signing key, RSA 3072 or larger is a good general choice; see the key-size guidance on the Code Signing Certificates page.
Signotaur supports the same three sources for document-signing certificates as for code signing, each accessible via its own tab in the Add New Certificate dialog:
In addition to registering certificates obtained elsewhere, Signotaur can issue document-signing certificates itself, using its Internal CA or an external ADCS CA. Issue and manage them from the Managed Certificates admin page, choosing Document signing as the purpose in the Issue dialog.
Issued certificates are renewed automatically before they expire, on the same schedule as code-signing certificates. Without an Enterprise licence, renewal of managed document-signing certificates is paused and they are allowed to lapse, resuming automatically when the licence is restored.
The Issue from Internal CA dialog offers Strict EKU (id-kp-documentSigning only) on its Certificate tab. Ticking it stamps only the standards-track RFC 9336 usage, 1.3.6.1.5.5.7.3.36, instead of the Microsoft, Adobe and RFC set.
Leave it off unless you have a reason to narrow the certificate. The full set is accepted by the widest range of viewers.
The usages Adobe documents as acceptable on a signer's certificate are Email Protection, Code Signing, Any Purpose and its own Adobe Authentic Documents OID. RFC 9336's 1.3.6.1.5.5.7.3.36 is not among them. A certificate carrying the strict usage on its own may therefore be refused by Acrobat, not only by older versions of it. Use strict EKU only where you know the verifying software recognises RFC 9336.
It applies to the Internal CA only, as an ADCS certificate's extended key usage comes from its template.
Certificates issued by the Internal CA can carry more than a common name. Both are optional, and both are covered in detail elsewhere:
A certificate policy is your organisation's own claim. Certificates issued by the Internal CA are self-asserted: they are not qualified (eIDAS QES) certificates, they carry no external audit, and no public trust list includes them.
Once a document-signing certificate is registered and assigned, the SignotaurTool client signs PDF, XML and other documents with it using the AdES formats. The private key never leaves the server.
At sign time the client checks the certificate again, against what is actually being signed. For a document format the accepted usages are the same as at registration above, so a certificate that registered successfully will sign a document.
Signing also requires the certificate's Key Usage extension to permit Digital Signature or Non-Repudiation. A key that permits neither is not authorised to produce a signature at all, whatever its extended key usage claims, so it is refused for documents and code alike. A certificate with no Key Usage extension is unrestricted.
The one difference concerns code. A certificate with no EKU extension whose key usage is Non-Repudiation without Digital Signature is the ETSI document-signing profile described above: it signs documents, but it is refused for code formats, where its key is not authorised to sign.
If the certificate carries an EKU extension with none of the accepted usages, nothing is signed. The error names the usages the certificate does carry, so you can see what you have. To sign anyway, pass --warn-wrong-purpose, which turns the refusal into a warning.
See Signing Documents and the sign command.