Certificates & Trust

When a partner connects to Files.com over FTPS or HTTPS, its client checks our server's TLS certificate before sending account credentials. The certificate needs to cover the intended hostname and meet the client's trust policy. These checks can stop a connection even when the server is reachable and the password is correct, so a failure here calls for investigating certificate trust before changing account credentials.

An X.509 certificate brings together a public key, identity information, validity dates, and an issuer's digital signature. The certificate is public, while its matching private key stays with the service using that identity. Having a copy of the certificate therefore does not give someone the ability to act as the service.

Certificate Authorities and Chains

A Certificate Authority (CA) issues certificates after performing the checks required by its issuance policy. Clients trust selected root CAs through a trust store supplied by their operating system, application, or administrator. A server certificate may be signed by an intermediate CA, forming a chain back to one of those trusted roots.

To let the client build that chain, the server presents its own certificate together with the required intermediates. The root is normally already in the client's trust store and need not be sent. Trust comes from that prior configuration; including a root in the server's response does not make the client accept it.

An incomplete chain can work in one client and fail in another because their cached intermediate certificates differ. Install the required intermediates with the server certificate rather than relying on a browser's previous connections. Files.com requires those intermediates when you provide your own certificate.

Hostname, Dates, and Purpose

The client verifies that the certificate's signatures form an acceptable chain, that its validity dates cover the current time, and that it permits the intended use. It also checks the connection hostname against the certificate's Subject Alternative Names (SANs). A trusted issuer does not make a certificate valid for every hostname.

The name the client uses is what matters. A certificate for files.example.com does not cover transfer.example.com just because both resolve to the same server or one is a DNS CNAME for the other. Connecting by IP instead requires appropriate IP-address coverage and can bypass the intended hostname-based routing.

Wildcard coverage has boundaries too: *.example.com can cover files.example.com, but not example.com or files.eu.example.com. Use the service identity rules and the actual client's supported certificate policy when evaluating a name.

An incorrect system clock can make a valid certificate appear expired or not yet valid. Correct the time and certificate configuration rather than disabling validation to make the connection proceed.

Self-Signed and Privately Issued Certificates

A self-signed certificate is signed by its own key rather than by a separate issuer. It can support encryption and proof of possession of the matching private key, but it has no independently trusted issuer. The other side needs to verify the certificate through the agreed partner contact and explicitly configure trust in it.

A private CA issues certificates under an organization's own trust hierarchy. A client can validate those certificates when it has the CA's approved trust anchor installed, but an ordinary public trust store may not include it.

Use a public CA certificate for an internet-facing service when clients need to recognize it through their existing trust stores. When partners agree on explicit certificate trust, verify the public certificate or its fingerprint through an established channel and configure that trust for the intended connection. Trust the verified certificate, rather than configuring the client to accept any self-signed certificate it receives.

TLS Certificates and AS2 Message Certificates

TLS identifies the HTTPS or FTPS endpoint for a connection. An AS2 message certificate identifies the key used for message signing, receipt signing, and message encryption. These certificates have different trust relationships and can have different lifetimes.

AS2 partners can explicitly exchange self-signed message certificates. The HTTPS connection still needs its own certificate trust. Likewise, a publicly trusted HTTPS certificate does not tell a partner which AS2 signing key to trust. AS2 Certificates and Encryption explains Files.com's separate controls.

Trust Across Renewal

Under CA-based TLS trust, a client can accept a renewed server certificate without importing that individual certificate when the new chain is trusted, the hostname matches, and the certificate meets its policy. The renewed certificate can have a different serial number, fingerprint, or public key. A change of CA or intermediate chain can still require an update to an older or restricted trust store.

Some clients instead use certificate pinning to trust a particular certificate, which means renewal requires a coordinated pin update. Public-key pinning ties trust to the key and can survive renewal if the key stays the same. Before relying on automatic renewal, confirm which value the partner pins and whether the change will require an update.

AS2 message trust commonly follows the explicitly configured partner certificate rather than the public TLS CA model. Exchange the renewed public message certificate and coordinate activation with the other side. Key & Certificate Changes explains the differences among replacement, overlapping trust, and retention for older encrypted files.

Files.com manages issuance and renewal for its managed TLS certificates. Customers supplying their own certificate maintain its renewal and chain. In either case, the partner's trust configuration determines whether that partner needs to make a corresponding change.