Aug 13, 2026
TLDR: You can now bring your own certificate authority to Documenso through CSC 2.0. This is the first real step towards the open signature stack we want to build. Native AES is next, first for self-hosters and later for enterprise customers on Hosted Documenso.
From one certificate to an open signing stack
Documenso currently supports Simple Electronic Signatures, or SES. Like most of the market, this is how the vast majority of documents are signed today.
With SES, Documenso inserts the signature and the final document is cryptographically sealed using the certificate configured on your instance. For most documents, this is exactly what you need.
But there are cases where you want the cryptographic signature itself to be tied to the identity of the person signing.
In Europe, this is where Advanced Electronic Signatures, AES, and Qualified Electronic Signatures, QES, come in. Similar concepts exist around the world under different names and regulatory frameworks.
With AES, the signer is authenticated and their identity becomes part of the cryptographic signature itself. Instead of the document simply being sealed by Documenso, the signature can identify the person who signed it.
QES works in a similar way, but requires certificates issued through regulated trust service providers.
We have talked about AES before. What is new is that we have now built the first piece of infrastructure we need to actually get there.
Bring your own CA
We recently shipped support for CSC 2.0, the Cloud Signature Consortium standard.
CSC gives signing applications like Documenso a standard way to connect to external systems that manage signing certificates.
Until now, a Documenso instance generally had one certificate configured for sealing documents. That is also how Hosted Documenso works today.
With CSC 2.0, you can connect Documenso to your own certificate authority and use certificates generated outside of Documenso for signing.
In other words, you can bring your own CA.
For us, this is more than a standalone feature. It is the first actual implementation of the open signature stack we have been thinking about for a while.
You might want to run your own CA. You might already have one. Or you might need a specific provider because of your industry or jurisdiction. Documenso should work with all of those setups.
The signing application should be one part of the stack, not something that forces you to buy every other part from the same company.
AES is next
CSC gives us the ability to work with external certificate infrastructure, but that alone does not give you a complete AES flow. For that, we also need to connect a verified identity to the certificate and ultimately to the signature.
That is what we are building next.
The PDF part is already mostly solved. libpdf.dev can create and insert these cryptographic signatures today. What we still need for native AES is our own certificate issuance infrastructure around it.
The plan is to add a small certificate service to the Documenso stack. Think of it as an internal CA built specifically for signing.
A signer authenticates, Documenso connects that identity to a certificate, and that identity is included directly in the cryptographic signature.
We want to make this available to self-hosters first. You will be able to run the certificate service alongside your self-hosted Documenso instance and connect it to your identity infrastructure.
This means you won't need a third party certificate service sitting in the middle of every AES signature. If you want to run the whole thing yourself, you can, without paying a third party fee for every signature.
Identity providers and SSO
The other part of AES is establishing who is actually signing.
By default, this can be done through an external identity provider. But companies can also use their existing SSO.
If someone signs into your company through SSO and that account is linked to an employee record, Documenso can use that identity when creating the signature.
Which approach makes sense depends on your requirements. An external identity provider can independently verify someone outside your organization. For employees, your existing SSO might already provide the identity layer you need.
Bringing AES to Hosted Documenso
Once this works well for self-hosters, we want to bring the same infrastructure to Hosted Documenso for enterprise customers.
Instead of running the certificate infrastructure yourself, we will run it for you and connect it either to selected identity providers or your company's SSO.
For now, hosted AES will be focused on enterprise customers. The identity and certificate infrastructure makes sense at that scale. Bringing the same setup to smaller use cases adds a lot of complexity for relatively little benefit, so that isn't something we are focusing on yet.
Towards an open signature stack
CSC 2.0 makes certificate infrastructure interchangeable. libpdf.dev gives us the PDF signing infrastructure. Native AES will add the identity and certificate layer.
Put those pieces together and you start getting something much more interesting than another AES integration.
You start getting an open signature stack.
If you already have infrastructure, you should be able to use it. If you want to run the whole stack yourself, you should be able to do that too. And if you don't want to operate any of it, we can host it for you.
CSC 2.0 is our first concrete step in that direction. AES is next.
If you are interested in running AES on your own infrastructure, need high volume AES signing on Hosted Documenso, or want to add a signing flow on top of your existing CA, talk to us at documen.so/enterprise.
