Proofpoint Protection Server 8.22.4: Patch 5807 leaves SMTP Client without a certificate

I investigated an outage in the outgoing mail flow of a Proofpoint Protection Server (PPS) 8.22.4 today. In short: after an automatically installed patch, the SMTP Client assignment under System > Certificates > Services was set to -none-. Sendmail subsequently established outgoing connections without a TLS client certificate. All peers that identify Proofpoint through this certificate rejected the mail. Regular recipients using opportunistic TLS continued to accept messages, so the issue only became apparent when individual partners could no longer be reached.

If you run PPS with automatic patches and have partners that require a client certificate, check this setting after every patch.

Symptom

Only connections where the peer verifies Proofpoint’s client certificate are affected. Two typical cases:

• Exchange Online with a partner connector restricted to a certificate via RestrictDomainsToCertificate. The rejection is 550 5.7.51 TenantInboundAttribution; Rejecting. Recipient has a partner connector with RestrictDomainsToIPAddresses or RestrictDomainsToCertificate set.
• Smarthost that permits relaying only with a client certificate. The response is 554 5.7.1 <empfaenger@example.com>: Relay access denied.

All other destinations continue to receive their mail. The test matrix therefore shows an inconsistent picture: mail to external recipients goes through, while mail to individual partners or via a specific smarthost fails.

The agent’s mail log contains one of the following two messages for every outgoing connection. If the file is missing entirely:

sendmail[...]: STARTTLS=client: file /etc/pki/tls/certs/sendmail-client.pem unsafe:
  No such file or directory

If the file exists but is empty:

sendmail[...]: STARTTLS=client, error:
  SSL_CTX_use_PrivateKey_file(/etc/pki/tls/certs/sendmail-client.pem) failed
sendmail[...]: STARTTLS=client, error:
  SSL_CTX_use_certificate_chain_file(/etc/pki/tls/certs/sendmail-client.pem) failed
sendmail[...]: STARTTLS=client, error:
  SSL_CTX_check_private_key failed(/etc/pki/tls/certs/sendmail-client.pem): 0

Immediately afterwards, Sendmail still establishes the connection with TLS (verify=OK), but without a client certificate. To the peer, this looks like an unknown sender.

Cause

PPS assigns a certificate to every service on each server. Under System > Certificates > Services, each server lists, among other things, SMTP Server, SMTP Client, Administration Server and End User Web Application / Encryption. PPS generates the file /etc/pki/tls/certs/sendmail-client.pem from the assignment at SMTP Client, which Sendmail uses as its client certificate. If it is set to -none-, PPS writes the file as empty or does not write it at all.

The SMTP Client assignment has only existed in 8.22.4 since patches 5806 and 5807, which Proofpoint released on 29 October 2026. Both are titled “TLS client and server certificate authentication improvement” and, according to the Knowledge Base, fix the inability of PPS 8.22.4 to assign separate certificates for the SMTP server and SMTP client. The feature is included regularly in release 8.23.0 (Release Notes, section “SMTP Client Certificate”).

Proofpoint therefore introduced the assignment rather than resetting an existing one. The patch does not inherit a certificate: after installation, the new row is set to -none-, and from that point Sendmail no longer uses a client certificate. The patch descriptions do not mention this.

In the environment investigated, the assignment was set to -none- on all servers afterwards. Under System > Config History, patch 5807 was visible as an entry configuration changes for patch-… created by system, and the files under /etc/pki/tls/certs/ had the same timestamp. However, 5807 did not appear under Software Patch History. This is consistent with 5807 not installing software but only changing configuration. Config History therefore shows when the change occurred, while the software change itself belongs to patch 5806.

A rollback under Config History to the patch snapshot did not help. PPS rewrote the file afterwards, but with 0 bytes.

Check

In the Admin GUI on the master, go to System > Certificates > Services, then select each agent that delivers externally in turn under Server and inspect the SMTP Client row.

On the agent itself, two commands show the status:

ls -l --time-style=full-iso /etc/pki/tls/certs/
grep -E 'sendmail-client.pem|SSL_CTX_' /var/log/maillog | tail -5

Options explained

Option	Effect
-l	Long format with permissions, owner, size and date
--time-style=full-iso	Timestamp with date, time and time zone, for comparison with the patch time
grep -E	Extended regular expressions so both search terms can be combined with |
tail -5	Show only the last five matches

If sendmail-client.pem is missing or the file has 0 bytes while sendmail.pem is several thousand bytes in size, no certificate is assigned to the SMTP Client service.

Fix

Under System > Certificates > Services, select a valid certificate for SMTP Client on each affected agent and save with Save Changes. This is generally the same public certificate configured for SMTP Server.

The selection list may contain several certificates with the same name, including expired ones. They can only be distinguished by the serial number in parentheses. Before saving, compare the serial number with the list under System > Certificates > Certificates, which shows the issue and expiry dates.

The list for SMTP Client does not necessarily show all imported certificates. In the environment investigated, some certificates were missing despite being valid and expired copies having already been deleted. Neither the patch articles nor the 8.23 Release Notes describe the criteria PPS uses to filter the list. If a certificate is missing, check two points:

• Private key: If the certificate was imported as a PEM without a key, PPS cannot assign it to a service. PKCS12 files always contain the key.
• Intended use: Does the certificate include the purpose TLS Web Client Authentication in Extended Key Usage? Many public certificates issued since autumn 2025 no longer include it (see below). A certificate without this purpose is unsuitable for the SMTP Client service anyway.

Once Proofpoint confirms the criteria, I will add them here.

After saving, PPS distributes the configuration to the agents. Check on the agent:

ls -l /etc/pki/tls/certs/sendmail-client.pem
grep -E 'STARTTLS=client|stat=' /var/log/maillog | tail -20

Options explained

Option	Effect
ls -l	Shows the file’s size and permissions; after the fix, it is no longer empty
grep -E 'STARTTLS=client|stat='	Filters TLS messages from outgoing connections and the delivery result
tail -20	Show only the last twenty lines

The messages SSL_CTX_… failed and unsafe must no longer appear after saving, and deliveries to partners must end with stat=Sent. Sendmail delivers messages previously deferred with a 4xx code from the queue itself. Senders must resend messages rejected with a 5xx code.

Manually copying sendmail.pem to sendmail-client.pem also bridges the outage. However, PPS overwrites the file at the next configuration push as long as the assignment is missing in the GUI.

Check after every patch

Patch 5807 changed the configuration without the patch description indicating the consequences. I therefore recommend checking the Services page after every patch and reviewing Config History to see whether the patch included configuration changes. If patch 5807 has not yet been installed on an 8.22.4 system, assign a certificate to SMTP Client immediately after installation. Monitoring that alerts on the sendmail-client.pem message in the agents’ mail logs is simpler. Under Licenses and Updates > Settings, you can also define when patches are installed. A maintenance window during which someone can check the mail flow significantly shortens such an outage.

Client Authentication is disappearing from public certificates

Independently of the patch, a second change affects exactly these connections. Until now, public TLS certificates have generally contained both purposes in the Extended Key Usage extension: TLS Web Server Authentication and TLS Web Client Authentication. Mail gateways therefore also use their server certificate as a client certificate.

The Chrome Root Program requires public certificates issued from 15 March 2027 onwards to contain only serverAuth. DigiCert has issued public TLS certificates without Client Authentication by default since 1 October 2025; upon request, the purpose remains available until 1 March 2027. Other CAs have similar schedules. OpenSSL shows whether a certificate includes the client purpose:

openssl x509 -in zertifikat.pem -noout \
  -subject -enddate -ext extendedKeyUsage

Options explained

Option	Effect
x509	Subcommand for displaying and processing X.509 certificates
-in zertifikat.pem	Certificate file in PEM format
-noout	Do not output the certificate itself again
-subject	Display subject (CN and additional fields)
-enddate	Display expiry date
-ext extendedKeyUsage	Display only the extension with the intended uses

In Windows, double-clicking the file shows the same information: the Details tab, Enhanced Key Usage field.

What this means for outgoing connections depends on the peer:

There is also the shorter validity period for public certificates. Under CA/Browser Forum decision SC-081v3, it decreases gradually from 398 days to 47 days by March 2029; the first stage of 200 days has applied since March 2026. Every certificate change is a point at which a peer may not know the new certificate.

For connections where partners identify Proofpoint through a client certificate, I therefore recommend:

1. Check existing certificates: Do today’s gateway certificates still include the client purpose, and when do they expire?

2. Plan a dedicated client certificate that permanently includes the client purpose, for example from a private PKI or a CA offering for server-to-server connections. Partners must know it.

3. Ask partners what they verify: name, intended use, issuer or fingerprint. This determines whether a certificate change is a change for them.

4. Handle certificate changes as a change, with a list of all peers that need to know the certificate and a test for each peer.