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

I investigated an outage in the outbound 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 outbound connections without a TLS client certificate. All peers that identify Proofpoint through this certificate rejected the emails. Regular recipients using opportunistic TLS continued to accept mail, which is why the problem only became apparent when individual partners could no longer be reached.

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

Symptom

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

• Exchange Online with a partner connector restricted to a certificate via RestrictDomainsToCertificate. The rejection reads 550 5.7.51 TenantInboundAttribution; Rejecting. Recipient has a partner connector with RestrictDomainsToIPAddresses or RestrictDomainsToCertificate set.
• Smarthost that permits relay only with a client certificate. The response reads 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 through a particular smarthost fails.

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

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 using TLS (verify=OK), but without a client certificate. To the peer, this looks like an unknown sender.

Cause

PPS assigns a certificate to each 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 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 as standard 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 carry over a certificate: after installation, the new line is set to -none-, and Sendmail no longer uses a client certificate from that point on. The patch descriptions contain no indication of this.

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

Rolling back 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 at the top under Server, and inspect the SMTP Client line.

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, allowing both search terms to 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 every affected agent and save it using Save Changes. In most cases, this is the same public certificate shown for SMTP Server.

The selection list may contain multiple 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, where the issue and expiry dates are shown.

The list under SMTP Client does not necessarily show all imported certificates. In the environment investigated, some certificates were missing although they were valid and expired copies had 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 PEM without a key, PPS cannot assign it to a service. PKCS12 files always contain the key.
• Intended use: Does the certificate contain the purpose TLS Web Client Authentication in Extended Key Usage? Many public certificates issued since autumn 2025 no longer contain it (see below). A certificate without this purpose is unsuitable for the SMTP Client service anyway.

If 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 size and permissions; after the fix, it is no longer empty
grep -E 'STARTTLS=client|stat='	Filters TLS messages for outbound 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 mail previously deferred with a 4xx code from the queue itself. Senders must resend mail rejected with a 5xx code.

Manually copying sendmail.pem to sendmail-client.pem also bridges the outage. However, PPS overwrites the file again 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 looking in 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. Even easier is monitoring that alerts on the message sendmail-client.pem in the agents’ mail log. Under Licenses and Updates > Settings, you can also specify 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 precisely 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; the purpose is still available on request until 1 March 2027. Other CAs have comparable schedules. OpenSSL shows whether a certificate contains the client purpose:

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

Options explained

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

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

What this means for outbound connections depends on the peer:

There is also the shorter lifetime of public certificates. Following CA/Browser Forum resolution SC-081v3, it is gradually reduced 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 current gateway certificates still contain the client purpose, and when do they expire?

2. Plan a dedicated client certificate that permanently contains 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 validate: Name, intended use, issuer or fingerprint. This determines whether a certificate change constitutes a change for them.

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