PKCS#7 / CMS Inspector

CMS (RFC 5652) is the IETF’s continuation of RSA’s PKCS#7 v1.5, and for the shapes people meet in practice the two are the same bytes: a ContentInfo with a content-type OID and a body. CMS added content types (authEnvelopedData, compressedData), allowed a signer to be identified by subject key identifier instead of issuer and serial, and tightened the attribute rules. The file extensions did not follow the split, so a .p7b, .p7s or .p7m may be either; this tool reads both and says which content type it found.

Almost certainly not: it is a detached signature. In a detached signature the encapContentInfo has an eContentType but no eContent, so the file carries the signature and the certificates and nothing else. The data it covers travelled separately — as the body of the email, or as the file the .p7s sits next to. That is normal for S/MIME and for most signing appliances. It also means the signature cannot be checked without those exact bytes, down to the last newline.

A .p7b is a signedData whose only real payload is the certificates set: no eContent, no signers, and often not even a CRL. It exists because PKCS#7 was the container Windows and Java picked for shipping a chain, and it is what a CA gives you when you ask for "the chain" in a form other than concatenated PEM. Nothing in it is signed, so the version, the digest algorithm set and the empty signerInfos are just an empty envelope around a list of certificates.

When signedAttrs is present, the signature is computed over the DER encoding of that SET OF Attribute — not over the content. The content is bound in only indirectly: one of the mandatory attributes is messageDigest, which holds the digest of the content, and another is contentType. So verifying by hand means hashing the content, comparing it with the messageDigest attribute, then re-encoding the attribute set with its SET tag (0x31, not the [0] the file stores) and verifying the signature over that. Getting the tag substitution wrong is the classic reason a hand-rolled check fails on a file that every real verifier accepts.

No, and neither is a limitation of running in a browser. An envelopedData holds the content key encrypted separately to each recipient’s public key; opening it needs a recipient’s private key, which is not in the file and should not be pasted into a web page. A signature can only be verified against the exact bytes it covers, which a detached file does not carry, and a meaningful verdict also needs a trust store to validate the chain against. What you get here is a complete reading of the structure, which is what tells you why a verification failed elsewhere.

No. CMS is specified as DER, but plenty of producers emit BER instead: an indefinite length is a 0x80 length byte followed by the content and a two-byte end-of-contents marker, and a streamed OCTET STRING arrives as a constructed string of segments. Java’s CMS libraries and openssl’s own streaming mode both do it, so the reader accepts it and reassembles the segments. It matters for one thing only: a signature is computed over particular encoded bytes, so a tool that re-encodes a BER file as DER before verifying will change what it hashes.