SignerTimeStampEx2() failed

I'm using signtool to code sign some Windows setup files and application executables. The command that I'm using is:

signtool sign /f "\path\to\certfile.pfx" /p "certPassword" /tr http://tsa.starfieldtech.com /td SHA256 "path\to\setup.exe"

The /tr option causes the signature to be time stamped with the specified time stamp server. The /td specifies the digest algorithm (hash function).

This command is typically executed by an automated code signing job on one of our remote servers. The job signs 22 different executables, half of which are setup files with the other half being application executables. Often, at some point in the signing job, the command fails on one of the files. It's not always one or other type of exe, it happens on both types. The error is:

Done Adding Additional Store  
Error information: "SignerTimeStampEx2() failed." (-2146881278/0x80093102)  
SignTool Error: An unexpected internal error has occurred.  
Sign command failed with exit code 1.  

The MSDN documentation states that the 0x80093102 code means:

CRYPT_E_ASN1_EOD - ASN1 unexpected end of data.

I've checked the server's Windows Event Log and haven't found any related messages.

I rerun the job and it sometimes fails on a different exe and sometimes it successfully signs all files. Note that the job does not rebuild the exe's, it uses the same source exe's each time. I've run this same job locally many times with the same executable files and never had an issue. It seems to be only when I run from the remote server. Based upon that fact, the error information logged, and the text of the result code explanation, it sounds like it is either having trouble connecting to the time stamp server or there's an error while communicating with the server.

What, exactly, does this error mean and how do I resolve the issue?

Update: I've modified my signing script to retry the signing of an individual exe up to five times when it fails on that exe. While testing that change on my local machine, I actually encountered an instance of the same error, indicating that it's not just an issue on the remote server. Assuming that this is simply a failure to contact the time stamp server, this might be my best option. However, I'd still like to know what the exact cause of the error is.