A definition of qualified and advanced seals can be found on this page https://europa.eu/europass/en/how-issue-european-digital-credentials at the section "Advanced or Qualified eSeal"

A more detailed specification of these two types of seals can be found at https://web.archive.org/web/20180115001229/http:/eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2014.257.01.0073.01.ENG at the section "Languages, formats and link to OJ", by clicking at the item on the row PDF and column EN (English).

Having defined what a qualified / advanced seal means (at least, in the view of the europass platform), my question is: what file formats can such a seal have, once installed on the computer (in the Windows keystore) ?

Given a type of a seal (qualified or advanced), is it constrained to have a particular extension, or it can take any of the acceptable extensions for an electronic certificate ?

I am totally new to the electronic certificates. Right now I am about to purchase one, and I need to make sure that it is compatible with a particular remote signature tool (Nowina's NexU - https://github.com/nowina-solutions/nexu/releases/download/nexu-1.22/nexu-bundle-1.22.zip ; clicking this link will start downloading a zip file)

1 Answer 1


First things first: File extensions mean literally nothing (except for what program the shell will default to trying to invoke if you double-click them). They are at best conventions for indicating the format of a file, but they certainly don't determine it. They're just part of the file name, a simple string that could be anything and has no inherent meaning.

Furthermore, the file extension something has "once installed on the computer (in the Windows keystore)" is a meaningless concept; the keystore doesn't store files at all (though you can export certificates and/or keys from it, in several formats some of which have a range of common file extensions).

Finally, the keystore isn't going to store "seals" at all. Going by links you provided (thanks for that), the "seals" are a combination of cryptographically signed data, the corresponding cryptographic signature, and some metadata (e.g. the date the signature was made, the certificate corresponding to the signer's private key, etc.) which is itself signed. The keystore doesn't hold things like that; it holds the keys used to generate the signatures needed for creating (and the certificates for verifying) such a seal.

Such seals are a concept that exists at a completely different level than file formats (which indicate a layout of binary data); one could in theory structure the layout of a seal in many different ways. A lot of those ways wouldn't even necessarily be a single file. Certainly the documentation about what constitutes a seal (of various degrees) doesn't seem concerned with the exact instantiation of one, only what it must represent.

The Nowina tool expects requests as either RESTful GET requests with the data in query parameters, or as JSON-serialized Java objects in a POST body. However, the tool only implements a few basic operations: listing certificates, creating and verifying signatures, and getting identity from one. All of which suggests that a "seal" is either in practice a looser data structure than you think (a collection of data, such as the original signed data, the signature, and the signer's certificate, all in no particular format), or that some front-end code is required to parse the formatted structure of a seal before it can be sent to the Nowina tool (and verify that the results match expectations).

Note that there's no single standard structure (much less extension) for digital signatures and their metadata in general. They might be embedded in a file, or might be detached; they might be in binary (e.g. DER-encoded) or base64-encoded representation, they might have a canonical layout (they must, if multiple pieces of data are to be concatenated in some way) or not... Some examples of signed data formats include various MIME formats for secure email, "Authenticode" signatures on Windows binaries, OpenPGP messages, X.509 certificates, JSON web signatures (and the closely-related JSON web tokens a.k.a. JWTs), signed PDFs and MS Office documents... All of these structure themselves differently, and have different common file extensions (sometimes multiple per data type, e.g. .exe/.dll/.sys/.scr are all the same file format that can have embedded signatures but can also have detached signatures in .cat files) or are not typically stored in a file at all.

All of which is arguably beside the point: if you have something that purports to be a seal, from a vendor of such things, made using data that you supplied them, it's probably valid. You can feed it into the web interface at https://europa.eu/europass/digital-credentials/issuer/#/home to test it, apparently (requires the Nowina software running locally; I strongly advise against leaving it running as it may expose your signing keys to malicious use). Presumably that page knows how to take a seal as input and feed it to the Nowina software usefully.

  • thanks for pointing out against leaving NexU running; I did not realize it can expose me to risks Jan 11 at 8:31
  • meanwhile, I found that the product suitable for me is named "Qcert for Eseal ", as opposed to a simple "eSig"; (this terminology might be specific to the europass platform) when I said "seal" I meant in fact the "certificate for e-seal"; Jan 11 at 8:41
  • one more thing to clarify: its NexU that sits between the browser app and the certificates i have installed locally, not the browser that stands between NexU and the certificates. I have been explained the reason for NexU's existance (which is a remote signature tool) : for security reasons, a web app cannot directly load resources from my PC (including certificates), therefore it need NexU as an intermediate Jan 11 at 9:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .