A timestamp was expected but was not found

We are facing following message "A timestamp was expected but was not found" during codesign for following .dylib and .pkg and it cause notarization process failed.

We are facing this issue for last 3 days and we have access for timestamp.apple.com and 17.0.0.0/8 and we didn't change firewall settings. We are facing this issue randomly and not for all time(scenario is 3:1).

We tried the below command to sign the package,

codesign --verbose --deep --force --timestamp --options=runtime --sign "<CODE SIGN IDENTITY>" <TO BE SIGNED PACAKGE>

Kindly let us know how to fix this probelm.

Answered by DTS Engineer in 622559022
Based on some great bug reports filed by folks on this thread, the team responsible for the timestamp server was able to track down and fix what they believe is the root cause of this problem. So, everything should be all good now (-:

If you see this problem crop up again (and we’re still investigating why it wasn’t detected by our own internal systems) please file a bug report and then post your bug number here.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

I have tried the commands and updated the ticket.

Your ticket with us (FB10804197)? Or your ticket with your own network team?

It takes more than one minute to establish the connection.

Honestly, this sounds like another instance of a problem with your firewall. If one of your colleagues in the same region as your non-California office does this from their home network, or from a WWAN network, do you still see the same delay?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi Quinn,

I have updated in the FB10804197. traceroute command details also updated.

I will give the other information soon.

regards

Prema Kumar

Hi Quinn,

We bypassed the firewall as well. Still getting the issue. Could you please try the following?

traceroute from 17.179.249.1 to 103.36.149.1 and 17.179.249.1 to 103.36.149.2

regards

Prema Kumar

Could you please try the following?

My running these traceroutes is unlikely to help because my packets will take a completely different route that yours.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi Quinn,

Thank you for your reply.

Could you please let us know why the requests are failing when they are originated from IP 103.36.149.7?

Many thanks in advance.

Regards

Prema Kumar

Hi Quinn,

May I have an update please? we are blocked from July 18 2022 because of this issue. Or could you please let me know the escalation channel?

regards

Prema Kumar

I don’t think this is an apple issue that you are encountering. We have had no issues from any of our networks or build machines since the original issue was resolved over a year ago.

As Quinn mentioned, this appears to be a networking issue on your own network.

I would suggest reaching out to your IT and security teams and see what changes they made on July 18th to determine if there may be new firewall rules that they recently put into place that are preventing access to the time stamp service.

I know that many organizations will try to “lock down” their networks - particularly those networks that have access to source code - and this can cause problems with the time stamping and notarization services. In fact, just a few months ago, my own organization did a firewall rule review, updated some rules, and broke our access for timestamping and notarization. we had to re-request our firewall exemptions to our internal security team to allow the signing and notarization to work again.

But the most important thing is, this is doesn’t look like an apple issue, and there is nothing that can be done from apples side to resolve it. I would suggest working with your company help desk, IT, and/or security teams to resolve this issue. The document at https://support.apple.com/en-us/HT210060 is likely a good place to start for what endpoints need to be available from your network (there may be additional endpoints - for example, I don’t see timestamp.apple.com on that list - we just ensure that we can access everything on 17.0.0.0/8 and have had no problems).

If, after working and ruling out your own organizations networking issues, there continues to be a problem, I suggest you open a developer support incident with apple - this thread is for a completely separate issue from over a year ago that has been resolved - and there are MANY people on this thread who do not need to be getting notifications of your corporate firewall issues.

How is it that this is still so unreliable? I get the "unavailable" message like 60% of the time when building in the middle of the night. My CI jobs have to run codesign in a delay retry loop until it succeeds for this reason. I don't have to do this for my windows builds which use another timestamp service. My outbound network is unrestricted and not problematic for anything else.

Apple, if you're going to position yourself as the only way to sign apps, you need to actually make your service work reliably!

I've been getting this on multiple machines the last few days. Seems kinda random. Am I the only one?

I do have ping access to timestamp.apple.com.

This is the command we are using:

codesign -vvv -s ... --ignore-resources --timestamp foo.dylib

For others reading this thread, it was IPv6 connections to timestamp.apple.com were unreliable. If you don't need IPv6, then you can set it to "link-local only", which will force codesign to use IPv4.

Thanks to @eskimo for the assist.

A timestamp was expected but was not found
 
 
Q