Troubleshooting and Resolving a ColdFusion 500 Error Due to BouncyCastle Library Conflicts

Initial Assumptions and Red Herrings

The issue began when an application running on ColdFusion 2023 appeared to stop responding. All signs initially pointed to a .NET or database connection issue. This assumption was made based on the browser developer tools, which showed a generic HTTP 500 Internal Server Error, and a complete lack of entries in the event logs. It looked like the application wasn't even starting.

Still operating under the .NET assumption, I struggled to gather useful logs. The Failed Request Tracing logs were not showing any information, which I later traced back to missing folder permissions. Once those were corrected, the logs began to populate.

Because the failed request log showed a warning related to isapi_redirect.dll, and the ColdFusion page had no logic in it, I changed the file extension from .cfm to .htm to test if the problem was related to ColdFusion execution. Surprisingly, the page loaded correctly, reinforcing the theory.

With logs in hand, I saw warnings related to isapi_redirect.dll but no actionable detail.  I then checked the isapi_redirect.log.  I noticed the following:

Reuse is set to false

This seemed to point to an AJP connector issue, so I removed and reinstalled the ColdFusion IIS connector. However, this did not resolve the problem.

Post-Update Context

This issue emerged after applying ColdFusion 2023 Update 15. Initially, immediately after the update, we experienced a number of errors — also relating to the mail tag. As part of our remediation:

• I downloaded the updated repository zip file from Adobe.

• Backed up the existing bundles folder.

• Replaced it with the new repository contents.

• Used the ColdFusion Package Manager (cfpm) to execute update all.
  
  

No errors were shown while this ran, and upon restarting ColdFusion, the majority of our pages seemed to function as expected. It wasn’t until accessing a specific application — one that sends an email on user access — that the issue resurfaced.

ColdFusion-Specific Clues

Switching attention to ColdFusion’s internal logs, I reviewed coldfusion-error.log and found the following stack trace:

java.lang.VerifyError: Bad type on operand stack
Type 'org.bouncycastle.asn1.smime.SMIMEEncryptionKeyPreferenceAttribute' is not assignable to 'org.bouncycastle.asn1.ASN1Encodable'

This indicated a class verification failure, typically caused by conflicting or incompatible Java class versions being loaded. The stack trace revealed it was tied to the <cfmail> tag.

Root Cause: Mail Tag & BouncyCastle Conflict

Our Application.cfc contains logic in the onRequestStart method that sends a notification email each time a user accesses the application. While the email is not explicitly signed, the <cfmail> tag appears to internally use classes from the BouncyCastle cryptography library to enable secure messaging features.

Due to multiple versions of BouncyCastle being present on the system, ColdFusion loaded the wrong one (or conflicting ones), which caused the class to fail verification at runtime.

BouncyCastle JARs Present:

A quick scan revealed multiple versions of BouncyCastle across different directories:

• bcprov-jdk14-139.jar

• bcmail-jdk14-139.jar

• bcprov-jdk15on-153.jar

• bcprov-jdk18on-1.78.1.jar

These were located in cfusion/lib, various hf-updates folders, and bundles/repo.

Resolution Steps

• Commented out the <cfmail> logic in onRequestStart to confirm it was the trigger — the application loaded fine afterward.
• Removed bcprov-jdk18on-*.jar in favor of the consistent bcprov-jdk15on-153.jar that ColdFusion Update 15 expects.
• Cleared out cfusion/bin/felix-cache.
  
• Restarted ColdFusion.

After the restart, the application loaded without error.

Lessons Learned

• A generic HTTP 500 with no logs can sometimes be caused by middleware or library issues, not just application bugs.

• ColdFusion’s <cfmail> tag may rely on third-party libraries (like BouncyCastle) even if you're not explicitly signing messages.

• VerifyError usually means conflicting versions of a Java class — pay special attention to JARs in different ColdFusion directories.

• Always check cfusion/bin/felix-cache when working with classloader or OSGi-related issues in ColdFusion.

• Updating the bundle repository and using cfpm update all is not always sufficient if older JARs linger.

Summary

This was a tough one — and it was only after carefully peeling back assumptions (from .NET to ColdFusion) and checking hidden logs that the true cause was found. Hopefully, this helps someone else down the road avoid several hours of troubleshooting!