Sealing in calServer: which seal belongs on which certificate¶
18 August 2026
A calibration certificate as a PDF tells the recipient nothing about whether it really came from the laboratory whose letterhead sits at the top. The scanned signature on it is an image and can be swapped out. That is why calServer seals the released certificate: the file is bound cryptographically to a certificate of the laboratory, and any common PDF viewer then shows who sealed it and whether a single byte has changed since.
The seal is invisible. It is an assurance about the whole document, not a stamp on one page. An image stamped on afterwards would rewrite the file and destroy the very signature it is meant to depict.
Four kinds, not one¶
A laboratory rarely needs just one seal. calServer therefore distinguishes what a certificate is for, and the kind is recorded on the credential:
| Kind | What it states | Typical use |
|---|---|---|
| Company seal | The document came from this laboratory. It says nothing about an accreditation. | Factory calibration certificates, test records, reports to customers |
| Accreditation seal | The laboratory signs the certificate under its accreditation. | The accredited calibration certificate, and nothing else |
| Personal signature | A named person has signed. | When a person signs rather than the laboratory |
| In-house PKI | The certificate comes from the company's own certification authority. | In-house labs whose recipients sit in the same group |
Whether this produces a seal or a signature is not a checkbox: calServer reads the holder from the certificate. If it belongs to a legal person, that is the laboratory, it is a seal. If it belongs to a natural person, it is a signature. Both are permitted; the interface simply names them correctly.
The DAkkS seal is not a separate case in this list but an accreditation seal
carrying a German accreditation number. That number, for example
D-K-12345-01-00, goes into the certificate as organizationIdentifier
(OID 2.5.4.97 per EN 319 412-1), which is where the tools used in an assessment
look for it. Nothing in the system is DAkkS-specific. A laboratory accredited in
another country puts its number in the same place and gets the same behaviour.
Four routes to a certificate¶
All four end up as an entry in the same list. They differ in where the private key comes into existence and what a recipient can take from the seal.
| Route | Where the key is created | What the recipient sees |
|---|---|---|
| Generate it yourself | in the sealing service | "validity unknown": proves the file is unchanged, not where it came from |
| Have a certification authority issue it | in the sealing service, never leaves it | origin proven, issuer visible |
| Import an existing key file | outside, travels in once as a file | as much as the purchased certificate provides |
| Remote signing at a trust service provider | at the provider, on its signature creation device | the only setup in which a seal can be qualified |
For an accreditation seal the second route is the usual one. calServer creates the key in the sealing service and hands out a certificate request; the certification authority signs it, the certificate is installed, the key stays the same and has never left the installation. It takes as many days as the certification authority needs, and it is the only route on which no key material travels over a wire.
What a seal is worth is likewise decided by the certificate, not by a checkbox. calServer reads the level: self-declared, issued by a CA, qualified certificate or qualified. "Qualified" is a legal term, and a box to tick would not be a statement about it but a claim. A seal can only be qualified if the key is not a file on the server, which means remote signing.
Separate from that is what the document carries with it. PAdES-B-B names who sealed. B-T adds when, with a third-party timestamp per RFC 3161. B-LT puts the chain and the revocation information into the document as well, so the seal is still verifiable years later, long after the certificate has expired. The level is a property of the credential, not of the system.
Which seal may go on which certificate¶
The mistake that costs a laboratory dearly is not the missing seal. It is the wrong one: the accreditation seal on a factory certificate.
calServer handles this with an ordered list of rules. Each rule assigns a credential and carries conditions: report type, customer, role and group of the person deciding. Anything left empty means "does not matter". The first matching rule wins. A rule with no condition at all is the fallback.
Two properties turn this into control rather than decoration. As long as no active rule exists, nothing changes; a laboratory with a single company seal does not have to write a rule in order to seal. But as soon as one active rule exists, the choice is bound, and no credential can be picked by hand that no rule permits. The middle ground, rules as a suggestion with free manual choice next to it, would look like control and be none.
Rejections come with two different reasons, because they mean different things to the user. Either no rule fits this certificate at all, in which case no other credential helps. Or the chosen one is not permitted, in which case the answer names what would be allowed instead.
Automatic sealing is configured per rule, not with a global switch. A laboratory can have the company seal applied by itself after release and hand out the accreditation seal deliberately. The run does not sit inside the release but follows it as a separate job: if the sealing service is down, the release remains valid, and the missing seal is visible in the state instead of passing silently.
A certificate can also carry two seals, company seal and accreditation seal together. The second one signs the bytes of the first rather than the original, otherwise there would be two statements about two different states of the document. The same credential a second time is rejected; that would be the same statement twice.
What gets sealed is what was released¶
The seal is part of the release process. On submission the certificate is produced once, filed in the DMS and frozen, and its checksum sits on the process from then on. Sealing happens only after release, and beforehand calServer checks that the file is still the same one. If the checksum differs, no seal is created: it would otherwise vouch for something the approver never saw.
The sealed document is added as a new version, the released one stays untouched. The record keeps both sides, the released bytes and the sealed ones, plus a snapshot of the certificate and the signature format. After a certificate has been replaced it is still possible to say what was sealed with what.
Failed attempts stay in the log with their reason. One case is called out explicitly: if a trust service provider does not answer, it is not established whether a signature was created. calServer reports this as unclear and advises against retrying until the provider has been checked, because a second run would otherwise produce a second signature over the same document, and usually a second invoice.
Where the limits are¶
A self-signed seal is created in seconds and looks like a seal in the list. Every PDF viewer shows "validity unknown" for it, because nobody vouches for the certificate except the laboratory itself. For trying things out and for internal use that is right; for a certificate going to a customer it is not.
The rule checks the scope of accreditation at the level of the report type: this report is the accredited calibration certificate, and only it may carry the mark. Whether a specific measurand lies within the accredited scope is not checked, because the data model for that does not exist. When a rule assigns an accreditation seal, the release therefore requires an explicit declaration by the deciding person; the wording and the person are then in the log. That is less than an automatic check promises and more than an automatic check could currently keep.
calServer creates signatures, it does not verify them. Whether a seal is valid is decided by whoever views the document, and the recipient's PDF reader is enough for that.
The private key sits as a file with the sealing service of your own installation, not in the database. That keeps it out of every database dump and every backup, but it moves care into operations: the keystore password belongs in the password manager, because without it existing credentials are lost, from a backup as well.
Sealing is an optional module. Without it the release process runs unchanged, the credential list stays empty, and the process is complete with the decision.
Setup and operation: Setting up seals. The process at the calibration certificate: Releasing a calibration certificate.