How it works
What happens when you upload a file
A technical validation performed with the European Commission's DSS library, explained step by step.
Step by step
- We identify the format. ASiC-E or ASiC-S container, S/MIME message (.eml), XML evidence, signed PDF or CMS (.p7m). Inside an email we look for attachments carrying evidence and containers.
- We open the container. We list the files, compute each file's SHA-256 fingerprint, and identify the original message and the ETSI EN 319 522 evidence (event, date and time, sender, recipient, message identifier).
- We validate signatures and seals. DSS checks every XAdES, CAdES or PAdES signature: cryptographic integrity, that each file matches what was signed, the certificate chain, revocation (OCSP/CRL) and time stamps.
- We check the EU trusted lists. DSS validates certificates against the List of Trusted Lists (LOTL) and the trusted lists of the EU and EEA Member States, and determines the level: qualified seal (QESeal), qualified signature (QESig) or advanced.
- We relate the seal to the registered delivery service. We check whether the certificate that sealed the evidence belongs to a qualified electronic registered delivery service in the trusted lists.
- We compare with the email you received (if you upload it): message identifier, content and headers.
- We discard everything. Files are never written to disk and cease to exist once the response is sent.
What is an ASiC container
ASiC (Associated Signature Containers) is the European format standardised by ETSI EN 319 162 to bundle documents and the signatures covering them in a ZIP file:
| Type | Extensions | Content |
|---|---|---|
| ASiC-S (simple) | .asics, .scs | A single file and its signature or time stamp |
| ASiC-E (extended) | .asice, .sce | Several files — e.g. the email and the evidence — and one or more signatures |
Inside the ZIP, the mimetype file declares the type (application/vnd.etsi.asic-e+zip or …asic-s+zip) and the META-INF/ folder holds the signatures: signatures*.xml (XAdES), signature*.p7s (CAdES), time stamps (*.tst), manifests and evidence records.
Reading the result
| Result | Meaning |
|---|---|
| Valid qualified registered delivery | A valid, intact electronic seal (advanced or qualified) from a qualified registered delivery service listed in the EU, with delivery evidence and date and time proven by a qualified time stamp (Art. 44(1)(a), (d) and (f)). Sender and recipient need no qualified certificates. |
| Valid signature/seal | The content was not altered and the certificate is recognised, but it was not shown to come from a qualified registered delivery service — see the details. |
| Could not be confirmed | The signature may be correct but something is missing to confirm it: certificate outside the EU trusted lists, revocation information unavailable, expired certificate without a time stamp… |
| Content altered | At least one file does not match what was sealed. The evidence cannot be relied on. |
| Invalid | The signature was rejected — for example, the certificate was revoked before signing. |
Limitations
- We are not a qualified validation service (Articles 33 and 40 of eIDAS). The result is for information. For legal proceedings, ask the registered delivery provider for its validation or use a qualified validation service.
- Validation depends on the trusted lists and the certificate authorities' revocation services being reachable at that moment.
- Some providers use proprietary evidence formats instead of the ETSI format. We still validate the signature, but may not be able to show the evidence fields.
- The email you received passed through servers that add headers, so we compare the identifier and the content, not just the file's fingerprint.
Frequently asked questions
Are my files stored?
No. They are processed in memory and discarded with the response. Nothing logs the content, names or metadata of your documents. See the privacy policy.
Can I use this report in court?
You can print it as support, but it does not replace the provider's evidence or a qualified validation service. The proof is the sealed evidence itself — this site helps you see whether it is intact and who it comes from.
The result says “Could not be confirmed”. Why?
The most common causes: the certificate was issued by an entity that is not on the EU trusted lists (or is a test certificate); revocation information could not be obtained; or the certificate has expired and the signature has no time stamp proving it was made earlier. The technical details at the end of the report give the exact cause.
What technology do you use?
DSS (Digital Signature Service) 6.5, an open-source library (LGPL-2.1) maintained by the European Commission — the one behind the Commission's demo validator — running on our own servers, without sending your files to third parties.
Is a normal email with DKIM or a personal S/MIME signature a registered delivery?
No. They prove where the email came from, but provide no evidence of delivery and receipt issued by a trust service provider.