Mutual TLS

How it works

Ordinary HTTPS proves the server. Mutual TLS proves the caller too. The file still moves with GET or PUT. The extra check is the client certificate. A revoked client cert stops the job without a password change.

A partner job presents a client cert and PUTs a 300 MB invoice file. A stolen password for the same URL fails because no cert is offered. Rotating the cert at quarter-end stops the old job until the new cert is installed.

How it differs

Mutual TLS is not a password link and not SFTP key auth. It is certificate auth on TLS.

A cert that expires on Saturday fails the Sunday job. Calendar the expiry.

Operators who skip the written rule end up debugging the file when the door was the problem.

On the ticket

• The practical close is a log line: time, actor, byte count, result.
• Without that line the transfer is a story.
• With it, the next person can see whether this door did what the ticket claimed.
• If the path is shared, say so in the partner profile so a later change does not silently pick a different limit, key, or region.
• On a real ticket, write down the door, the byte count, and the clock.
• For mutual tls, that means naming the host or bucket, the expected size, and the time the other side must have a complete file.
• A progress bar is not that record.
• A 200 response that arrives before the complete call is not that record.
• If a retry is allowed, say how many and whether it resumes.
• If a person must approve the send, name the person.
• Partners who receive mutual tls files should match on hash or size before they import.
• A same-length corrupt file passes a size check and fails a hash.
• Keep the published hash off the only channel an attacker can edit, or treat it as a corruption check rather than a substitution check.
• When the path changes, new key, new region, new cap, update the profile the same day so the next run does not use a stale limit.