CipherMail fails to handle S/MIME message after decryption - unknown DL object encountered: 0xd

Hi all,

we are encountering an issue where CipherMail fails to handle certain S/MIME-encrypted emails. After decryption, instead of finding a clean CMS object (as expected), bouncycastle throws an ASN.1 parsing error.

I´ve done extensive analysis of this message structure, including manual OpenSSL processing.

This issue only occours on a new partner, that we are trying to exchange mails with. All existing partners and contacts do work fine.

When messages from this sender is processed through CipherMail, we see the following error in the backend logs:

Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: 04 Jul 2025 16:07:44 | ERROR IOException retrieving CMS content type    (mitm.common.security.cms.CMSContentTypeClassifier) [Spool Thread #3]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: org.bouncycastle.asn1.ASN1Exception: unknown DL object encountered: 0xd
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at org.bouncycastle.asn1.ASN1StreamParser.parseImplicitConstructedDL(ASN1StreamParser.java:158) ~[bcprov.jar:1.71.0]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at org.bouncycastle.asn1.ASN1StreamParser.implParseObject(ASN1StreamParser.java:118) ~[bcprov.jar:1.71.0]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at org.bouncycastle.asn1.ASN1StreamParser.readObject(ASN1StreamParser.java:46) ~[bcprov.jar:1.71.0]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at mitm.common.security.cms.CMSContentTypeClassifier.getContentType(CMSContentTypeClassifier.java:137) [ciphermail-core.jar:5.5.3.0g99d2faca]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at mitm.common.security.smime.SMIMEUtils.getSMIMEType(SMIMEUtils.java:170) [ciphermail-core.jar:5.5.3.0g99d2faca]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at mitm.common.security.smime.SMIMEInspectorImpl.<init>(SMIMEInspectorImpl.java:71) [ciphermail-core.jar:5.5.3.0g99d2faca]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at mitm.common.security.smime.handler.SMIMEHandler.handlePart(SMIMEHandler.java:338) [ciphermail-core.jar:5.5.3.0g99d2faca]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at mitm.common.security.smime.handler.RecursiveSMIMEHandler.internalHandlePart(RecursiveSMIMEHandler.java:248) [ciphermail-core.jar:5.5.3.0g99d2faca]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at mitm.common.security.smime.handler.RecursiveSMIMEHandler.handlePart(RecursiveSMIMEHandler.java:303) [ciphermail-core.jar:5.5.3.0g99d2faca]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at mitm.application.djigzo.james.mailets.SMIMEHandler.handleMessageTransactedNonStrict(SMIMEHandler.java:690) [ciphermail-core.jar:5.5.3.0g99d2faca]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at mitm.application.djigzo.james.mailets.SMIMEHandler.handleMessageTransacted(SMIMEHandler.java:614) [ciphermail-core.jar:5.5.3.0g99d2faca]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at mitm.application.djigzo.james.mailets.SMIMEHandler.access$700(SMIMEHandler.java:126) [ciphermail-core.jar:5.5.3.0g99d2faca]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at mitm.application.djigzo.james.mailets.SMIMEHandler$1.doAction(SMIMEHandler.java:557) [ciphermail-core.jar:5.5.3.0g99d2faca]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at mitm.application.djigzo.james.mailets.SMIMEHandler$1.doAction(SMIMEHandler.java:547) [ciphermail-core.jar:5.5.3.0g99d2faca]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at mitm.common.hibernate.DatabaseActionExecutorImpl.executeTransaction(DatabaseActionExecutorImpl.java:81) [ciphermail-core.jar:5.5.3.0g99d2faca]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at mitm.common.hibernate.DatabaseActionExecutorImpl.executeTransaction(DatabaseActionExecutorImpl.java:131) [ciphermail-core.jar:5.5.3.0g99d2faca]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at mitm.common.hibernate.DatabaseActionExecutorImpl.executeTransaction(DatabaseActionExecutorImpl.java:122) [ciphermail-core.jar:5.5.3.0g99d2faca]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at mitm.application.djigzo.james.mailets.SMIMEHandler.serviceMail(SMIMEHandler.java:545) [ciphermail-core.jar:5.5.3.0g99d2faca]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at mitm.application.djigzo.james.mailets.AbstractDjigzoMailet.service(AbstractDjigzoMailet.java:281) [ciphermail-core.jar:5.5.3.0g99d2faca]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:424) [james-2.3.1.jar:?]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:405) [james-2.3.1.jar:?]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:309) [james-2.3.1.jar:?]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: #011at java.lang.Thread.run(Thread.java:829) [?:?]
Jul  4 16:07:44 mailcrypt1 ciphermail-gateway-backend[603544]: 04 Jul 2025 16:07:44 | WARN  Header says s/mime but the message is not a valid CMS structure.    (mitm.common.security.smime.SMIMEUtils) [Spool Thread #3]

Manual analysis/decryption of the mail:

  1. I opened the original mail in Outlook and saved the smime.p7m file.
  2. Verifying the mail

openssl pkcs7 -in smime.p7m -inform PEM -print

Returns, that the message is an smime encrypted mail:

PKCS7: 
  type: pkcs7-envelopedData (1.2.840.113549.1.7.3)
  d.enveloped: 
    version: 0
    recipientinfo:
        version: 0
        issuer_and_serial: 
          issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Assured ID Client CA G2
          serial: 1234
        key_enc_algor: 
          algorithm: rsaEncryption (1.2.840.113549.1.1.1)
          parameter: NULL
...

Same with

openssl asn1parse -in smime.p7m -inform PEM

    0:d=0  hl=4 l= 676 cons: SEQUENCE          
    4:d=1  hl=2 l=   9 prim: OBJECT            :pkcs7-envelopedData
   15:d=1  hl=4 l= 661 cons: cont [ 0 ]        
   19:d=2  hl=4 l= 657 cons: SEQUENCE          
   23:d=3  hl=2 l=   1 prim: INTEGER           :00
   26:d=3  hl=4 l= 410 cons: SET               
   30:d=4  hl=4 l= 406 cons: SEQUENCE          
   34:d=5  hl=2 l=   1 prim: INTEGER           :00
   37:d=5  hl=2 l= 126 cons: SEQUENCE          
   39:d=6  hl=2 l= 106 cons: SEQUENCE          
   41:d=7  hl=2 l=  11 cons: SET               
   43:d=8  hl=2 l=   9 cons: SEQUENCE          
   45:d=9  hl=2 l=   3 prim: OBJECT            :countryName
   50:d=9  hl=2 l=   2 prim: PRINTABLESTRING   :US
   54:d=7  hl=2 l=  21 cons: SET               
   56:d=8  hl=2 l=  19 cons: SEQUENCE          
   58:d=9  hl=2 l=   3 prim: OBJECT            :organizationName
   63:d=9  hl=2 l=  12 prim: PRINTABLESTRING   :DigiCert Inc
   77:d=7  hl=2 l=  25 cons: SET               
   79:d=8  hl=2 l=  23 cons: SEQUENCE          
   81:d=9  hl=2 l=   3 prim: OBJECT            :organizationalUnitName
   86:d=9  hl=2 l=  16 prim: PRINTABLESTRING   :www.digicert.com
  104:d=7  hl=2 l=  41 cons: SET               
  106:d=8  hl=2 l=  39 cons: SEQUENCE          
  108:d=9  hl=2 l=   3 prim: OBJECT            :commonName
  113:d=9  hl=2 l=  32 prim: PRINTABLESTRING   :DigiCert Assured ID Client CA G2
  147:d=6  hl=2 l=  16 prim: INTEGER           :1234
  165:d=5  hl=2 l=  13 cons: SEQUENCE          
  167:d=6  hl=2 l=   9 prim: OBJECT            :rsaEncryption
  178:d=6  hl=2 l=   0 prim: NULL              
  180:d=5  hl=4 l= 256 prim: OCTET STRING      [HEX DUMP]:xxx
  440:d=3  hl=3 l= 237 cons: SEQUENCE          
  443:d=4  hl=2 l=   9 prim: OBJECT            :pkcs7-data
  454:d=4  hl=2 l=  29 cons: SEQUENCE          
  456:d=5  hl=2 l=   9 prim: OBJECT            :aes-256-cbc
  467:d=5  hl=2 l=  16 prim: OCTET STRING      [HEX DUMP]:1234
  485:d=4  hl=3 l= 192 prim: cont [ 0 ]        
  1. Decrypting the mail does return the signed mail content and is successful.

openssl smime -decrypt -in smime.p7m -inform PEM -recip mailbox.cer -inkey mailbox.pem -out decrypted.txt

When then reapplying the mailheaders to the decrypted content, the smime signature is displayed valid by Outlook.

This happens every time, with the same error. It does not matter, if the message is encrypted, signed or encrypted and signed.
It happens with multiple certificates from multiple recipients.

In the messages, we do see the headers, that the smime signature is not valid. These lines are present, if the mail is signed, encrypted or both.

X-Djigzo-Info-SMIME-Signed: True
X-Djigzo-Info-Signer-ID-0-0: CN=DigiCert Assured G2 EUR SMIME RSA4096 SHA384
 2023 CA1, O=DigiCert Ireland Limited,
 C=IE/E05AD344FE4888505C8D1EA313E4093//1.2.840.113549.1.1.1
X-Djigzo-Info-Signer-Verified-0-0: False
X-Djigzo-Info-Signer-Verification-Info-0-0: Signature could not be verified.
 Message: Message content cannot be verified with the signers public key.
X-Djigzo-Info-Signer-Trusted-0-0: True
X-Djigzo-Info-Signer-Email-0-0: mailbox@partner.com

Certificates:

Ours: RSA2048
SHA256WITHRSA
Signed by: CN=DigiCert Assured ID Client CA G2, OU=www.digicert.com, O=DigiCert Inc, C=US, Serial FFAE1F31A2B433C3D9AE16D643B588B
Other party: RSA2048
SHA256WITHRSA 
Signed by: CN=DigiCert Assured G2 EUR SMIME RSA4096 SHA384 2023 CA1, O=DigiCert Ireland Limited, C=IE, Serial A5402A46D0D8D39D442F5617C4A0014

Setup:

Ciphermail 5.5.3.0g99d2faca
Debian 11.11, all Updates installed.
Installed via .deb
openjdk 11.0.27 2025-04-15
OpenJDK Runtime Environment (build 11.0.27+6-post-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 11.0.27+6-post-Debian-1deb11u1, mixed mode, sharing)

original message:

application/pkcs7-mime
smime-type=enveloped-data
Content-Transfer-Encoding: base64
Filename: smime.p7m

There are no other parts; this is a single-part message whose body is an S/MIME envelope (CMS EnvelopedData).
Each header and body line ends with canonical CRLF (\r\n). No lone-LF lines were observed.

I am out of any further ideas, so i require some help here.
I can provide the full mails in private, if required.

Thanks in advance.
Josef

It would be helpful if you can send me an example encrypted email (martijn@ciphermail.com)

Kind regards,

Martijn

The encrypted blob (smime.p7m) seems to be invalid. It looks like the smime.p7m blob has been PEM encoded instead of DER encoded

If you base64 decode the smime.p7m attachment of the example you sent, you get the following result:

-----BEGIN PKCS7-----
MIICpAYJKoZIhvcNAQcDoIIClTCCApECAQAxggGaMIIBlgIBADB+MGoxCzAJBgNV
[SNIP]
z1ILnMRE1cQ=
-----END PKCS7-----

Afaik, the encrypted blob should be DER and not PEM encoded.,

If you run the following command, you will see the asn1 dump of the correct blob

base64 -d dump.b64 | openssl pkcs7 -print 

Do you know which product created the encrypted message?

The mails are sent from Google Workspace, using the builtin SMIME Encryption. Turn on hosted S/MIME for message encryption - Google Workspace Admin Help
But this issue does also happen when sending from an exchange instance, however I do not know, how the encrypted message is generated here, but I suspect also from the integrated SMIME functionality.

Could be that Gmail creates the wrongly encoded smime part of that some system afterwards changes the email. The headers show that somewhere proofpoint (PP) is involved:

X-Proofpoint-encrypted: text/plain,application/pkcs7-signature,application/pkcs7-signature

Could it be that PP changes the message?

The Proofpoint System is our Outmost mail Gateway. This header is only for internal systems and does not change anything in the mail.

I am currently checking other messages, that we receive, to see, what they are formatted as.

One thing that was not clear to me. Are you able to read the encrypted email in Outlook?

Sorry for the late answer here and thank you very much for your help!

We were able to figure out the issue, and it was in fact the PEM encoding!
RFC5652 requires the CMS to be BER or DER encrypted.

We were not able to read the message in Outlook.
We worked with the partner and they adjusted their settings encrypting the mails. It looks like they used some custom scripts in addition to Google Workspace, so the issue is definitely on the sender side.

Thank you again, and I am looking forward to the new release of ciphermail :wink: