P7S Attached vs Detached Signatures: How to Tell the Difference

A P7S file can represent two different practical situations. In an attached signature, the signed content is carried inside the CMS/PKCS#7 container. In a detached signature, the signature is separate and the original document must be supplied independently. The file extension alone does not tell you which case you have.

This distinction matters because verification answers a very specific question: does the signature match the exact bytes that were signed? If the original content is absent, the verifier cannot reconstruct it from the signature. It needs the exact original file.

P7S Universal Viewer handles both cases locally on Windows and keeps the signature result separate from certificate trust and other warnings.

Start by keeping every file you received

Do not rename, edit, re-save or convert the files before you know what they are. A detached signature may depend on a second file that arrived in the same email, archive or download folder.

A typical delivery might contain:

• contract.pdf
• contract.pdf.p7s

or:

• invoice.xml
• invoice.xml.p7s

That naming pattern is a useful clue, not proof. Some systems use .p7s for attached content too, and filenames can be changed after signing.

Keep the originals untouched while you inspect them. If you want to experiment, work on copies.

What an attached P7S contains

An attached P7S carries the signed content in the cryptographic container together with the signature information. A viewer can therefore verify the signature and, when supported, extract the original embedded bytes without asking you for another file.

In P7S Universal Viewer, opening an attached signature should allow the app to identify the embedded content. You can inspect the signer information, review the integrity result and save the original content to a separate destination.

Extraction is not the same as conversion. The purpose is to recover the bytes that were included in the signed container. If the embedded content is a PDF, XML file, text file or another format, save it with an appropriate name and inspect it with the application you normally use for that format.

Do not treat successful extraction as proof that the content itself is safe. Signature verification concerns integrity and signer information; it is not an antivirus scan and does not make an untrusted document harmless.

What a detached P7S contains

A detached signature carries the cryptographic signature but not the original signed content. Verification therefore needs an external file.

When P7S Universal Viewer identifies a detached signature, select the original file that you believe belongs to it. The app verifies the signature against those exact bytes.

This is why visually identical documents are not necessarily interchangeable. Opening and saving a PDF again, changing line endings in a text file, exporting an XML document from another program or even making a tiny hidden change can produce different bytes. A detached signature that was valid for the original file should fail against a modified copy.

If the sender supplied both files, use the original companion file rather than a later print, scan, screenshot or converted version.

Why “the document looks the same” is not enough

Cryptographic signatures operate on data, not on human visual similarity. Two files can display the same text while differing internally.

Examples include:

• a PDF rewritten by another editor;
• an XML document with different whitespace or encoding;
• a text file changed from CRLF to LF line endings;
• an image re-exported with different metadata;
• a document copied through software that rewrites its container structure.

Any of these may change the byte sequence. For detached signatures, the correct question is not “does this look like the same document?” but “is this the exact content that was signed?”

A failed verification does not automatically prove malicious tampering. It can also mean you selected the wrong original, the file was legitimately re-saved after signing, or the signature/container is damaged. Preserve the evidence and obtain the original delivery again if necessary.

Read integrity and certificate information separately

A valid signature result means the signature matches the content being checked. It does not by itself answer every question about the signer certificate.

You may still see information or warnings about:

• certificate validity dates;
• whether the certificate chain can be built from available information;
• whether a root is trusted in a particular environment;
• revocation status;
• claimed signing time;
• business or legal acceptance requirements.

P7S Universal Viewer deliberately keeps these concepts separate. Its current release does not perform revocation checks or trusted timestamp-authority validation, and cryptographic integrity is not presented as a legal-validity decision.

That separation is useful when troubleshooting. If integrity is valid but a certificate warning appears, do not describe the document as “tampered with” merely because the trust side needs more review. Conversely, a trusted-looking certificate does not rescue an invalid document signature.

A practical verification workflow

1. Save the files you received without editing them.
2. Open the .p7s or .p7m container in P7S Universal Viewer.
3. Check whether the content is embedded or the signature is detached.
4. If detached, select the exact companion file supplied with the signature.
5. Review the cryptographic integrity result for every signer.
6. Review certificate details separately from document integrity.
7. If content is attached, extract it to a new file rather than overwriting anything.
8. Open the extracted or companion document in the appropriate viewer and inspect the visible content too.

If verification fails, do not keep trying random similar files until one happens to work. Go back to the source of the documents and identify the original signed payload.

Common mistakes

Assuming every P7S contains a PDF. P7S is a signature container, not a PDF format. The content can be many types of data.

Changing the original before verification. A re-save can invalidate a detached signature because the bytes change.

Treating the filename as cryptographic evidence. A matching name helps humans organize files but is not what the signature verifies.

Equating integrity with trust. A valid signature and a trusted certificate are related but separate checks.

Ignoring multiple signers. A container can contain more than one signer. Review each result rather than relying on a single overall impression.

When to ask the sender for new files

Ask for the original package again when a detached signature has no obvious companion file, when every plausible original fails verification, or when the only copy you have was edited or converted after receipt.

If the files are part of an official, financial or legal process, follow the rules of that process as well. A desktop verification tool can help you inspect the cryptographic evidence, but it cannot decide the legal effect of a signature or replace an organization’s required validation procedure.

The safest approach is simple: preserve the originals, determine whether the signature is attached or detached, verify against the exact content, and interpret certificate and trust information as separate evidence.