How to Open a P7M File or an .asice Container Your Computer Rejects

Somebody emailed you a file called contract.pdf.p7m or agreement.asice, and nothing on your machine will touch it. Double-clicking does nothing useful, or Windows helpfully offers to go looking in the store for an app that doesn't exist. You can't open a P7M file with a PDF reader, and no amount of double-clicking is going to change that. Here's the short version, then the explanation.

Both files are containers. Something perfectly ordinary is sealed inside, usually a PDF, an XML invoice or a Word document, along with a digital signature wrapped around it. So you've got two separate jobs: get the document out, and find out whether the signature is worth anything. Most people only think about the first one.

Route the file by its extension

Look at what the name ends with. That one detail decides everything that follows.

• Ends in .p7m or .p7s? It's a CMS envelope carrying a CAdES signature. Take it to CAdES verification.
• Ends in .asice, .sce, .asics or .scs? That's an ASiC container, and ASiC verification reads all four. It also accepts a plain .zip, which covers files that lost their extension somewhere in transit.
• Ends in .bdoc? Same container as .asice under an older Estonian name. Rename a copy to .asice or .zip before uploading, because the upload filter matches on extension rather than on what's inside.
• Not sure what you're holding, or the name has two extensions stacked up? Signature verification takes every format through one form and works it out itself.

Files up to 50 MB go through. You confirm your email address with a one-time code before the report comes back, and the file you upload isn't stored afterwards.

Right. Now the part that explains why any of this is necessary.

A .p7m isn't a document. It's a sealed box with a document inside it.

The format is Cryptographic Message Syntax, CMS for short, defined in RFC 5652 and descended from PKCS#7. That ancestry is why older tools still call these PKCS#7 files. When someone signs this way, the signing software hashes the original bytes, encrypts that hash with a private key, and packs the document, the signature and the signer's certificate into a single binary blob. Then it bolts .p7m onto the end of the original filename.

Which is why you see names like contract.pdf.p7m and Fattura_0187.xml.p7m. The inner extension tells you what's sealed inside. The outer one tells you it's sealed.

CAdES is the layer built on top. Short for CMS Advanced Electronic Signatures and standardised as ETSI EN 319 122, it adds what a bare CMS signature lacks: signing time, signature policy, timestamps, and the certificate and revocation data you'll need to check the thing years from now.

Geography explains most .p7m sightings. Italy's firma digitale leans on CAdES heavily, so anything arriving from an Italian public administration portal, a PEC certified email, or a FatturaPA e-invoice tends to be wrapped this way. Spain, Portugal and parts of Latin America use it too, just less relentlessly. If one of your suppliers is in Milan, you'll be seeing .p7m files for the rest of your working life.

An .asice file is a ZIP file that follows rules.

That isn't a joke, and it's the single most useful fact about the format. ASiC stands for Associated Signature Container, specified in ETSI EN 319 162. Inside sits an ordinary ZIP archive holding your documents, a META-INF folder with the signature files, and a manifest describing what's what. Rename a copy to .zip, open it with any archive tool, and the documents are simply there.

Two flavours exist. ASiC-S carries exactly one data object and turns up as .asics or .scs; ASiC-E carries several plus a manifest and turns up as .asice or .sce. Most files you'll meet in practice are ASiC-E.

Then there's .bdoc, which trips people up more than it should. Estonia's DigiDoc software wrote ASiC-E containers under that name for years, and structurally it's the same container. A validator that reads .asice will read the bytes of a .bdoc perfectly well. But upload filters match on file extension, not on content, so a .bdoc gets bounced before anything looks inside. Rename a copy to .asice or .zip and it goes straight through.

Baltic eID is why these land in your inbox at all. Estonia's ID-card, e-Residency and Smart-ID all produce .asice containers, and Latvia and Lithuania run on the same DigiDoc lineage. Sign a contract with an Estonian company and this is what comes back. Nordic and Central European systems use ASiC as well, though less exclusively.

Nothing is broken. Your operating system just has no idea what these are.

Windows, macOS and Linux all choose an application by file extension or MIME type. Neither .p7m nor .asice ships with a default handler on a consumer machine, because neither is a consumer format. They come out of national eID systems and business signing software, and the people who need them daily install dedicated tools.

Browsers behave the same way and add an annoyance of their own. Download a .p7m from a web portal and Chrome or Safari may quietly rename it, strip the extension, or hand it over with a MIME type that makes your mail client re-encode the attachment. Any of that can alter the bytes, which is precisely what a signature is built to notice.

There's a second reason specific to .p7m. Even once you know what the format is, the document inside isn't sitting at the top of the file where a reader could stumble across it. It's embedded in an ASN.1 DER structure alongside the signature and the certificate. Getting it out takes software that understands that structure, not a PDF viewer being asked nicely.

If it's an ASiC container, unzip it

Copy the file, rename the copy to .zip, and open it with Windows Explorer, macOS Archive Utility, 7-Zip, or unzip on the command line. Your documents are in the root of the archive. The signatures are in META-INF.

That's genuinely all there is to it, which tends to annoy people who've just spent an hour hunting for special software.

If it's a .p7m, you need something that understands CMS

No renaming trick here. On macOS or Linux with OpenSSL installed, this pulls the document out:

The -noverify flag skips trust checking, because right now you only want the payload. Drop it and OpenSSL will also try to validate the certificate chain, which usually fails against a European national certificate authority your system has never heard of. That failure says nothing at all about whether the signature is really valid, and it's exactly where most people conclude something is wrong when nothing is.

One practical note: if the command errors out on the input format, swap -inform DER for -inform PEM. A minority of .p7m files are PEM-encoded rather than binary DER. Don't just drop the flag: OpenSSL then assumes S/MIME and fails with a confusing content-type error.

Desktop readers are the other route. Estonia's DigiDoc4 client handles ASiC containers and reads .p7m files too, and Italian certificate authorities ship free readers for firma digitale files. Both work well. Both also assume you already live inside that country's ecosystem, which is a poor fit when one Italian invoice a quarter is your entire exposure to the format.

One thing these tools don't do

Worth being clear about, because it saves you a wasted afternoon. Chaindoc's verification tools check signatures: they report on the signatures inside the file, who signed it, and whether the result holds up. They aren't a file extractor. If what you actually need is the PDF itself, unzip the container or run the OpenSSL command above. Verification and extraction are separate jobs and it's worth keeping them separate in your head.

Two files that look nearly identical can behave completely differently, and this is the point where people give up.

An enveloping signature carries the document inside it. A .p7m is the everyday example: one file, self-contained, checkable on its own. ASiC containers are self-contained for the same reason, since the documents and their signatures travel together in the same ZIP.

A detached signature holds no document whatsoever. It's the signature and the certificate and nothing else. .p7s is the common CAdES version, and the same pattern shows up as a detached .xml or .xsig on the XAdES side. Upload one on its own and the validator has a signature with nothing to compare it against, so you get an indeterminate result. It reads like a failure. It isn't one.

The fix is to hand over both files. On Chaindoc's forms, selecting a detached-capable file (.p7s, .xml or .xsig) reveals a second field for the signed document. Attach the original there and the digest can finally be recomputed and compared.

One warning about that original. It has to be the exact bytes that were signed, not a copy that's been through a document management system, been re-saved, or been reflowed by an email gateway. A single changed byte breaks the hash. So when a detached signature fails, suspect your copy of the document before you suspect the signature.

Searching for a p7m viewer turns up three kinds of answer, and they are not equally good.

National eID clients

DigiDoc4 in Estonia, and the free readers Italian certificate authorities bundle with firma digitale kits. These are the tools the formats were designed around, they're free, and they handle the local edge cases properly. The catch is that they assume you belong to that country's ecosystem, and several want your card reader and its drivers installed before they'll do anything interesting.

The command line

OpenSSL for .p7m, any unzip utility for .asice. Free, already sitting on most macOS and Linux machines, and completely indifferent to which country the file came from. Windows users can get OpenSSL through WSL or a native build. Perfectly fine, assuming a terminal doesn't put you off.

Browser-based validators

Nothing to install, which matters when you handle one of these files a month and don't want a foreign eID client living on your laptop permanently.

So which p7m viewer is actually worth installing?

Honest answer: for occasional files, a desktop reader is overkill. For daily volume in a single country, install that country's client and stop thinking about it. The awkward middle, where signed files arrive from three countries in formats nobody consulted you about, is where a format-agnostic validator earns its place.

Whichever route you pick, be sceptical of the free "p7m opener" downloads that fill the search results. You'd be handing a signed legal document to an unknown binary from a site you've never heard of. Bad trade for saving five minutes.

Getting the document on screen answers the boring question. The interesting one is whether the signature around it means anything.

Here's what people miss: extracting the payload proves nothing. A .p7m can hold a signature made with an expired certificate, a revoked certificate, a certificate belonging to someone other than who you assume, or a signature over content that has since been altered. Unzip it and the PDF opens beautifully in every one of those cases, because the document really is fine. What's broken is the claim about who approved it.

A proper check answers four separate questions:

• Integrity. Does the hash still match the signed bytes? Anything that changed after signing fails here.
• Chain. Does the signing certificate lead back to a root the validator trusts? Chaindoc treats the EU Trusted List as its primary anchor, with major commercial certificate authorities alongside it.
• Revocation. Was the certificate good at the moment of signing, rather than today? A 2023 file signed with a certificate that expired in 2024 is perfectly valid.
• Timestamp. Is there a trusted timestamp fixing when the signing happened? Without one, the revocation question has no dependable answer.

And one more that no tool decides for you: is the signer who you think it is? Open the certificate subject, read the organisation name and tax identifier, then compare both against whoever you believe sent the file. A cryptographically flawless signature from the wrong company is the shape most invoice fraud takes. Our guide to validating a signed invoice works through that check properly.

Whether a signature counts as qualified under eIDAS is a separate lookup again, against a national trusted list rather than against the cryptography. Qualified trust service providers and the EU Trusted List covers how that lookup works, and the qualified electronic signature guide covers what the label actually buys you in law.

Four habits, all common, all avoidable.

Renaming a P7M file to get at the document. Stripping the extension doesn't unwrap anything. You get a corrupt file, and if that was your only copy you've just destroyed evidence you might need years from now.

Re-saving after opening. Open the extracted PDF, add a comment, hit save, and the bytes no longer match what was signed. Checking against the original container still works, which is the whole reason you keep the container. Checking against your edited copy never will.

Forwarding through systems that touch the file. Mail gateways re-encode attachments. Document management systems normalise whitespace in XML. Portals re-render PDFs on download. Any of these can break a signature without altering a single visible character, so when a file fails, ask the sender to resend it as a direct attachment before assuming bad faith.

Throwing the wrapper away once you have the document. Understandable, and expensive. The signed original is the evidence; the extracted PDF is a convenience copy. Archive both.

All of which is simpler than the file formats make it look. A P7M file is a sealed box, an .asice file is a ZIP with rules, and both hold an ordinary document plus a claim about who signed it. Get the document out however suits you. Then check the claim, because that answer gets more expensive to obtain every month you leave it.