-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Description
Hello dear maintainers,
We have just experienced a regression when updating from v38.0.4 to v39.0.0 when generating S/MIME signatures. We have a setup with multiple intermediate CAs, and the generated signatures are broken, they do not pass smime validation.
We have tracked this to a chain sorting issue, in the generated signature the root CA ends up as the first entry in the signature chain, instead of the expected leaf > intermediate1 > intermediate2 > root order.
We are wondering if this could have to do with the recent bump of the pem library at #8043.
A sample of the code:
def load_certificates(cert_path: str) -> list[Certificate]:
with open(cert_path, "r") as f:
...
return [
cryptography.x509.load_pem_x509_certificate(
bytes(cert + delimiter, "utf-8")
)
for cert in all_certs
]
def load_key(key_path: str) -> CERTIFICATE_PRIVATE_KEY_TYPES:
with open(key_path, "rb") as f:
return cryptography.hazmat.primitives.serialization.load_pem_private_key(
f.read(),
None,
)
def get_smime_attachment_content(
data: bytes,
key: CERTIFICATE_PRIVATE_KEY_TYPES,
cert: Certificate,
ca: list[Certificate],
) -> bytes:
return PKCS7SignatureBuilder(
data=data,
signers=[
(cert, key, cryptography.hazmat.primitives.hashes.SHA512()),
],
additional_certs=ca,
).sign(
Encoding.SMIME,
options=[PKCS7Options.DetachedSignature],
)We have debugged and the ca: list[Certificate] param is pased in the right order, but the generated signature messes this up (and also breaks the signature itself). After generating the message and analyzing it with openssl, we see:
cat smime.msg | openssl smime -pk7out | openssl pkcs7 -print_certs
<root CA>
<leaf>
<intermediate1>
<intermediate2>in a proper email we should see:
<leaf>
<intermediate1>
<intermediate2>
<root CA>Reverting to v38.0.4 fixes the problem.
/cc @max-wittig