Connected System Identity

When Files.com retrieves a partner's files, checks a directory password, or sends mail through your SMTP server, it connects to a system outside Files.com. Encryption protects the connection's traffic. Certificate and host-key verification establish which system receives the credentials or file contents. An encrypted connection without that verification can still deliver them to a different system answering at the configured address.

Files.com applies the identity checks selected in each connection's configuration. Keep certificate or host-key verification enabled, and obtain the expected identity from the system's operator. A failed required certificate or host-key check stops the connection before authentication. Allowing an untrusted certificate or an unexpected host key removes that protection; it does not merely suppress an error message.

These choices complement the permissions and credential ownership described in Outbound Connections. For clients verifying Files.com when connecting to your site, see Transfer Encryption & Algorithms.

LDAP and Active Directory

With Secure Connection enabled, the directory's Server Certificate setting determines what Files.com accepts before sending the service account's credentials or checking a user's password. The default, Require a valid certificate (recommended), verifies the certificate's trust chain and the directory hostname. A certificate failure stops the connection before either set of credentials is sent.

Allow any certificate (insecure) disables certificate validation. The connection remains encrypted, but Files.com no longer verifies that the recipient is your directory. Another system able to answer in its place can receive the service account password and the password supplied by each LDAP user who signs in. Prefer correcting the directory's certificate rather than disabling the check.

The same certificate setting governs LDAP provisioning, including provisioning for users who sign in through another SSO provider. The LDAP/Active Directory configuration guide explains the setting. With Secure Connection disabled, LDAP traffic is unencrypted and certificate verification does not apply.

Custom SMTP

For Custom SMTP, choose Require SSL (Explicit) or Require SSL (Implicit) when credentials and mail must be encrypted from the first connection. Explicit mode requires STARTTLS before authentication or delivery; implicit mode starts TLS immediately. Whenever TLS is used, Files.com verifies the certificate against the configured Server address.

The default, Use If Available, uses STARTTLS when the server offers it. Before a verified STARTTLS connection succeeds, a missing offer permits unencrypted delivery. Someone able to change that initial unencrypted exchange can remove the offer and receive credentials and mail in readable form. A failed TLS handshake instead fails delivery without an unencrypted fallback.

The first certificate-verified STARTTLS connection changes the saved mode to Require SSL (Explicit), even if authentication or delivery subsequently fails. A Child Site Management Policy that controls the mode preserves its policy value instead. Files.com never automatically lowers the requirement. Never Use disables TLS entirely.

SFTP Remote Servers

With Require server host key to match selected, a supplied Server Host Key pins the SFTP server's identity from the first connection. Files.com requires the server to present that key and prove possession of its matching private key before user authentication. A mismatch stops the connection before Files.com sends a password or attempts authentication with a user key.

Without a supplied pin, Files.com detects and stores the key presented on the first connection, then requires it on subsequent connections. That first connection trusts the system answering at the address. To verify the first connection too, obtain the key independently from the remote operator and supply it during setup.

The Allow non-matching server host key option disables enforcement of the pin, including a key you supplied. Keep Require server host key to match selected. If a server's key changes, verify the replacement with its operator before updating the pin. The Server Host Key reference also explains how pinned OpenSSH host certificates differ from certificate-authority validation.

FTPS and WebDAV Remote Servers

FTPS and HTTPS WebDAV verify the remote certificate's hostname, trust chain, and validity by default. Their certificate options can relax that verification. Allowing a self-signed, untrusted, expired, or non-matching certificate leaves the connection encrypted without establishing the intended server's identity.

For FTP, select a required explicit or implicit SSL mode to require encryption before authentication and file transfer. Use If Available permits plain FTP when TLS is unavailable, and Never use disables TLS. A port number alone does not select an encryption mode.

For WebDAV, select HTTPS. An HTTPS connection refuses a redirect to plain HTTP, so a redirect cannot cause its stored credential to be sent unencrypted. A redirect to another origin (a different scheme, host, or port) also omits the stored authorization credential. Selecting HTTP initially permits unencrypted communication.

HTTP File Imports

Import Files in Automations v1 and Import File in Automations v2 send configured headers only to the configured URL's origin: its scheme, host, and port. A redirect to another origin is followed without those headers. This rule is automatic, with no setting to relax it.

An endpoint can therefore check an authentication header and redirect to a file on a separate storage service without giving that service the credential. If the destination needs authentication too, configure an import URL that can authorize the download without relying on headers carried across origins. Use HTTPS for URLs receiving confidential headers; limiting their destination does not encrypt an HTTP request.

AS2 Trading Partners

AS2 separates the identity of the HTTPS server from the identity signing a message or receipt. The partner's Server certificate setting controls TLS certificate validation for an HTTPS endpoint. Requiring a valid, chained, trusted, matching certificate verifies that endpoint; allowing other certificates relaxes that check. S/MIME message encryption protects the message independently of its transport, but does not protect an HTTP Basic Authentication password sent over plain HTTP.

For outgoing messages, the MDN validation level determines what counts as an accepted receipt. Normal and Strict require a valid Message Integrity Check (MIC), a valid Disposition, and a signature verified against the configured partner certificate. This ties the receipt to the private key corresponding to the certificate exchanged with that partner. Strict additionally requires a valid certificate chain and S/MIME signing purpose; Normal permits a self-signed certificate.

Weak accepts a valid MIC and Disposition without requiring a signature. None does not validate the receipt. Auto selects Normal only when the first receipt passes those checks, otherwise Weak if the MIC and Disposition validate, or None if they do not. It saves the selected level for later transmissions. Choose Normal or Strict explicitly when the business process requires a signed receipt. The AS2 partner configuration defines each level and the separate validation of incoming message signatures.

For incoming encrypted messages, decryption failures and parsing or signature-validation failures before the signature is verified return the same failure receipt. This prevents the receipt from revealing whether unverified encrypted contents were decrypted. Use your site's AS2 logs for detailed processing results.