ColdFusion must be configured to use only DOD-approved keystores and truststores containing certificates issued by a DOD Public Key Infrastructure (PKI) Certificate Authority (CA), and all keystore and truststore files must be protected by file system permissions that prevent unauthorized access or modification.

Severity	Group ID	Group Title	Version	Rule ID	Date	STIG Version
medium	V-279063	SRG-APP-000176-AS-000125	APAS-CF-000390	SV-279063r1171542_rule	2025-12-19	1

Description
Keystores and truststores are critical components in securing communication between applications and services. If ColdFusion is configured to use certificates that are not issued by a DOD-approved Certificate Authority (CA), the authenticity and trustworthiness of encrypted communications cannot be guaranteed. Accepting certificates from untrusted or self-signed sources introduces the risk of man-in-the-middle (MitM) attacks, unauthorized access, and spoofing. Keystore and truststore files contain sensitive cryptographic material, including private keys and trusted root certificates. If these files are not adequately protected at the file system level, unauthorized users may gain access and exploit them to impersonate services, decrypt communications, or alter trust relationships. Insecure permissions may also allow modification of trusted CAs, weakening the system's ability to verify legitimate certificates. Restricting keystore usage to DOD-approved certificates and enforcing strict file-level access controls helps ensure data confidentiality, integrity, and authenticity. It also aligns with DOD PKI requirements and mitigates the risk of compromise through unauthorized certificate usage or tampering with trust anchors. Satisfies: SRG-APP-000176-AS-000125, SRG-APP-000175-AS-000124, SRG-APP-000427-AS-000264, SRG-APP-000514-AS-000137

Description

Keystores and truststores are critical components in securing communication between applications and services. If ColdFusion is configured to use certificates that are not issued by a DOD-approved Certificate Authority (CA), the authenticity and trustworthiness of encrypted communications cannot be guaranteed. Accepting certificates from untrusted or self-signed sources introduces the risk of man-in-the-middle (MitM) attacks, unauthorized access, and spoofing. Keystore and truststore files contain sensitive cryptographic material, including private keys and trusted root certificates. If these files are not adequately protected at the file system level, unauthorized users may gain access and exploit them to impersonate services, decrypt communications, or alter trust relationships. Insecure permissions may also allow modification of trusted CAs, weakening the system's ability to verify legitimate certificates. Restricting keystore usage to DOD-approved certificates and enforcing strict file-level access controls helps ensure data confidentiality, integrity, and authenticity. It also aligns with DOD PKI requirements and mitigates the risk of compromise through unauthorized certificate usage or tampering with trust anchors. Satisfies: SRG-APP-000176-AS-000125, SRG-APP-000175-AS-000124, SRG-APP-000427-AS-000264, SRG-APP-000514-AS-000137

ℹ️ Check
Verify Keystore Location and Permission. 1. From the Admin Console Landing Screen, navigate to Server Settings >> WebSocket. 2. If the "Use Built-in WebSocket Server" option is selected and the "SSL Port" is checked, make note of the keystore path and filename. 3. From the Admin Console Landing Screen, navigate to Server Settings >> Mail. 4. If "Sign the mail" is checked, record the keystore path and filename. 5. Review JVM truststore settings by navigating to Server Settings >> Java and JVM. 6. Check if JVM Arguments include a truststore setting. For example: -Djavax.net.ssl.trustStore=/path/to/truststore 7. If present, record the truststore path and filename. 8. If the "JVM Arguments" does not contain a truststore setting, note the path and file name of the default "cacerts" file (found under the directory "Java Virtual Machine Path" settings' subdirectory \lib\security). 9. In each of the ColdFusion instances <ColdFusion_Installation_Directory>\cfusion\runtime\conf, open the server.xml file. Verify all uncommented connector tags for the word "keystorefile". 10. Record any keystore path and filename. 11. For the keystore/ truststore used, use the keytool command to display the CA certificates for the defined keystore/truststore: keytool -list -keystore <trust/key store location> If there are no certificates issued by a CA that is part of the DOD PKI/PKE, this is a finding. 12. Verify Permissions on each keystore/truststore file: a. For Windows: The file permissions must grant Full Control only to the Administrators group and the account running the ColdFusion service. No other users or groups should have permissions. If additional permissions are present, this is a finding. b. For Linux: File permissions must be 640 or more restrictive. The owner must be root, and the group must include the ColdFusion runtime user. If permissions are more permissive than listed above, this is a finding.

ℹ️ Check

Verify Keystore Location and Permission. 1. From the Admin Console Landing Screen, navigate to Server Settings >> WebSocket. 2. If the "Use Built-in WebSocket Server" option is selected and the "SSL Port" is checked, make note of the keystore path and filename. 3. From the Admin Console Landing Screen, navigate to Server Settings >> Mail. 4. If "Sign the mail" is checked, record the keystore path and filename. 5. Review JVM truststore settings by navigating to Server Settings >> Java and JVM. 6. Check if JVM Arguments include a truststore setting. For example: -Djavax.net.ssl.trustStore=/path/to/truststore 7. If present, record the truststore path and filename. 8. If the "JVM Arguments" does not contain a truststore setting, note the path and file name of the default "cacerts" file (found under the directory "Java Virtual Machine Path" settings' subdirectory \lib\security). 9. In each of the ColdFusion instances <ColdFusion_Installation_Directory>\cfusion\runtime\conf, open the server.xml file. Verify all uncommented connector tags for the word "keystorefile". 10. Record any keystore path and filename. 11. For the keystore/ truststore used, use the keytool command to display the CA certificates for the defined keystore/truststore: keytool -list -keystore <trust/key store location> If there are no certificates issued by a CA that is part of the DOD PKI/PKE, this is a finding. 12. Verify Permissions on each keystore/truststore file: a. For Windows: The file permissions must grant Full Control only to the Administrators group and the account running the ColdFusion service. No other users or groups should have permissions. If additional permissions are present, this is a finding. b. For Linux: File permissions must be 640 or more restrictive. The owner must be root, and the group must include the ColdFusion runtime user. If permissions are more permissive than listed above, this is a finding.

✔️ Fix
Configure Keystore Location and Permission. 1. For all untrusted certificates identified, execute the following command: C:\ColdFusion2023\jre\bin\keytool -delete -alias "<certificate alias>" -keystore <keystorefile> 2. Follow the platform-specific steps below to remediate permissions. ColdFusion Running on Windows: a. Right-click the keystore or truststore file and select "Properties". b. Click the Security tab and then click "Advanced". c. In the Permissions tab, click "Disable" inheritance. Select "Remove all inherited permissions from this object". d. Click "Add". e. In the Permission Entry dialog, click "Select a principal". Enter the user account running the ColdFusion service. Assign Read permission and then click "OK". f. Click "Add" again. Click "Select a principal". Enter the Administrators group. Assign Full Control and then click "OK". g. Replace all child object permission entries with inheritable permission entries from this object. h. Click "OK" to apply the changes. Result: Only the Administrators group (Full Control) and the ColdFusion service account (Read) have access. No other permissions remain. ColdFusion Running on Linux: a. For each keystore or truststore file identified, run the following commands (adjust paths and group names as appropriate): chown root:<cfusion_group> /path/to/keystorefile chmod 640 /path/to/keystorefile Example: chown root:cfgroup /opt/coldfusion2023/jre/lib/security/cacerts chmod 640 /opt/coldfusion2023/jre/lib/security/cacerts Result: Owner is root. Group is the group that includes the ColdFusion runtime user. Permissions are 640 (read/write for owner, read for group, none for others). b. Restart ColdFusion to ensure that it starts without error. c. Verify secure mail and WebSocket connections continue to function. d. Recheck the Admin Console settings to confirm no keystore paths were altered unintentionally.

✔️ Fix

Configure Keystore Location and Permission. 1. For all untrusted certificates identified, execute the following command: C:\ColdFusion2023\jre\bin\keytool -delete -alias "<certificate alias>" -keystore <keystorefile> 2. Follow the platform-specific steps below to remediate permissions. ColdFusion Running on Windows: a. Right-click the keystore or truststore file and select "Properties". b. Click the Security tab and then click "Advanced". c. In the Permissions tab, click "Disable" inheritance. Select "Remove all inherited permissions from this object". d. Click "Add". e. In the Permission Entry dialog, click "Select a principal". Enter the user account running the ColdFusion service. Assign Read permission and then click "OK". f. Click "Add" again. Click "Select a principal". Enter the Administrators group. Assign Full Control and then click "OK". g. Replace all child object permission entries with inheritable permission entries from this object. h. Click "OK" to apply the changes. Result: Only the Administrators group (Full Control) and the ColdFusion service account (Read) have access. No other permissions remain. ColdFusion Running on Linux: a. For each keystore or truststore file identified, run the following commands (adjust paths and group names as appropriate): chown root:<cfusion_group> /path/to/keystorefile chmod 640 /path/to/keystorefile Example: chown root:cfgroup /opt/coldfusion2023/jre/lib/security/cacerts chmod 640 /opt/coldfusion2023/jre/lib/security/cacerts Result: Owner is root. Group is the group that includes the ColdFusion runtime user. Permissions are 640 (read/write for owner, read for group, none for others). b. Restart ColdFusion to ensure that it starts without error. c. Verify secure mail and WebSocket connections continue to function. d. Recheck the Admin Console settings to confirm no keystore paths were altered unintentionally.