Core Connector Document Retrieval PGP Decrypt Fails After Key Rotation (Stale Encrypted File)
What it means
An inbound Core Connector Document Retrieval process decrypts a PGP-encrypted file pulled from a vendor's SFTP server. After regenerating an expiring PGP key pair in Workday and sending the new public key to the vendor, decryption started failing, even though the vendor confirmed they had switched to the new key. The actual cause was a file already sitting on the vendor's SFTP server from before the rotation, still encrypted under the old key, which Workday could no longer decrypt now that it only holds the new secret key.
Troubleshooting
- Confirm the timing: did decryption start failing right after a PGP key regeneration, with no other change to the integration itself? That narrows the cause to the key rotation rather than the connector's configuration.
- Rule out the vendor's own systems by confirming with them that new outbound files are actually being encrypted with the new public key, not just that their configuration has been switched going forward.
- Check the SFTP server directly, or ask the vendor, for any file still present from before the rotation date, files encrypted under the retired key will fail to decrypt no matter how correctly the new key is configured on the Workday side.
- Have the vendor remove the stale file and re-upload a fresh copy so it is encrypted under the current key, then re-run Document Retrieval.
Ask the vendor to delete and re-upload the file to the SFTP server so it is freshly encrypted under the current PGP key, then re-run the retrieval.
When rotating a PGP key pair used for inbound Core Connector file retrieval, treat the vendor-side file directory as part of the rotation, not just the key exchange: confirm with the vendor that any file staged before the rotation is cleared or re-encrypted, since a stale leftover file will fail decryption indefinitely even after the key exchange itself is done correctly.