- Blogs
- Administrator
- Troubleshooting ColdFusion Scheduled Tasks Failing Due to SSL Issues
Scheduled Tasks are commonly used in Adobe ColdFusion to automate background operations such as calling APIs, generating reports, sending emails, and synchronizing data. Occasionally, you may encounter a Scheduled Task that fails without providing enough information to identify the actual cause.
One common scenario is when the Scheduled Task is configured to invoke an HTTPS URL, but the SSL handshake fails. Although the task reports a generic Connection Failure, the underlying exception isn’t immediately visible.
This article walks through a simple approach to identify the root cause and troubleshoot SSL-related Scheduled Task failures.
Understanding the Problem
When a Scheduled Task fails, the first place most users check is scheduler.log or http.log. However, these logs often don’t provide enough information to identify the actual problem.
A better approach is to capture the output generated by the Scheduled Task.
Navigate to:
ColdFusion Administrator → Scheduled Tasks → Select the Scheduled Task → Advanced Settings → Publish → Save Output to a File
Specify an output file, for example:
C:\temp\text.log

Note
If you’re saving the output to a custom directory such as C:\temp, make sure the directory is whitelisted in pathfilter.json located under:
<ColdFusion_Home>\cfusion\lib\pathfilter.json
Add the directory to the schedulerexecutionpaths property.
For example:
{
"bytecodeexecutionpaths": "",
"schedulerexecutionpaths": "C:/temp/**",
"car": {
"deploypath": "",
"associatedfiles": ""
}
}
Save the changes, restart the ColdFusion service, and run the Scheduled Task manually.
Open the output file. In many cases, you’ll see only:
Connection Failure
Although this confirms that the request failed, it still doesn’t explain why.
Finding the Actual Exception
The easiest way to identify the root cause is to execute the same URL using the cfhttp tag.
Unlike a Scheduled Task, cfhttp returns the complete HTTP response, including the underlying Java exception.
<cfhttp
url="https://yourserver/application.cfm"
method="GET"
result="httpResult">
<cfdump var="#httpResult#">

For example, you may see:
I/O Exception: Unsupported or unrecognized SSL message
This indicates that the request is failing during the SSL handshake rather than within the ColdFusion application.
Depending on your environment, you may encounter other SSL-related exceptions.
| Exception | Possible Cause |
|---|---|
| Unsupported or unrecognized SSL message | SSL/TLS negotiation failure |
| PKIX path building failed | Missing trusted certificate |
| SSLHandshakeException | Certificate trust failure |
| CertificateExpiredException | Expired SSL certificate |
| No subject alternative names present | SAN certificate mismatch |
| Remote host terminated the handshake | TLS protocol or cipher mismatch |
These exceptions provide far more useful information than the generic Connection Failure message and help narrow down the root cause quickly.
Why Does This Happen?
ColdFusion relies on the Java Runtime for SSL communication, which means SSL trust is determined by the Java keystore.
Common causes include:
- Expired SSL certificate.
- Certificate renewed but not imported into the Java keystore.
- JDK was upgraded or replaced during a system update.
- ColdFusion using a different Java installation.
- Missing Root or Intermediate certificates.
- Incomplete certificate chain.
If the endpoint uses a SAN (Subject Alternative Name) certificate, import the complete certificate chain into the Java keystore, including:
- Root Certificate
- Intermediate Certificate(s)
- Server/SAN Certificate
Importing only the server certificate may not be sufficient if Java can’t validate the complete trust chain.
Importing the Certificate
Once you’ve confirmed that the certificate isn’t trusted, import it into the Java keystore using the keytool utility.
keytool -importcert -trustcacerts -alias "global_cert" -file "C:\temp\server.crt" -keystore "%JAVA_HOME%\lib\security\cacerts" -storepass changeit
Restart the ColdFusion service after importing the certificate and run the Scheduled Task again.
Enabling Detailed SSL Debugging
If the cfhttp output doesn’t provide enough information, enable Java SSL debugging.
Add the following JVM argument under:
ColdFusion Administrator → Java and JVM Settings – Add it in –
-Djavax.net.debug=all
Restart ColdFusion and execute either:
- the Scheduled Task manually, or
- the cfhttp test page.
Review the SSL handshake details in coldfusion-out.log.
The SSL debug log provides detailed information about:
- SSL handshake negotiation
- Certificate validation
- Trust chain verification
- TLS protocol negotiation
- Cipher suite selection
- Certificate exchange
This information is extremely useful when troubleshooting complex SSL-related issues.
Best Practices
To avoid SSL-related Scheduled Task failures:
- Monitor SSL certificate expiration dates.
- Verify the JDK used by ColdFusion before importing certificates.
- Import the complete certificate chain.
- Re-import certificates after JDK upgrades.
- Test HTTPS endpoints using cfhttp before scheduling them.
Scheduled Tasks are commonly used in Adobe ColdFusion to automate background operations such as calling APIs, generating reports, sending emails, and synchronizing data. Occasionally, you may encounter a Scheduled Task that fails without providing enough information to identify the actual cause.
One common scenario is when the Scheduled Task is configured to invoke an HTTPS URL, but the SSL handshake fails. Although the task reports a generic Connection Failure, the underlying exception isn’t immediately visible.
This article walks through a simple approach to identify the root cause and troubleshoot SSL-related Scheduled Task failures.
Understanding the Problem
When a Scheduled Task fails, the first place most users check is scheduler.log or http.log. However, these logs often don’t provide enough information to identify the actual problem.
A better approach is to capture the output generated by the Scheduled Task.
Navigate to:
ColdFusion Administrator → Scheduled Tasks → Select the Scheduled Task → Advanced Settings → Publish → Save Output to a File
Specify an output file, for example:
C:\temp\text.log

Note
If you’re saving the output to a custom directory such as C:\temp, make sure the directory is whitelisted in pathfilter.json located under:
<ColdFusion_Home>\cfusion\lib\pathfilter.json
Add the directory to the schedulerexecutionpaths property.
For example:
{
"bytecodeexecutionpaths": "",
"schedulerexecutionpaths": "C:/temp/**",
"car": {
"deploypath": "",
"associatedfiles": ""
}
}
Save the changes, restart the ColdFusion service, and run the Scheduled Task manually.
Open the output file. In many cases, you’ll see only:
Connection Failure
Although this confirms that the request failed, it still doesn’t explain why.
Finding the Actual Exception
The easiest way to identify the root cause is to execute the same URL using the cfhttp tag.
Unlike a Scheduled Task, cfhttp returns the complete HTTP response, including the underlying Java exception.
<cfhttp
url="https://yourserver/application.cfm"
method="GET"
result="httpResult">
<cfdump var="#httpResult#">

For example, you may see:
I/O Exception: Unsupported or unrecognized SSL message
This indicates that the request is failing during the SSL handshake rather than within the ColdFusion application.
Depending on your environment, you may encounter other SSL-related exceptions.
| Exception | Possible Cause |
|---|---|
| Unsupported or unrecognized SSL message | SSL/TLS negotiation failure |
| PKIX path building failed | Missing trusted certificate |
| SSLHandshakeException | Certificate trust failure |
| CertificateExpiredException | Expired SSL certificate |
| No subject alternative names present | SAN certificate mismatch |
| Remote host terminated the handshake | TLS protocol or cipher mismatch |
These exceptions provide far more useful information than the generic Connection Failure message and help narrow down the root cause quickly.
Why Does This Happen?
ColdFusion relies on the Java Runtime for SSL communication, which means SSL trust is determined by the Java keystore.
Common causes include:
- Expired SSL certificate.
- Certificate renewed but not imported into the Java keystore.
- JDK was upgraded or replaced during a system update.
- ColdFusion using a different Java installation.
- Missing Root or Intermediate certificates.
- Incomplete certificate chain.
If the endpoint uses a SAN (Subject Alternative Name) certificate, import the complete certificate chain into the Java keystore, including:
- Root Certificate
- Intermediate Certificate(s)
- Server/SAN Certificate
Importing only the server certificate may not be sufficient if Java can’t validate the complete trust chain.
Importing the Certificate
Once you’ve confirmed that the certificate isn’t trusted, import it into the Java keystore using the keytool utility.
keytool -importcert -trustcacerts -alias "global_cert" -file "C:\temp\server.crt" -keystore "%JAVA_HOME%\lib\security\cacerts" -storepass changeit
Restart the ColdFusion service after importing the certificate and run the Scheduled Task again.
Enabling Detailed SSL Debugging
If the cfhttp output doesn’t provide enough information, enable Java SSL debugging.
Add the following JVM argument under:
ColdFusion Administrator → Java and JVM Settings – Add it in –
-Djavax.net.debug=all
Restart ColdFusion and execute either:
- the Scheduled Task manually, or
- the cfhttp test page.
Review the SSL handshake details in coldfusion-out.log.
The SSL debug log provides detailed information about:
- SSL handshake negotiation
- Certificate validation
- Trust chain verification
- TLS protocol negotiation
- Cipher suite selection
- Certificate exchange
This information is extremely useful when troubleshooting complex SSL-related issues.
Best Practices
To avoid SSL-related Scheduled Task failures:
- Monitor SSL certificate expiration dates.
- Verify the JDK used by ColdFusion before importing certificates.
- Import the complete certificate chain.
- Re-import certificates after JDK upgrades.
- Test HTTPS endpoints using cfhttp before scheduling them.
- Most Recent
- Most Relevant




