Key & Certificate Changes
Changing a key or certificate used by Files.com can be transparent to one partner and stop another's nightly job. A client using CA-based TLS trust can accept a renewed certificate without an update, while an SSH client that trusts only the old host key will reject its replacement. The key's purpose and the partner's trust configuration determine what needs to change on each side.
Keys need replacement when policy, an identity change, or loss of confidence in their confidentiality requires it; certificates need renewal before their required validity ends. Files.com does not recommend age-only rotation of SSH, API, or GPG keys. A coordinated process makes a necessary change manageable without creating an arbitrary rotation requirement.
Announcement and Verification
Identify every consumer of the key, including unattended jobs, backup transfer systems, failover clients, and partners in both test and production. Include the current key's purpose and fingerprint in the notice so each recipient can identify which configuration needs to change.
Give the other side the replacement public material, verified fingerprint, affected endpoint or account, activation time and time zone, and the action it needs to take. Confirm the request and new identity through the known partner contact or trusted channel before replacing a trusted key. An unverified email containing a new key is insufficient confirmation.
The change announcement contains only public material. Private keys stay with the systems that use them, including a managed service acting on your behalf. If that service needs a replacement private key, configure it separately through the service's supported path.
Overlapping Trust and Cutover
Where the systems support overlapping trust, each side can trust the new key before it is put into use. That gives you a chance to test the new identity, activate it at the agreed time, and verify a complete exchange before retiring the old one. It reduces the risk of one side switching to a key the other does not yet recognize.
Support for overlap varies by purpose and product. A server may accept several client login keys but present only one host key per algorithm; an AS2 partner profile may store one message certificate, and a client may allow several trusted identities or only one pin. If the two systems cannot trust both identities at once, the operators need a coordinated change window.
Keep the previous configuration recoverable for a planned change only while it remains acceptable under the reason for replacement. If a private key has been disclosed or an identity is no longer authorized, promptly end that authority rather than preserving it solely to make rollback convenient.
Differences by Key Purpose
The same announce, verify, test, switch, and retire sequence has different consequences for each kind of key.
| Key or certificate | Preparation | Retirement boundary |
|---|---|---|
| SSH client login key | Register the new public key on the account, configure the client's matching private key, and test that key explicitly | Remove the old authorized public key after dependent clients have switched |
| SSH host key | Distribute and verify the new fingerprint; preload additional client trust where supported | Replace the presented host identity and update or remove old client trust according to the agreed cutover |
| PGP recipient key | Give every sender the new public encryption key and confirm which one it uses | Stop new encryption to the old key while retaining necessary decryption capability for older files under policy |
| PGP signing key | Give verifiers the new trusted public key and agree how they identify accepted signers | End acceptance for new signatures as agreed, preserving the public material needed to interpret retained evidence |
| TLS server certificate | Install the new certificate, matching private key, and intermediates; confirm hostname coverage and partner trust | Activate the new certificate; update certificate or key pins when applicable |
| AS2 message certificate | Exchange the new public certificate with every affected partner and coordinate signing, encryption, and receipt validation | Switch matching certificate/key use on both sides, accounting for in-flight and retained messages |
When several keys are configured, a successful SSH login might still use the old one. Verify the particular credential used in the test rather than concluding that the new key works because the account can connect.
Treat each identity separately even when several changes share a maintenance window. The SSH host key is independent of user login keys, just as an HTTPS certificate is independent of the AS2 message certificate. Each needs its own record and test.
Previously Encrypted Files
A new, unrelated PGP private key cannot decrypt content encrypted to the previous public key. Retain the necessary old decryption key and its passphrase in controlled storage for as long as retained files require it, consistent with the reason for replacement and your retention policy.
Existing encrypted files and messages also matter during AS2 recovery. A retained message encrypted to an earlier identity may need its matching private key if it is processed again. Coordinate retention and recovery requirements before removing the only usable copy.
Retaining the matching key also means keeping it usable by the processing service. Files.com requires unexpired GPG keys, including for decryption of older files. Its GPG guidance explains how to renew the same key and its subkeys when continued decryption is required. Generating a new pair cannot recover content encrypted to the old one.
Files.com Configuration Boundaries
Files.com can associate multiple SSH user keys with an account. Its custom host-key configuration instead controls active server identities and their domain assignments. Follow the host-key rules rather than assuming user-key overlap applies to server presentation.
For AS2 certificate replacement, coordinate every partner using the affected identity. For managed TLS certificates, Files.com handles renewal, while partners maintain any pins or private trust-store requirements they impose.
Key Lifecycle Rules enforce configured expiration or inactivity behavior for supported key types, while your change process coordinates the partner's trust. A required replacement needs to be usable before a lifecycle rule removes or expires the credential on which the exchange still depends.