Finding 11, found while writing the EJBCA runbook rather than from a test -
and it is a blocker that fix 1 created.
extractEmailAddresses collected the Subject DN emailAddress attribute
(OID 1.2.840.113549.1.9.1) BEFORE the SAN rfc822Name, and every consumer
reads emailAddresses[0]. Under RFC 5280/8550 the SAN is authoritative and
the DN attribute is legacy, retained only for old clients - so the order
was exactly backwards. Compounding it, signerEmailMatch compared the From
header against position 0 only, never against the other addresses a
certificate legitimately carries.
Two ways a perfectly valid certificate failed:
1. DN and SAN disagree in any respect - case, domain form, a stale
value. The DN wins, From never matches.
2. A multi-alias certificate where the message was sent From the
SECOND rfc822Name. Only [0] is compared, so it mismatches.
Before fix 1 that was a cosmetic amber "signer != From" banner. After fix
1 it BLOCKS auto-import, so the correspondent's encryption certificate is
never stored and encryption silently never becomes available for them.
I turned a latent wart into a functional blocker in the same audit.
This was not hypothetical for much longer: EJBCA populates both fields by
default once the end-entity profile has an email field, which is exactly
what the CA runbook configures. The internal CA would have shipped
certificates this client mishandles on day one.
Fix:
- collect SAN rfc822Name first, DN emailAddress second, de-duplicated
case-insensitively, so [0] is the authoritative address
- add certAssertsAddress(), matching against every address the
certificate asserts rather than only the first
- file the signer certificate under the address the message actually came
from when the certificate asserts it. That address is the key used for
encryption lookups later, so storing a usable certificate under a
different one of its addresses hides it from the code that needs it.
The manual-import paths (index.js:961, pkcs12.js:114) have no From header
to match against and are corrected by the reordering alone.
Verified: new verify-address-binding.mjs, 18 assertions, self-contained -
it generates its own certificates with openssl, including one whose SAN
and DN deliberately disagree, and asserts openssl really emitted both
forms before drawing any conclusion.
Confirmed the bug was real rather than assumed, by running the same suite
against the pre-fix file restored from git with the old [0]-only matching
shimmed back in: emailAddresses[0] resolves to legacy.address@old.example
and all three match assertions fail. Every REFUSAL case still passed both
before and after, so this removes false negatives without loosening the
gate - lookalike domains, substrings and empty addresses are still
refused.
51 + 28 + 18 = 97 assertions passing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
