S/MIME-Signatur-Verifizierer

What an S/MIME signature covers

S/MIME (RFC 8551) signs the body of an email with a CMS signature (RFC 5652) and ships the sender's X.509 certificate with it. It comes in two shapes:

• Clear-signed — multipart/signed with protocol="application/pkcs7-signature". The first part is the content, readable by any client; the second part, usually named smime.p7s, is a detached signature over the exact bytes of the first part in canonical form, CRLF line endings included.
• Opaque — application/pkcs7-mime; smime-type=signed-data, usually smime.p7m. The content is inside the signature, so a client without S/MIME support shows only an attachment. The verifier unpacks and shows it.

The signature covers the body, not the envelope: From:, To: and Subject: of the outer message are not signed (RFC 8551 §3.1 lets clients protect them by wrapping the whole message). That is why the verifier checks the certificate's e-mail addresses against the From: header separately.

What it checks

1. Structure. The top-level Content-Type, the boundary and the two parts of a clear-signed message, the transfer encoding of the signature. OpenPGP/MIME (application/pgp-signature) is recognised and pointed elsewhere.
2. Integrity. The digest of the signed content is compared with the message-digest attribute, and the signature over the signed attributes is verified with the signer's public key — RSA PKCS #1 v1.5 and PSS, ECDSA, Ed25519 and Ed448. Mail stores and copy-paste often turn CRLF into LF; when the signature only verifies with the line endings restored, the verifier says so instead of failing. The micalg parameter announced in the header is compared with the digest actually used.
3. The signer certificate. It must allow digital signatures and, if it has an extended key usage, include emailProtection — a TLS or code-signing certificate is not good for mail, which is OpenSSL's "unsuitable certificate purpose". One of its e-mail addresses (subject alternative names, or the legacy emailAddress in the subject) must be the sender's.
4. Trust. With the roots you trust supplied, the chain from the signer certificate is built from the certificates in the message and checked at the signing time: signatures, validity, CA flags, key usage and path length. Without them, an intact message is reported as intact, but not trusted — exactly what a mail client says about a certificate from a CA it does not know.

A bare .p7s is checked against the file it signs, added under Detached content; a .p7m carries its content.

The message never leaves your browser

Signed mail is often the mail that matters — contracts, invoices, releases — so the verifier is a page that does the work itself. The pasted text or the opened file is parsed and verified by code running in this tab; nothing is uploaded and no request carries the message. The page offers no share link for the same reason. When the home-page box recognises a signed message, it opens this page with the message in the URL fragment, which browsers never send to a server.

Encrypted messages (enveloped-data) are recognised and left closed: decrypting needs the recipient's private key, and private keys are never asked for anywhere on this site. Revocation is not checked online, because that would mean contacting the certificate authority about the certificate in your message.

Where to find the raw message

The verifier needs the message source with all its headers, not the rendered text. In Gmail it is Show original, in Outlook View message source or Save as .eml, in Thunderbird View → Message Source or Save As, in Apple Mail View → Message → Raw Source. Saving the .eml file keeps the line endings intact and is the most reliable way.

S/MIME is not the only way to sign mail: OpenPGP signs with keys rather than certificates, and DKIM signs on behalf of the sending domain, not the person. Signatures of other email layers can be checked with the DKIM debugger; a certificate from a message can be read in full in the certificate decoder.